Hacker News Reader

"Microsoft has pretty much abandoned the API"

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

I also made some Win32 development at one point. The programs made using only Win32 have a very snappy and light weight feel to them that is very nice. It is fairly low level and more for the machine than for humans. But I doubt you can have both of these things.

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=19883351

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.

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

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)

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.

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.

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.

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.

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.

> Now in Windows 10, User32/GDI is deprecated and obsolete for high-performance applications (and it’s really slow too after they axed GDI hardware acceleration in Vista), but there isn’t a single replacement, instead there’s like 5 of 6 - all incompatible with each other. While it’s true that it shouldn’t matter because OLE objects were rendered to their own separate hWnd, consider that the new UWP system doesn’t use hWnds, and frameworks like WPF have “air gap” issues with rendering their content overlaying another hWnd and often resort to hacks using window content blitting which drastically hurts performance (as you need to blit to/from RAM, instead of keeping it all in VRAM).

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

I may be totally off-base, here, but isn't WPF independent from Win32?

Sort of. It uses Win32's windowing and input/message loop primitives for top-level windows but within a window's content all the layout, controls and rendering are WPF-bespoke. This is different from Windows Forms which wraps Win32 controls. It's also different from UWP/WinUI which can use Win32 windowing primitives, but doesn't necessarily depend on them. This is all using Win32 to refer specifically to the UI side of things, but if we use "Win32" to refer to the entire set of flat C-style Windows APIs then all these frameworks are heavily dependent on Win32

It is. It’s based on DirectX. I think version 9.

> and I faced this obscure Win32 API, which looks ugly, appalling, antiquated and plainly awful.

As you point out, the code you had to deal with was actually written using the Win16 API.

That Win16 API dates back to the first ever version of Windows which takes you back to a pre 1990 era.

As someone who did work on both Win16 and Win32, what I found amazing is Microsoft designed Win32 such that you could take your Win16 code, do a minimal number of changes and recompile that code for Win32.

That meant you could take your old Win16 code designed for a now obsolete version of Windows, do a minimal number of tweaks, recompile the code using a 32 bit compiler and have it running on the most resent 32 bit versions of Windows.

It was my first experience of a major coding upgrade and it was the last such upgrade that was anywhere near as simple as that upgrade.

> and have it running on the most resent 32 bit versions of Windows.

Or 64-bit, for that matter.

Well, those 32-bit apps run in a hypervisor. The compatibility is so good because you have both 64-bit and 32-bit Windows in your 64-bit installation.

32-bit apps running on 64-bit Windows run using a Windows component called "WoW64". There is another compatibility layer used to run 16-bit apps on 32-bit Windows called "WoW".

Neither "WoW64" nor "WoW" are usually referred to as "hypervisors". That term is usually reserved for systems which run a full operating system using CPU virtualisation technology – Hyper-V, VMWare, VirtualBox, Xen, KVM, etc.

By contrast, WoW64 and WoW are rather thin translation layers. WoW64 just intercepts the 32-bit API calls, translates the parameters, invokes the 64-bit API, and then translates the results back to 32-bit. (WoW does basically the same thing for 16-bit calls to 32-bit.) This is possible because all of the Win32 API calls have Win64 equivalents (likewise, most Win16 API calls have Win32 API equivalents, except for a handful of obscure Win16 APIs which newer versions of Windows don't support.)

WoW runs under NTVDM which uses virtual 8086 mode, so you might call WoW a "hypervisor" in that sense (although the hypervisor is really NTVDM not WoW.) But WoW64 does not use any virtualisation technology at all.

Over the decades a lot of win32 code was written. You can expect that all changes from 1995 on were win32 API only

WTL is a great attempt at creating a close-to-zero-cost C++ library around the Win32 UI architecture. I use it sometimes even today, and it's not bad considering the age of the foundations.

Do you use it in open source projects of commercial applications? If the former, I'd be interested in looking at it.

I think xplorer² is written using WTL.

Yeah. It was a very good start but as usual MS abandoned it before it could get really good.

WTL continues on as an open-source project, supporting the latest updates to Win32 API in Windows 8 and Windows 10.

AFAIK WTL is still being developed as an open source project by the same main developer who originally made it.

They never really embraced it despite it being used internally for several projects.

Abandoned? Every single Windows application uses it, regardless of the language, framework or anything else.

It is the equivalent to Linux syscalls, since it is the lowest stable layer in Windows land.