Comment by bni

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)

I wonder how exactly will those WinUI (or UWP GUI) APIs will be used in practice though. The vast majority of applications that still use Win32 do it through some sort of framework (be it wxWidgets, MFC, VCL/LCL, etc) that has specific assumptions about what desktop applications are and how they are made. From what i've seen, mixing WinUI and Win32 on the same application kinda feels like dropping a web control in a VB6 application and using HTML+JS to create the UI (which ignores pretty much all the strengths of VB6 while retaining all the limitations).

I have a hard time imagining why anyone who isn't forced to use WinUI in their Win32 application (forced in the sense that some middle manager heard about it and believes it is a good idea so forces the developers to use it) would use it in the first place. I mean, many applications/frameworks do not even use stuff available through COM since Vista and instead prefer to recreate them using the plain C APIs and that is for a seemingly simpler and more understood variety of COM.