Comment by stelonix
6 years ago
Exactly this. As a Windows API/GDI developer, I used to loathe the WndProc way, but after looking at how Qt and Gtk do things, I really really miss it; specially considering the aforementioned libraries requires megabytes of space while a simple winapi program might take a couple dozen kilobytes.
What I dislike about Qt is that it's a C++ only library with no proper way to use it in C. And Gtk imposes a convoluted object oriented C library you should learn and the usual tried & tested RAD point & click to get forms done is way more complicated than it should be, vis a vis the MSVC form builder, the way .NET does it or hell, even VB6. In hindsight, Windows API/GDI was great.
FWIW Windows - or at least the HWND parts - is also an object oriented API, it is just closer to something like Smalltalk (which i guess was more popular at the time) than C++. You still define a class with a message handler on it, create instances of this class and can create subclasses. Windows are really supposed to communicate with the outside world via messages and some Win32 calls are really just wrappers for SendMessage.
GUIs tend to fit perfectly with object oriented systems, so it makes sense for a GUI library for a non-OOP language to need to "invent" one. I think one failing of the Windows API was that they made this only for visual windows instead of creating a more generic "HOBJ" object system with message passing that the GUI bits would be implemented on and other system and user APIs would also be able to use.
Though on the other hand Windows event-driven message passing was already a culture shock to most programmers at the time and this could make things even harder :-P
What I like about Windows API when compared to GTK is exactly that: the OO/class system is kept at a minimum and is limited to the handling of the widget tree.