Looks good. One question though: Was it a conscious decision to name the structures in CamelCase? Most other structures use the same name as their native counter parts.

Ah, good point. This was one of the first JNA structures I mapped in my project (for the battery portion) and I had chosen the Java convention at that time, before submitting code here. I'll switch it to match the native variable names.

Also, if you can hold off merging until I get a test from a user with over 64 logical processors to confirm that the function behavior matches the windows docs in terms of counting processors (this doesn't impact the base code but the test case relies on it.)

Sure I'll wait. Please indicate, when you think it is time to rereview this. Thank you!

This is good to merge. A test on an 80-logical-processor system only populated structures for the 40 processors on the current processor group, exactly as the Windows API documentation would lead one to expect.

Ah, good point. This was one of the first JNA structures I mapped in my project (for the battery portion) and I had chosen the Java convention at that time, before submitting code here. I'll switch it to match the native variable names.

I saw, that you changed the casing of the fields. The names of the classes themselves also differ SYSTEM_BATTERY_STATE vs. SystemBatteryState.

Fixed all the casing and went ahead and added all the necessary supporting structures for other options as well.

Hold off on merging, realized some of those structures are supposed to be in WinNT...

Should be good to go!