Comment by pcwalton

6 years ago

> I started with a bit of Win16 and then moved to Win32, and don't really see why it gets a lot of hate; it's not perfect, but it looks like it does exactly what it was meant to do, and does it well.

From a birds' eye view: Because it's just not productive to write apps without some type of modularity, and the WndProc abstraction encourages enormous monster functions that do everything. There's a reason why all UI frameworks have some kind of modular paradigm, whether it's object-oriented or functional reactive or what have you.

More specifically: A lot of the core APIs are just bad. RegisterWindowEx has a struct with a dozen random fields, and CreateWindowEx has a ton of confusing random parameters. For example, why do you have to specify a menu when you're creating a button? Why is dwExStyle the first parameter and dwStyle is the fourth? Why do you have to specify a cursor explicitly instead of just having a function that sets it if you want a non-default one? It's possible to make a low-level C API that's actually reasonably pleasant to use, as in GTK+. Win32 is just a mess.

6 comments

pcwalton

badsectoracula 6 years ago

I have worked with both and i find Gtk+'s C API to be very bad actually, much worse than Win32. Sure, it looks more consistent but that doesn't help when what you want to do is done in a hair-pulling way. It is also much more verbose, though it hides that because it is overall a higher level API than Win32.

The issues you mentioned do exist but they are just minor nitpicks - at the end of the day it doesn't matter at all if the dwExStyle parameter is at the first, fourth or at the last (my guess was that is first to allow for a quick textual search and replace in code to "upgrade" from "CreateWindow(..." to "CreateWindowEx(0, ..."). This is the sort of stuff that will never cause any sort of issue in practice.

Also there are no confusing random parameters in CreateWindow if you actually read the documentation. The menu parameter for a button isn't used for a menu but for an identifier that allows you to distinguish that button from other controls in the window.

Finally your winproc's switch can actually call dedicated functions. You can even write a couple of macros that do that for you so you do something like

    static LRESULT HandlePaint(HWND hWnd, WPARAM wParam, LPARAM lParam);
    static LRESULT HandleSize(HWND hWnd, WPARAM wParam, LPARAM lParam);

    BEGIN_WINPROC(MyWinProc)
    ON_WINPROC_MESSAGE(WM_PAINT, HandlePaint)
    ON_WINPROC_MESSAGE(WM_SIZE, HandleSize)
    END_WINPROC()

which is pretty much the same as what you'd do in other toolkits with setting up event handles such as

    gtk_signal_connect(GTK_OBJECT(widget), "expose_event", (GtkSignalFunc)handle_expose, NULL);
    gtk_signal_connect(GTK_OBJECT(widget), "configure_event", (GtkSignalFunc)handle_configure, NULL);

(or your favorite toolkit's equivalent)

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.
- Crinus 6 years ago
  
  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
  
  1 reply →
pcwalton 6 years ago
I don't find any of this persuasive, but I'll just say: If Win32 were actually more ergonomic than modern UI development, then you'd actually see people using it for apps. Instead, Win32 is basically only used for maintenance of legacy apps at least 15 years old and low-level plumbing. Developers want something better.
- Crinus 6 years ago
  
  Most modern frameworks provide more functionality than raw Win32, such as automatic layout management and most of those are also cross-platform. People use those frameworks because of those features and/or need to be cross-platform, not because of Win32's ergonomics.
  Win32 only provides the basic building blocks for the UI and Microsoft decided that this is enough (i disagree, i'd like them to add new APIs to Win32 for stuff like layout management, resizable dialogs, dockable panels, etc) and anything else should be provided by other libraries, so you just see people using these other libraries.