I remember in the late 1990s Windows applications, particularly the little weird ones like the app you would use to work a (flatbed) scanner, often tried hard to have unique themed appearances. The industry seemed to lose interest by 2005 or so. I got a job as a Silverlight programmer not long after that which got me to learn WPF and WPF had facilities for theming that seemed capable adn well thought out (would be easy, for instance, to turn pill buttons diagonal) but these hardly ever got used, I think the industry had moved on.
Lately I have had to run Office '98 which tries to take over your desktop with Clippy and other things and it still tries to do it to Windows 11. The borderless windows from Office '98 don't quite look right now but it all works.
Yeah, weird-shaped windows are definitely not something that should make a comeback. Just because you could doesn't mean you should.
> Today, all Windows desktop apps look the same as they are the same; they are all built on crap React, Electron, electronbun, and Tauri browser wrappers that mimic the real Desktop apps.
Desktop apps should look the same because they should use the OS GUI framework; that has nothing to do with React and Electron. I can't quite understand this argument; being webview based enables applications to look different from each other, like websites do, not similar. If they still do look similar, that's a good thing.
> The point was usually not usability. It was identity.
Yeah. And usability is sort of a big deal. Applications that implement their own widgets or color schemes or nonstandard shapes usually pay zero attention to usability or accessibility. They almost invariably lack all standard affordances and disregard the standard UX guidelines.
Also, ironically the applications with the most "identity" today tend to be control panels and other accessories by HW manufacturers bundled with device drivers, and they also happen to be the crappiest, most terrible bloatware that an average user is likely to encounter.
Accessibility is really important as well, as there's different laws and regulations covering people's rights here too. Modern cross-platform GUI frameworks (as heavy as they can be) have no issues supporting screen readers and HiDPI for people with sight difficulties.
Not only that, but I think that Electron leads to the opposite problem: all apps look and behave differently, they don't follow platform guidelines, they look out of place.
I never had a problem with that. I want a specific application to behave the same no matter where I run it. I do not want my muscle memory for how to use an application to be confused by an application not looking or behaving the way I am used to when moving to a different platform.
Of course all the applications bundled with a specific OS should be designed to work the same and work well together. It still makes sense to have guidelines and standard widgets in a system. But I prefer very much any third-party multi-platform app to be identical everywhere I run it.
Not to defend Electron. There are many native frameworks that work the way I prefer, looking the same across platforms.
Do platforms even follow their own guidelines? And if they do, are those guidelines good? Microsoft doesn't seem to care about UI/UX at all, Apple's UI/UX quality gets worse each year, and Linux is all over the place with each distro doing its own thing. What guidelines are those apps supposed to follow?
Looking at the current state of things, I think it's good that apps tend to do whatever they think is best for their use case. Also, most people don't switch between 100 different apps all the time.
I used to write a lot of native Windows corporate software in the 90's and 2000's and my standard login window was a floating draggable oval. Nothing else was oddly shaped but I did get a lot of comments on the oval login windows. It was a bit about being unique, marking my "style", and just because I could. I will add though in the 90's it did make me nuts when entire applications were wildly shaped and you had to figure out how to use them.
I'm all for Win32, but those odd-shapes and custom skins were the precursors and the normalizing precedence for the current default mentality of "visual identity = branding" that's been killing desktop computing experience for years and is one of the reasons we have to endure reacts, electrons and multitude of half-baked widget libraries that consist of things looking like no particular control but all feature blurry text rendering, flaky accessibility, negative information density and their own special sets of bugs.
Unless you're building a Blender or an Ardour or, I don't know, a trading platform or a game, an individualized GUI should be the last of your priorities.
It's different. Electron apps all look the same without actually making much efforts to make them "personal" -- they just want to release an app ASAP so they chose Electron.
On the other hand, the Win32 era "skins" like they ones used in Video Player and Winamp are very personal -- they have distinct styles. Maybe we don't like the styles, but at least they are trying to make a unique taste.
Electron apps do not have tastes. Unless you count flat design + as little UI as possible as a taste.
Modern operating systems are for servers, for corporations. They are not personal. Linux was for hackers and sysadmins then, not power users, and for servers now. Linux does make a come back for desktop because Windows team makes such a herculean effort to trash its own product. The Win 3.1 - Win XP era are the real "personal" era.
> Electron apps all look the same without actually making much efforts to make them "personal" -- they just want to release an app ASAP so they chose Electron.
Which is the most goofy thing about the whole situation! I would argue that the push for “visual identity” was largely responsible for the drive towards web apps vs. native apps in the early 00s. In exchange we got all of these tortured UI frameworks built to paper over hypertext abstractions that weren’t well suited to application development to start with. And now we use these frameworks to make bland applications again!
> The point was usually not usability. It was identity.
And we're not even getting usability out of it! Each of those bland react-angles is subtly inconsistent with the OS, with each other, and very often, itself. And in 6 months everything will move around again, for no reason other than to keep the responsible managers employed, without improving UX. And a11y is crying in a corner somewhere, forgotten.
I think those observations get to the crux of the issue:
> That is why weird shaped windows are easy to prototype and expensive to polish.
> But there is an issue with Win32 API programming. And the truth is that custom windows mean doing everything yourself, controlling every Windows message, and that is fragile
Software used to be made by small teams (often of 1). Once released it could be expected to be stable for years.
The priorities have shifted to software that can be built and iterated on quickly, by large teams with high turnover. It’s not uncommon for popular software to get updated weekly, daily.
I suspect this is also why skeuomorphic design lost the evolutionary race - everything needs to be tweaked and aligned and optimized ad hoc. If you want to reorganize the interface, it means potentially recreating a lot of assets. Flat design is interchangeable and modular.
These trends will only get stronger with agentic software engineering - the incentives reward scale and speed.
This is also why we don’t really see large ornate hand carved wooden funiture anymore, it’s all flatpack particleboard now.
While the idea itself may hold water, all of the practical implementations I saw were just too visually busy and… just ugly tbh. I am glad we moved away from that.
It could probably be done better, but that would require lots of effort, as you said.
> But there is an issue with Win32 API programming. And the truth is that custom windows mean doing everything yourself, controlling every Windows message, and that is fragile
This isn't actually true though. You can delegate to the default window proc, and only customise what you want.
Sure, if your window is now a triangle, you need to think about how resizing is going to work. But you don't need to re-implement everything from scratch -- only the defaults that aren't compatible with your new design.
> This isn't actually true though. You can delegate to the default window proc, and only customise what you want.
Yeah that was my memory of doing this stuff. You basically just added what you wanted to the case statement (or other hooks depending on your framework). Then dump the rest onto the default proc. The default 'wizards' usually made the standard petzold structure for you and you didnt even really have to think much about it. Now if you were doing everything by yourself just make sure you read the docs and make sure you call the default in the right cases.
Absolutely, same feeling here. But I also see that the author wanted to say something, and finally he manages: it begins as a rant (generated by a prompt of course) the goes to some examples that are entertaining, at least making me remember how I did some things in the past.
I believe I went to high school with the author, so this took me down memory lane. I wrote an FTP client back in 1999 using only the Win32 API and C. Good times.
I worked on Windows apps for many years. The problem is that the Win32 interface only really gets you 90% control. The hardest thing I've ever done was when our product manager decided that color theming our app was an essential new feature. That's when you find out that certain Windows features like scroll bars under certain conditions bypass the usual message loop completely, because they know they can get away with it. The part I remember most vividly was recreating the lowly MessageBox from scratch, because none of the internals of the system supplied one were exposed in a way that you could modify them.
It was more of you had to know where to grab control. It was not always clear.
With some of them it was dead easy and you can do it on window creation.
Others you had to hook it out by playing with the window params (SetWindowLong) and getting the underlying control and then changing it.
Some controls had their own bespoke way where you would send messages to the control then it would take care of it.
Some you would have to iterate over the control list that window controlled and change it.
In some cases it was just such a pain you were better off making your own custom control window that was just a mashup of other controls that you could control.
It was one part experimentation and one part reading the docs (if the control had it). Now if it was a built in windows control you were playing with. You had to take on the risk on windows version update the customization you did would break if you did non documented things.
> freaking memory is 77% full when freaking Windows 11 starts up.
Unused memory is wasted memory. 77% is basically caches + private process memory + shared memory. Unless you are comparing by the private committed working set, you usually have no idea of the actual usage. .Net apps and browsers often allocate overcommitted memory to avoid making system calls.
I get it, using browsers for ToDo apps is slow, however measuring their impact is harder than you think. At the same time the best x-platform UI framework is the browser. Qt comes next but it lacks man-decade amount of fixes/polishing to match native font support and text rendering, media handling, accessibility support, hw acceleration and memory pressure behaviors of Skia and Chromium.
> Unused memory is wasted memory. 77% is basically caches + private process memory + shared memory.
In simplified overviews, Windows counts file system caches (standby memory) as free (respectively available) memory, so if 77% of 32 GB is to be taken literally, it still sounds rather on the high side.
I am reminded of how the CD burning app Disco for Mac would actually smoke while your disc was burning. Standard looking Window but with semitransparent smoke billowing out the top. If I recall, Steve Jobs showed it off on stage and loved it.
Talking about choice. The article is presented in non-avoidable dark mode. Enough already! Say it with me: dark mode does not directly reduces the brightness, which should be your main concern, it only masks the brightness, which is BAD!
It reminds me a bit of one of the reasons Buckminster Fuller's geodesic domes didn't catch on. It's difficult to make rectangular furniture work efficiently in a non-rectangular space. Likewise, it's difficult to efficiently use a non-rectangular window on a rectangular monitor.
I wonder what is the memory foot print of the notepad application in NT 3.1/3.5? The OS is supposed to run on 16MB systems so 1.8MB is definitely a LOT.
Had one project where for some reason one of the devs wanted to access the messages before it got translated. The reasons are lost to time. You technically could create other types of application that is not CLI or 'windows'. But then you are own your own making the queues or console items. Think they were typically used for device drivers or background service manager tasks.
Pretty sure it just changes out what the default function that is called before winmain. So you probably could just switch out the first function called (dont remember the cli option for that).
Most of the time you just picked the right type at project creation so it would feed correctly into the project solution which would set the right flags on build. But technically you could pick the most basic one and do it all yourself.
The main loop of any GUI application is an event loop. You can't do that without using a platform API, and the platform API happens to be GetMessage() / TranslateMessage() / DispatchMessage(). There is nothing Win32 specific that somehow gives you less ownership of the main loop than you would have otherwise. If anything, it gives you more customization than most other platforms / frameworks by having three separate functions between which you can manipulate events.
At best, what the article is trying to say is "This is a GUI application, so we need to handle user input and paint request events etc in the main loop. Here is how to set up such a main loop in Win32:"
Win32 messages are higher-level than what you get out of select() and such, but that only serves to make it easier to customize things at the appropriate level of abstraction and with sufficient high-level information.
Some AI slop aside, nice article to help us remember that the platform is much more powerful if we dare to do some things without the crippling framework help.
Personally, I find that any Windows application that is remotely polished will have its own win32 WindowProc anyway, even if written in higher-level tech.
For example, if you want custom window controls, you need to use a WindowProc + WM_NCHITTEST to tell windows where the buttons are, so the OS can do things like display the window snapping controls when you hover over the "Maximize" button.
Sidenote: as a designer, its disappointing how many Windows apps are subtly broken in a bunch of these ways. Its not that hard. "Modern" UI frameworks generally don't do this work for you either, there's a real lack of attention to detail.
First, taking the opportunity this discussion presents, I'd like to state for the record, AGAIN, that I have long appreciated the Win32 API and still do -- not because it's great in and out of itself necessarily, it certainly has more warts than your average toad native to the Amazon, but because it de-facto worked for a long while through simple iteration (which grew warts too though) _and_ while it didn't demand Microsoft had everything for _everyone_, it kept Win32 development stable "at the bottom", as the "assembly" layer of Windows development, which everything else was free to build on, _in peace_. Ironically -- looking at the volume of APIs and SDKs Microsoft is churning out today, by comparison, through sheer mass and velocity -- they've proven utterly unable to be sole guardians of their own operating system. There's a plethora of articles shared on Hacker News on this inadequacy on their part to converge on some subset of software that a Windows developer can use to just start with a window or two of their own, on the screen. Win32 _gave you exactly that_. And even `CreateWindow2` export would have worked beyond what `CreateWindow` or `CreateWindowEx` couldn't provide, because you could count on someone who loved it more to just abstract it with a _thin_ layer like WxWidgets etc. Things _worked_. Now there's internal strife between the .NET and "C++ or bust" teams at Microsoft, and the downstream developers are just everything between confused and irritated, this is entirely self-inflicted, Microsoft. It's also a sign of bloat -- if the company could split these groups into subsidiaries, they could compete on actual value delivered, but under the Microsoft umbrella, the result is entirely different.
Second -- and this is a different point entirely -- not two weeks ago there was at least _two_ articles shared here which I read with a mix of mild amusement and sober agreement, about the _opposite_ of what the author of the article linked above, advocates for -- _idiomatic_ design (usually one that's internally consistent):
What I am getting at is that this is clearly different people vocally preferring different -- _opposite_ -- UX experiences. From my brief stint with graphic design, I know there's no silver bullet there either -- consistency is on some level in a locked-horns conflict with creativity (which in part suggests _defiance_), but it's just funny that we now have examples of both, with the above, to which I should add:
> This is why we can't have nice things!
Also, while we "peasants" argue about which way good design should lean -- someone likes their WinAmp-like alpha-blended non-uniform windows and someone else maintains anything that's not defined by the OS is sheer heresy -- the market for one or the other is kept well fueled and another round on the carousel we all go (money happily changing hands).
For my part I wish we'd settle, as much as settling can be done. The APIs should support both, but the user should get to decide, not the developer. Which is incidentally what CSS was _ideally_ kind of was supposed to give us, but we're not really there with that, and I am digressing.
Lately I have had to run Office '98 which tries to take over your desktop with Clippy and other things and it still tries to do it to Windows 11. The borderless windows from Office '98 don't quite look right now but it all works.
> Today, all Windows desktop apps look the same as they are the same; they are all built on crap React, Electron, electronbun, and Tauri browser wrappers that mimic the real Desktop apps.
Desktop apps should look the same because they should use the OS GUI framework; that has nothing to do with React and Electron. I can't quite understand this argument; being webview based enables applications to look different from each other, like websites do, not similar. If they still do look similar, that's a good thing.
> The point was usually not usability. It was identity.
Yeah. And usability is sort of a big deal. Applications that implement their own widgets or color schemes or nonstandard shapes usually pay zero attention to usability or accessibility. They almost invariably lack all standard affordances and disregard the standard UX guidelines.
Also, ironically the applications with the most "identity" today tend to be control panels and other accessories by HW manufacturers bundled with device drivers, and they also happen to be the crappiest, most terrible bloatware that an average user is likely to encounter.
Not only that, but I think that Electron leads to the opposite problem: all apps look and behave differently, they don't follow platform guidelines, they look out of place.
Of course all the applications bundled with a specific OS should be designed to work the same and work well together. It still makes sense to have guidelines and standard widgets in a system. But I prefer very much any third-party multi-platform app to be identical everywhere I run it.
Not to defend Electron. There are many native frameworks that work the way I prefer, looking the same across platforms.
Do platforms even follow their own guidelines? And if they do, are those guidelines good? Microsoft doesn't seem to care about UI/UX at all, Apple's UI/UX quality gets worse each year, and Linux is all over the place with each distro doing its own thing. What guidelines are those apps supposed to follow?
Looking at the current state of things, I think it's good that apps tend to do whatever they think is best for their use case. Also, most people don't switch between 100 different apps all the time.
Unless you're building a Blender or an Ardour or, I don't know, a trading platform or a game, an individualized GUI should be the last of your priorities.
On the other hand, the Win32 era "skins" like they ones used in Video Player and Winamp are very personal -- they have distinct styles. Maybe we don't like the styles, but at least they are trying to make a unique taste.
Electron apps do not have tastes. Unless you count flat design + as little UI as possible as a taste.
Modern operating systems are for servers, for corporations. They are not personal. Linux was for hackers and sysadmins then, not power users, and for servers now. Linux does make a come back for desktop because Windows team makes such a herculean effort to trash its own product. The Win 3.1 - Win XP era are the real "personal" era.
Which is the most goofy thing about the whole situation! I would argue that the push for “visual identity” was largely responsible for the drive towards web apps vs. native apps in the early 00s. In exchange we got all of these tortured UI frameworks built to paper over hypertext abstractions that weren’t well suited to application development to start with. And now we use these frameworks to make bland applications again!
And we're not even getting usability out of it! Each of those bland react-angles is subtly inconsistent with the OS, with each other, and very often, itself. And in 6 months everything will move around again, for no reason other than to keep the responsible managers employed, without improving UX. And a11y is crying in a corner somewhere, forgotten.
> That is why weird shaped windows are easy to prototype and expensive to polish.
> But there is an issue with Win32 API programming. And the truth is that custom windows mean doing everything yourself, controlling every Windows message, and that is fragile
Software used to be made by small teams (often of 1). Once released it could be expected to be stable for years.
The priorities have shifted to software that can be built and iterated on quickly, by large teams with high turnover. It’s not uncommon for popular software to get updated weekly, daily.
I suspect this is also why skeuomorphic design lost the evolutionary race - everything needs to be tweaked and aligned and optimized ad hoc. If you want to reorganize the interface, it means potentially recreating a lot of assets. Flat design is interchangeable and modular.
These trends will only get stronger with agentic software engineering - the incentives reward scale and speed.
This is also why we don’t really see large ornate hand carved wooden funiture anymore, it’s all flatpack particleboard now.
While the idea itself may hold water, all of the practical implementations I saw were just too visually busy and… just ugly tbh. I am glad we moved away from that.
It could probably be done better, but that would require lots of effort, as you said.
This isn't actually true though. You can delegate to the default window proc, and only customise what you want.
Sure, if your window is now a triangle, you need to think about how resizing is going to work. But you don't need to re-implement everything from scratch -- only the defaults that aren't compatible with your new design.
Yeah that was my memory of doing this stuff. You basically just added what you wanted to the case statement (or other hooks depending on your framework). Then dump the rest onto the default proc. The default 'wizards' usually made the standard petzold structure for you and you didnt even really have to think much about it. Now if you were doing everything by yourself just make sure you read the docs and make sure you call the default in the right cases.
1.8MB? I don't know how much it took on our 386 computer with 4MB RAM and windows 3.11, but hopefully not that much
Is it bad that when I read that I immediately thought "this was written by an LLM."
With some of them it was dead easy and you can do it on window creation.
Others you had to hook it out by playing with the window params (SetWindowLong) and getting the underlying control and then changing it.
Some controls had their own bespoke way where you would send messages to the control then it would take care of it.
Some you would have to iterate over the control list that window controlled and change it.
In some cases it was just such a pain you were better off making your own custom control window that was just a mashup of other controls that you could control.
It was one part experimentation and one part reading the docs (if the control had it). Now if it was a built in windows control you were playing with. You had to take on the risk on windows version update the customization you did would break if you did non documented things.
Unused memory is wasted memory. 77% is basically caches + private process memory + shared memory. Unless you are comparing by the private committed working set, you usually have no idea of the actual usage. .Net apps and browsers often allocate overcommitted memory to avoid making system calls.
I get it, using browsers for ToDo apps is slow, however measuring their impact is harder than you think. At the same time the best x-platform UI framework is the browser. Qt comes next but it lacks man-decade amount of fixes/polishing to match native font support and text rendering, media handling, accessibility support, hw acceleration and memory pressure behaviors of Skia and Chromium.
In simplified overviews, Windows counts file system caches (standby memory) as free (respectively available) memory, so if 77% of 32 GB is to be taken literally, it still sounds rather on the high side.
Anyone else liked to skin they Winamp?
Kids these days! A full 1.8MB of memory for little more than a wrapper around an existing win32 multi-line text box control!
(Note that I added the "[only]" in the quote above to make it clear what the author meant since the quote was ripped from context).
https://learn.microsoft.com/en-us/cpp/build/reference/subsys...
Pretty sure it just changes out what the default function that is called before winmain. So you probably could just switch out the first function called (dont remember the cli option for that).
Most of the time you just picked the right type at project creation so it would feed correctly into the project solution which would set the right flags on build. But technically you could pick the most basic one and do it all yourself.
At best, what the article is trying to say is "This is a GUI application, so we need to handle user input and paint request events etc in the main loop. Here is how to set up such a main loop in Win32:"
Win32 messages are higher-level than what you get out of select() and such, but that only serves to make it easier to customize things at the appropriate level of abstraction and with sufficient high-level information.
For example, if you want custom window controls, you need to use a WindowProc + WM_NCHITTEST to tell windows where the buttons are, so the OS can do things like display the window snapping controls when you hover over the "Maximize" button.
Sidenote: as a designer, its disappointing how many Windows apps are subtly broken in a bunch of these ways. Its not that hard. "Modern" UI frameworks generally don't do this work for you either, there's a real lack of attention to detail.
It's good weird-shaped windows disappeared. They are a usability nightmare and override what theme that the users wants for himself.
And for Wayland I found this
https://dev.tizen.narkive.com/AkKHZRHh/wayland-non-rectangul...
Second -- and this is a different point entirely -- not two weeks ago there was at least _two_ articles shared here which I read with a mix of mild amusement and sober agreement, about the _opposite_ of what the author of the article linked above, advocates for -- _idiomatic_ design (usually one that's internally consistent):
* https://news.ycombinator.com/item?id=47738827 ("Bring back Idiomatic Design")
* https://news.ycombinator.com/item?id=47547009 ("Make macOS consistently bad unironically")
What I am getting at is that this is clearly different people vocally preferring different -- _opposite_ -- UX experiences. From my brief stint with graphic design, I know there's no silver bullet there either -- consistency is on some level in a locked-horns conflict with creativity (which in part suggests _defiance_), but it's just funny that we now have examples of both, with the above, to which I should add:
> This is why we can't have nice things!
Also, while we "peasants" argue about which way good design should lean -- someone likes their WinAmp-like alpha-blended non-uniform windows and someone else maintains anything that's not defined by the OS is sheer heresy -- the market for one or the other is kept well fueled and another round on the carousel we all go (money happily changing hands).
For my part I wish we'd settle, as much as settling can be done. The APIs should support both, but the user should get to decide, not the developer. Which is incidentally what CSS was _ideally_ kind of was supposed to give us, but we're not really there with that, and I am digressing.