Having written code for Win32 for a while, I kind of have to disagree. Compared to Gtk+ (I admit, I only used it from Python/Perl/Ruby) or Qt, building GUIs in C/Win32 is a huge pain.
I only had very brief contact with Win32's threading API, but it looked like that was indeed more fun to use than pthreads.
> Having written code for Win32 for a while, I kind of have to disagree. Compared to Gtk+ (I admit, I only used it from Python/Perl/Ruby) or Qt, building GUIs in C/Win32 is a huge pain.
On the other hand: WinAPI stays (even binary-)compatible with new versions of Windows. Gtk+ on the other hand is replaced by newer incompatible versions all the time.
But if one wants to use GNU/Linux on a desktop (in opposite to the server) the desktop libraries are a part of the operating system - thus keeping compatibility for desktop libraries is keeping compatibility for the operating system.
The WinAPI's closest analog in Unix-land is POSIX, which is just as horrifying. Gtk+ vs. WinAPI is apples to oranges. IMO, even WinForms and Visual Studio's form designer are infinitely better than the mess that is Gtk+ and Glade. I haven't tried Qt too seriously, but my impression of it is that its object model combines the disadvantages of C# (less than adequate support for generic programming) with those of C++ (manual memory management, not even aided by smart pointers).
Having written code for Win32 for a while, I kind of have to disagree. Compared to Gtk+ (I admit, I only used it from Python/Perl/Ruby) or Qt, building GUIs in C/Win32 is a huge pain.
I only had very brief contact with Win32's threading API, but it looked like that was indeed more fun to use than pthreads.