The first time I really looked at the Win32 API is when I first started porting the Win32 modules from Perl and Python to Ruby. So, I did they what they did - I wrote C extensions based on the C code I found in the Perl and Python libraries. And it worked.
One of the things I quickly noticed, and have mentioned before, is that there are often many ways to accomplish the same task. Often these different approaches offer slightly different information and you run into a situation where you like approach X, but there is some tiny bit of information you would like from approach Y. But you don't want to use approach Y.
Not too long ago I came across WMI, but I must admit that I had not looked too deeply into it. I wish I had. In fact, I wish I had known about WMI before I ever touched a C extension for Win32.
The fact of the matter is that any informational needs you may have about a Win32 system (remote or local) can be accomplished via WMI. Not only that, you sometimes get much more information using WMI than the equivalent C functions, eliminating the need to pick between approach X or approach Y that I mentioned above.
To be fair to the Perl and Python folks, I think most of the Win32 interfaces were written before WMI arrived (in Windows NT SP 4 I think), and so there's not much incentive to go back and write them now.
However, I am going to revamp all of my ports to use WMI + OLE instead because it's easier to maintain AND it doesn't require that users download and install all the compiler stuff. That means scrapping a lot of hard work I put into the C extensions, but I think it will be worth it in the end. That is, until MS scraps WMI in Longhorn or something. ;)
