Comment by userbinator

6 years ago

No they havent. Everything else in Windows land is just built on top of it.

There were even some articles recently about that:

https://news.ycombinator.com/item?id=19873198

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. Perhaps it's because all of the tiny and fast applications I've used in the past were pure Win32. You can do a lot with it in only a few KB or tens of KB. In contrast, I don't find all the other multi-megabyte UI frameworks appealing.

9 comments

userbinator

Reply
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.

  • 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.

      2 replies →

    • 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.

      1 reply →

ChrisSD  6 years ago

Those articles seem overblown. Providing access to UWP APIs from regular desktop apps will, if anything, increase the number of applications using those APIs. UWP GUI APIs could be especially attractive option to those applications currently using win32 forms.

  • Crinus  6 years ago

    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.