Pooh, I had to do some basic IO programming for Wind*ws-NT and doing so I learned some more details about its API and those MSVC toolkits.
Now I know what it feels like if you do not know how the systems looks like beneath: Common API features of Win32 are good documented but in the moment you need more details for robust code no information is at hand (not at MSDN). It ends up in test applications to figure out how the function might behave. Sometimes documented feature do not work at all or it depends on the Windows Version it was compiled for.
Eg. to close sockets descriptors CloseHandle(sd, ...) may be used on Win-NT, but it is forbidden for Win-CE (Pocket-PC). Some features for Process enumeration exist for Win95, and for Win2000, but for Win-NT-4.0 you need to use another API. Process IDs can be transformed to object handles, being used for synchronization, but it is not possible to query the objects process ID in reverse (The latter is really a problem as PIDs can not be used for process synchronization in robust manner, and process handles can not be used for emitting terminal events). Furtheron, good books about Windows-NT System and Network programming are rare.
In constrast, open source code is free for everybody and if it is bad documented you can have a look into it, basta! In my eyes, this is really an advantage.
Well, as default libc layer of Win-NT is allmost useless and even socket API's home is the native layer of Win32 (which does not interoperate with libc layer function like 'write'), I wrote a thin abstraction layer, close to unix API, that could be used to write portable C-code easily, for Unix and Win32. It is beta and still evolving, but you might try http://cs.tu-berlin.de/~frehberg/gios.html