Comment by wirrbel
6 years ago
My first job out of university was in a company that developed a GUI appication based on the Win32 C API. In fact, the product has been on the market for so long, that it's code had been a Win16 application in the past and pre-dated Win 3.1 (It is a product for a niche market, and had been the first Windows program on the market there, with all other software being MS-DOS Applications).
So, I came from university, had written Software during my master thesis with Qt, had some exposure to Gtk on my home PC a few years before, and I faced this obscure Win32 API, which looks ugly, appaling, antiquated and plainly awful.
But: Development was actually quite pleasant, and, while it didn't offer the flexibility of full-blown object oriented libraries like Gtk or Qt, it was amazingly good at getting stuff done. I wouldn't start a new project in it of course and it seems Microsoft has pretty much abandoned the API. But, I have to admit that I can see how it served Microsoft and its developer community well for a few years. In fact, a lot of things in there where quite thoughtful and I can still appreciate the non-bloaty way of doing things, if I see how many processes and memory an electron app uses that doesn't do much more than what a simple Win32 program does.
"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=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.
6 replies →
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.
1 reply →
> 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.
2 replies →
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.