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.
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.
I use probably 70% Windows, 20% iPad, 5% Meta Quest 3 [1], and 5% MacOS -- for the latter though it is mostly "test that something works on MacOS" and "tech support for the computer the family uses".
I like web-based applications that behave the same everywhere. Personally I feel the MacOS widget set is a touch old fashioned, a little ugly and gauche. I can see though why somebody might like the MacOS terminal better than CMD.EXE. The dominant theme on Windows is that Windows has several widget sets that aren't consistent but the average user doesn't notice or care -- probably the worst area is the settings dialogs which seem to be mostly migrated to a Metro-based design lately. I was afraid before they wouldn't finish that migration before they churned to another framework but I think they've stopped the churn.
The best windows applications, in my mind, steal from web technology -- like they are either using some kind of HTML-based UI or they are made by people who grew up making web applications and reproduce those patterns w/ the desktop widget sets.
[1] I've got some web applications I wrote that run perfectly on the MQ3, especially after I got target sizes up to WCAG AAA level and it is fun to put the headset on and crash out on the couch and get things done
> I've got some web applications I wrote that run perfectly on the MQ3, especially after I got target sizes up to WCAG AAA level and it is fun to put the headset on and crash out on the couch and get things done
One way to have better text in VR for 2D content is to make use of OpenXR composition layers:
I don't think platform guidelines that anyone listens to have been a real thing for a long time. Even between apps released by MS there is little or no consistency at times, things that should be part of standard OS provided chrome like title-bars are a random mess - good luck guessing what has input focus sometimes, particularly with multiple monitors, as you unlock or switch vdesktop, without clicking to make sure.
I keep thinking of writing something that detects the top-most app window and draws an obvious box around it.
Native macOS developers respected Apple's Human Interface Guidelines for a long time, but even that's declining now that everyone needs to work around all the problems with Liquid Glass.
>> I keep thinking of writing something that detects the top-most app window and draws an obvious box around it.
I would use this in a heartbeat. With Windows 10/11 I usually have the option to apply a garish accent color to the active window active. Nowadays, more and more apps don't use native window frames anymore, so that option works less and less.
The W11 task bar with its barely legible indicators doesn't help either.
On a big ultra-wide display with a few windows open, I sometimes struggle to see which one is active.
> > I keep thinking of writing something that detects the top-most app window and draws an obvious box around it.
> I would use this in a heartbeat.
I may one day get around to it. Of the many projects on my “will probably never actually happen” list¹ it is one of the smallest. I did something similar to add other decorations to windows back in my just-post-Uni days². Walking the process list, getting the hWnd(s) you were interested in, and for there the window dimensions, was fairly trivial and it no doubt still is.
----
[1] I mention them here where relevant, in the hopes that someone else will see the ideas and be inspired to implement the them in an open form so I don't have to :-)
[2] ~win2000 era, I was playing in Delphi at the time
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.
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.
> Yeah, weird-shaped windows are definitely not something that should make a comeback. Just because you could doesn't mean you should.
My opinion here is the exact opposite of yours. Make computers cool again! They used to look like an alien spaceship, now everything looks like paperwork.
I'm with you. It's fine if your opinion is "software = tool" and you personally want it to be utilitarian and basic, but plenty of us desire our software interfaces to have personality and customization. The answer is that we should have the option to choose.
I use computers for a plenty of fun, but those programs always were the digital equivalent of garden gnomes. Utterly kitschy. Just having a basic sense of aesthetics doesn't imply thinking that computers should be dull or just for work.
Agreed. I remember seeing quite a few non-standard designs in the days of Vista, especially when Microsoft was heavily promoting the Windows Presentation Foundation framework and using XAML for UI design.
The problem with setups like this is that the moment you need to resize them, place them in a specific spot, or move them to a larger or smaller monitor, they tend to scale terribly and end up causing all kinds of “death by a thousand cuts” issues.
It would help if you had seething more specific to say about usability rather than blindly defending the bland conformity: for example, if your music player app looks like your physical old round CD music player, not a rectangle, how exactly does it hurt usability?
> Applications that implement their own widgets or color schemes or nonstandard shapes usually pay zero attention to usability or accessibility.
OS are close to this, pick any era of the constantly changing OS color schemes and widget design, and you'll find plenty of issues, with the basics of the basics - readability - suffering.
So again, why should everyone be generically bad just because they wrote the "guidelines"? Sure, change doesn't mean good, but the neither does using the defaults
Quite. And the era when everyone was trying to "do their own thing" with UI design wasn't exactly pleasant or usable. Just have a look at some of these designs, for example
Not to mention that the statement is wrong. Windows applications do NOT look the same, and that's bad.
Oh... except for their lack of a title bar, which prevents you from telling which application you're looking at. Is this PDF open in Edge, or Acrobat? Who knows. The windows look the same.
Beyond that... it's a disgraceful mess. You have applications now with no menu bar, but instead a bunch of hamburger buttons and "gear" buttons scattered all over the place. And common, standard functions like "save file" are further hidden behind "more" labels even in THOSE menus.
Another example of Windows's galling regression: the abolition of the File dialog in many apps, which have replaced it with a giant page of crudely-drawn, unlabeled, super-wide text boxes and a bunch of plain text. There's no file structure shown, so you have no idea where you are about to save a file... It's truly a clinic on dogshit UI. Pathetic.
Companies like IBM and Microsoft did a lot of HCI research back in the 80s, and made a lot of progress with usability and common idioms that all software followed. Then when displays with 256 or more colors became common, all that went out the window.
All those Windows Media Player skins were awful because they used so much screen real estate on dead space. Whereas the plethora of Winamp skins kept the economy of screen real estate while still providing unique and imaginative visuals.
The whole skeuomorphic trend starting in the mid-90s was similarly awful for the same reason. First, it was often hard to tell what was a control and what was just decoration. Second, it often took trial and error to figure out what was what. And, as I mentioned above, these designs almost inevitably wasted huge chunks of screen space on decoration that provided no functionality.
Of course, we have the opposite problem now. All windows look the same. Title bars are mostly gone. And since companies like Microsoft replaced all their HCI experts with art-school dropouts who think the "flat" look with low contrast is cool, not only can you not tell what app you're looking at. Half the time you can't even tell where one window stops and another starts.
The only good UI thing that's come out of the last decade or two is a near universal support for "dark mode". Otherwise, I would greatly prefer the Windows 2000 "classic" look, or something similar.
I agree with your sentiments, but not your timeline. The mid-'90s was the high point for GUIs, with Windows 95 nailing it pretty much across the board.
And as you note, "flat" design is NO design. It's total dereliction of the design task. Fortunately we're seeing some steps back toward legitimate GUI, where controls are occasionally demarcated as controls.
A great example of Windows's pathetic regression is "dark mode." Since the early '90s (and I mean '91 or '92), you could set up a system-wide color scheme. Inverse color schemes were an unfortunate vestige of the late '80s, early '90s... the advent of the Mac, "desktop publishing," and the effort to make the screen an analog for a piece of paper. That analogy fails.
The result was millions of people reading black text off the surface of a glaring light bulb all day, every day. The first thing I did was set up a charcoal theme in Windows, pretty much exactly what all the "dark" schemes are today. And all properly written applications inherited it and all was good.
So... just in time for people to realize that this was the way, Microsoft REMOVED the color-scheme editor from windows. Only to have to hastily slap a hard-coded "dark mode" back onto the OS. So damned stupid.
I'm all for Win32, but those odd-shapes and custom skins were the precursors and the normalizing precedent 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!
It's the worst of both worlds. Not only are the bland, but they don't even follow the platform's conventions, have horrible accessibility (because they no longer get it for free from the platform), and don't respect my desktop environment's theming, fonts, colors, and so on.
I think they want an app, but prefer to use web stack, so that's the result. The reason they want an app instead of a web application, is maybe an app gives them more control.
Web development has been part of my life, on and off, since around 1998, and I never shipped browsers inside applications, not even during MSHTML glory days.
Either proper application, or delivered to the already installed browser.
I even refused a job offer where that was going to be part of it, some Electron like thingy.
For your average business app, yes, I agree, however there are a lot of apps I use on my iPad that have essentially moved this "custom skin" UI into elements in a full-screen wrapper and they look and work wonderfully. There are also lots of smart devices that have hyper individualized UIs, modern cars, anything in the audio realm with a screen, plenty of examples.
But yes, you're showing a series of forms to fill out? Use the platform native controls and make it work perfectly.
> 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.
> 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.
Of course absolutely ancient, but once you learn how to read them, they're very comprehensive.
And the 3rd party content written about win32 is pretty evergreen. I regularly find articles written in the '90s that are helpful today. The beauty of an incredibly stable API, and documentation written before everyone had the internet.
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.
> 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.
Another way to say this is: cost cutting. We gave up superior usability so software could be made more cheaply. See also: replacing buttons and knobs in cars with a big iPad.
I think HiDPI is another reason - these were from the "96 DPI" era where pixels looked the same on every screen. You can draw all your pixel art at 2x (or 3x) and scale it down at load time, but it's not super easy.
Also, some of the RAM usage of modern apps is the need for a full backing store for each window - in the "true" win32 days like Windows 95, XP, or Win7 in classic mode, you'd be drawing directly to the front buffer, with no extra RAM/VRAM usage per pixel. Of course it flickered and looked bad, but it was fast and cheap.
The two root causes of these sort of windows disappearing is what you've said (DPI) and just a change in tastes.
People now view those styles as kind of garish. Between that and the difficulty of making it work and look good at a variety of DPIs, it just wasn't going to stick around.
I admit, I like things to have some more color and texture. Simple black and white boxes are a bit soul crushing. But I see why they disappeared.
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 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.
My memory from the old days is you can use Win32 hooks to modify the MessageBox. HCBT_CREATEWND gets you the HWND of the MessageBox, and you can subclass it (in the Win32 sense) to insert your own WndProc. Then you're off to the races--it's your dialog now.
But it wasn't just one window, there were lots of controls on that window and the relationship between them wasn't as obvious as you'd assume. Trust me, recreating the whole thing from scratch was easier.
The fun part was making a C++ class that could build up an in-memory dialog template. You had to do it that way because it was dynamically sized based on the message you displayed and the buttons you needed. If you used the default colors, you might be able to tell they were different if you squinted but you wouldn't know which was mine and which was Microsoft's.
I've done this for real, in commercial code that shipped. No trust needed; I have personal experience. For typical minor MessageBox additions, this can be easier than rebuilding the whole dialog yourself. Sometimes, we just wanted to add a "Don't ask again" checkbox which didn't require touching the existing child windows at all. I also used this technique to simply change the labels on the buttons to custom text. I had a MessageBox wrapper that accepted a list of button strings instead of a predefined constant. We've all built various custom message boxes, of course, but not every situation required that level of effort.
These days you can just use a TaskDialog, of course, and it's way more flexible than MessageBox. But it's fun to remember the old techniques.
You can modify this stuff if you go deep enough and are willing to detour the native Win32 API functions. Some things implemented in User32.dll don't make the appropriate API calls back to other User32.dll functions, and you need to detour Win32U.dll instead.
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.
The biggest problem was when there was an established protocol, but it wasn't always followed. I remember scroll bars being the worst. Usually you could respond to the messages and everything would work the way you want, but there were some edge cases where Windows would update those scroll bars without even telling you it was doing so. And of course it would paint those updates in the default colors.
I honestly don't know if Qt would have made it any easier. But this was a large and old app that relied on Win32 at its core, and nobody was going to accept rewriting it for just one feature. Plus our customers were very time sensitive, and anything that could have slowed it down by a few ms was off the table.
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 and 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.
To my delight, The article also mentioned desktop mascots! I saw a cool video recently where someone made a desktop pet in Godot, and it seems to be cross platform as well.
It seems to be a little fiddly, but not quite win32 level fiddly :) So, maybe a more approachable option for the desktop pet enthusiast.
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.
Even a minimal Hello World program (1.5KB executable) takes 340K of active private working set, and 552K of commit size. Windows just don't allow programs to use any less memory than that. You're bound by what the system libraries allocate (either statically or dynamically).
Once you create a window, even if you haven't drawn that window, your minimum is now around 500KB.
Given that I assume NOTEPAD.EXE is still basically a window containing an optional status bar and a multiline edit control with a custom WNDPROC for managing features like word wrap, I'm actually curious why it opens with such a large private working set, even on Windows 11.
Possibly space for data allocated by one of the 50+ DLLs it loads directly or indirectly to support features like Unicode text input and rendering.
Actually, it gets much worse. By default, recent Windows 11 versions use a completely new version of Notepad with support for things like tabs, styled text, and AI (!).
Even with all the new features disabled, this one has a 32 MB private working set before opening a single file.
Amusingly, GNU Emacs, a.k.a. Eight Megabytes And Constantly Swapping at a time when entry-level UNIX workstations actually shipped with as little as 4 MB RAM, opens on the same machine with a smaller (25 MB) private working set than the new Notepad.
To be fair to at least one team at Microsoft, the EDIT.EXE text-mode editor recently added to Windows 11, with a user interface that somehow manages to be more consistent with basic Windows UI conventions than many modern Windows GUI apps despite not being a GUI app at all, opens with a private working set size of only 520 kB.
Window transparency is available on all major platforms, and there are cross platform libs which support it, such as SDL3: https://wiki.libsdl.org/SDL3/SDL_WINDOW_TRANSPARENT (for rendering, making underlying windows visible where window surface pixels are transparent), https://wiki.libsdl.org/SDL3/SDL_SetWindowShape (for input, making pointer events pass to underlying windows where surface pixels are fully transparent)
I (ab)use it in my image (pre)viewer to have image presentation area always fitting image during pan&zoom without window borders limiting it, while having underlying windows visible outside of it (transparent fullscreen overlay): https://github.com/shatsky/lightning-image-viewer
> 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.
Why does my computer freeze and become unusable when the RAM is 90%, then? That myth is complete nonsense - RAM is like a seatbelt or a crumple zone, serves as a buffer between the user and crashes, and will hopefully never be tested under use.
Article only mentions manually building an irregularly shaped region from an image
> Every horizontal run of non-transparent pixels becomes a tiny rectangle region, and those runs are combined into one final window region
but there's an easier way: you just use a LWA_COLORKEY with SetLayeredWindowAttributes to make a color transparent, like a green screen. I recall building my own desktop mascot that way. Doesn't work with arbitrary image/content of course since the color can't appear in the content region.
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.
Editing this to add: I really miss that level of coding and working with Win32. I get that the world has moved on and HTML or some runtime flavour of it has taken over but I too lament the los of true control I once had. I hate that my stack can be broken because some runtime was updated out of my control or the crazy load times of simple projects. I know many today would say it was messy and problematic (and it could be) but it's definitely a lost art form.
Sonique media player, Trillian messenger and NeoPlanet web browser. I was there, man. Before flat UI and sensible color schemes took hold. For a moment, it was pretty wild.
> Desktop UI culture shifted from “look at this crazy skin” to “work reliably and get out of my way.”
I miss the wobbly windows I had in Linux when we started playing with Compiz.
Or neko on my Sun machines.
As for weird-shaped windows, I think it is about ergonomics. A different shape requires more thinking to operate. Form should follow function, not the other way around - if the odd shape serves a purpose, then it makes sense. If it's just to show off, or to make the app look different, then it becomes a usability issue.
I don't, though I still have fond memories of olwm, AfterStep, and WindowMaker, as well as the NEXTSTEP 3.3 GUI running on greyscale NeXT hardware fished out of a dumpster behind the Indiana University School of Journalism in the late '90s following a hot tip from a friend who worked for university IT (as well as NeXT tech support who graciously sent me a full OS media kit free of charge so I could actually use it).
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.
The addition of frameworks like Qt and yes, web wrappers certainly complicates things unless you're presumably deep in it.
What isn't clear to me is whether Win32 is still technically a viable choice for "modern" Windows 10/11 development. In other words, could you submit a Win32 app to the Microsoft Store, if that was something you felt like doing?
> What isn't clear to me is whether Win32 is still technically a viable choice for "modern" Windows 10/11 development. In other words, could you submit a Win32 app to the Microsoft Store, if that was something you felt like doing?
I believe so, although originally the store required other toolkits, they changed thier mind.
That said, I don't think it's very important for windows programs to come from the microsoft store... the limitations are not worth the market, especially since the store is unreliable: at least in my experience, the installation can get messed up and it won't self repair, and then you can't install new software... Why would you want to support that, when you could just provide a downloadable installer and license keys? (And tell people the sequence to escape store only mode)
Don't get me wrong; I absolutely refuse to use the store.
I'm just not deep enough in this to know the correct terminology. What I think I'm trying to ask is whether Win32 is still considered viable / equal opportunity compared to something built with, for example, WinForms. (To pick a name I remember.)
From the outside, all of this churn makes me completely understand why web wrappers are so popular.
Yes, because anything WinRT has been messed up, it was going well between Windows 8 and Project Reunion, as it was progressively getting feature parity with Win32, then everything went downhill and you can safely ignore anything from Microsoft marketing related to WinUI/WinAppSDK.
It was so bad that on BUILD 2024, WPF regained its official status out of deprecation.
So, Win32 (+ COM, most new APIs since Vista are COM based), Forms, and WPF, or oldie MFC, if on Microsoft own stacks.
Otherwise Delphi, FreePascal, C++ Builder, Qt, Avalonia, Uno if going 3rd party.
Don't get me wrong; I actually appreciate the breakdown. It just makes me not want to even consider native Windows development. This is definitely an example of too many choices being a very bad thing.
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!
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.
Presumably you're talking about /SUBSYSTEM:NATIVE, and while you're correct that it changes the default entry point (to NtProcessStartup in this case), it also sets the Subsystem field in the PE optional header to IMAGE_SUBSYSTEM_NATIVE, which causes CreateProcess to fail to start the executable with ERROR_CHILD_NOT_COMPLETE ("The %1 application cannot be run in Win32 mode.").
To see this, try press Windows+R and try running C:\Windows\System32\autochk.exe.
There are workarounds, but AFAIK there's no officially supported way to launch a native executable.
But that doesn't matter unless you want to avoid creating Win32 process structures, loading default Win32 DLLs, etc., as no windows are created and no messages are dispatched by code other than your own unless peculiar startup code is injected into your process at load time.
In particular, you have access to untranslated messages by default, and if you don't want translated messages to be posted, just don't call TranslateMessage in your message loop.
"GetMessage" can do a lot of things you don't expect it to do. Ever used a global keyboard hook? Your keyboard handler code is called because "GetMessage" is calling other functions to have it get handled.
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.
Here's the thing, you absolutely can do this in exactly the same way: Make the background transparent and draw within the bounds. You can argue about whether or not you should, but that is the argument. There's no technical limitation.
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.
The weird windows were a fun fad for sure, but thankfully, a fad. Winamp was probably the best example of a program with an OS agnostic UI that didn't seem too out of place. It stood out for sure.
I agree on the memory usage of electron apps though. Been using Slack for 10 years now and it has never been slower. A freshly started Slack app on my macOS takes up nearly 1GB. It's nuts imho.
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.
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.
I remember some of the malarkey done with the X11 SHAPE extension. There was a program called xmascot. You could give it an xpm of a character or use one of the presets—typically a cute animal of some sort or a chibi anime waifu. It would show a dangling figurine of this character right on your desktop, autogenerating a few frames of rotation so it could swing from side to side.
Of course X11 is four olds, and there's probably some security justification for not having nonrectangular windows in Wayland, and/or "that's a compositor implementation detail and outside the scope of the Wayland protocol".
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.
> that has nothing to do with React and Electron
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.
I use probably 70% Windows, 20% iPad, 5% Meta Quest 3 [1], and 5% MacOS -- for the latter though it is mostly "test that something works on MacOS" and "tech support for the computer the family uses".
I like web-based applications that behave the same everywhere. Personally I feel the MacOS widget set is a touch old fashioned, a little ugly and gauche. I can see though why somebody might like the MacOS terminal better than CMD.EXE. The dominant theme on Windows is that Windows has several widget sets that aren't consistent but the average user doesn't notice or care -- probably the worst area is the settings dialogs which seem to be mostly migrated to a Metro-based design lately. I was afraid before they wouldn't finish that migration before they churned to another framework but I think they've stopped the churn.
The best windows applications, in my mind, steal from web technology -- like they are either using some kind of HTML-based UI or they are made by people who grew up making web applications and reproduce those patterns w/ the desktop widget sets.
[1] I've got some web applications I wrote that run perfectly on the MQ3, especially after I got target sizes up to WCAG AAA level and it is fun to put the headset on and crash out on the couch and get things done
> I've got some web applications I wrote that run perfectly on the MQ3, especially after I got target sizes up to WCAG AAA level and it is fun to put the headset on and crash out on the couch and get things done
One way to have better text in VR for 2D content is to make use of OpenXR composition layers:
https://developers.meta.com/horizon/documentation/unreal/os-...
Don't worry, not Unreal specific. Hope it helps you out!
> But I prefer very much any third-party multi-platform app to be identical everywhere I run it.
Apps that disregard platform standard behaviors are poorly-written apps. Whether they happen to be cross-platform or not is irrelevant.
> they don't follow platform guidelines
I don't think platform guidelines that anyone listens to have been a real thing for a long time. Even between apps released by MS there is little or no consistency at times, things that should be part of standard OS provided chrome like title-bars are a random mess - good luck guessing what has input focus sometimes, particularly with multiple monitors, as you unlock or switch vdesktop, without clicking to make sure.
I keep thinking of writing something that detects the top-most app window and draws an obvious box around it.
Native macOS developers respected Apple's Human Interface Guidelines for a long time, but even that's declining now that everyone needs to work around all the problems with Liquid Glass.
Yes, Liquid Glass is atrocious and it's the reason why I'm not going to buy a new Mac.
>> I keep thinking of writing something that detects the top-most app window and draws an obvious box around it.
I would use this in a heartbeat. With Windows 10/11 I usually have the option to apply a garish accent color to the active window active. Nowadays, more and more apps don't use native window frames anymore, so that option works less and less.
The W11 task bar with its barely legible indicators doesn't help either.
On a big ultra-wide display with a few windows open, I sometimes struggle to see which one is active.
> > I keep thinking of writing something that detects the top-most app window and draws an obvious box around it.
> I would use this in a heartbeat.
I may one day get around to it. Of the many projects on my “will probably never actually happen” list¹ it is one of the smallest. I did something similar to add other decorations to windows back in my just-post-Uni days². Walking the process list, getting the hWnd(s) you were interested in, and for there the window dimensions, was fairly trivial and it no doubt still is.
----
[1] I mention them here where relevant, in the hopes that someone else will see the ideas and be inspired to implement the them in an open form so I don't have to :-)
[2] ~win2000 era, I was playing in Delphi at the time
> they don't follow platform guidelines
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.
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.
> Yeah, weird-shaped windows are definitely not something that should make a comeback. Just because you could doesn't mean you should.
My opinion here is the exact opposite of yours. Make computers cool again! They used to look like an alien spaceship, now everything looks like paperwork.
We can make it cool again! We can make it fun.
All the fun parts of life are optional.
I'm with you. It's fine if your opinion is "software = tool" and you personally want it to be utilitarian and basic, but plenty of us desire our software interfaces to have personality and customization. The answer is that we should have the option to choose.
I use computers for a plenty of fun, but those programs always were the digital equivalent of garden gnomes. Utterly kitschy. Just having a basic sense of aesthetics doesn't imply thinking that computers should be dull or just for work.
I don't know. They look cool. If someone wants to bring them back it's a viable option. I'd definitely welcome it.
Agreed. I remember seeing quite a few non-standard designs in the days of Vista, especially when Microsoft was heavily promoting the Windows Presentation Foundation framework and using XAML for UI design.
The problem with setups like this is that the moment you need to resize them, place them in a specific spot, or move them to a larger or smaller monitor, they tend to scale terribly and end up causing all kinds of “death by a thousand cuts” issues.
It would help if you had seething more specific to say about usability rather than blindly defending the bland conformity: for example, if your music player app looks like your physical old round CD music player, not a rectangle, how exactly does it hurt usability?
> Applications that implement their own widgets or color schemes or nonstandard shapes usually pay zero attention to usability or accessibility.
OS are close to this, pick any era of the constantly changing OS color schemes and widget design, and you'll find plenty of issues, with the basics of the basics - readability - suffering.
So again, why should everyone be generically bad just because they wrote the "guidelines"? Sure, change doesn't mean good, but the neither does using the defaults
Quite. And the era when everyone was trying to "do their own thing" with UI design wasn't exactly pleasant or usable. Just have a look at some of these designs, for example
http://hallofshame.gp.co.at/mshame.htm
Ahh, but I do miss all the weird phones from 1998 - 2008.
I think it's ultimately the same process at work.
There's a wave of "desktop games" on Steam. Most of them are Idle genre or tamagochi like.
For those I find these exoctic shaped windows are fun and a great differentiator.
Example:
https://store.steampowered.com/app/2666510/Rustys_Retirement...
Bundle with a ton of these games:
https://store.steampowered.com/bundle/48558/BottomOfYourScre...
Adobe is a notable holdout in refusing to go native.
Not to mention that the statement is wrong. Windows applications do NOT look the same, and that's bad.
Oh... except for their lack of a title bar, which prevents you from telling which application you're looking at. Is this PDF open in Edge, or Acrobat? Who knows. The windows look the same.
Beyond that... it's a disgraceful mess. You have applications now with no menu bar, but instead a bunch of hamburger buttons and "gear" buttons scattered all over the place. And common, standard functions like "save file" are further hidden behind "more" labels even in THOSE menus.
Another example of Windows's galling regression: the abolition of the File dialog in many apps, which have replaced it with a giant page of crudely-drawn, unlabeled, super-wide text boxes and a bunch of plain text. There's no file structure shown, so you have no idea where you are about to save a file... It's truly a clinic on dogshit UI. Pathetic.
Companies like IBM and Microsoft did a lot of HCI research back in the 80s, and made a lot of progress with usability and common idioms that all software followed. Then when displays with 256 or more colors became common, all that went out the window.
All those Windows Media Player skins were awful because they used so much screen real estate on dead space. Whereas the plethora of Winamp skins kept the economy of screen real estate while still providing unique and imaginative visuals.
The whole skeuomorphic trend starting in the mid-90s was similarly awful for the same reason. First, it was often hard to tell what was a control and what was just decoration. Second, it often took trial and error to figure out what was what. And, as I mentioned above, these designs almost inevitably wasted huge chunks of screen space on decoration that provided no functionality.
Of course, we have the opposite problem now. All windows look the same. Title bars are mostly gone. And since companies like Microsoft replaced all their HCI experts with art-school dropouts who think the "flat" look with low contrast is cool, not only can you not tell what app you're looking at. Half the time you can't even tell where one window stops and another starts.
The only good UI thing that's come out of the last decade or two is a near universal support for "dark mode". Otherwise, I would greatly prefer the Windows 2000 "classic" look, or something similar.
I agree with your sentiments, but not your timeline. The mid-'90s was the high point for GUIs, with Windows 95 nailing it pretty much across the board.
And as you note, "flat" design is NO design. It's total dereliction of the design task. Fortunately we're seeing some steps back toward legitimate GUI, where controls are occasionally demarcated as controls.
A great example of Windows's pathetic regression is "dark mode." Since the early '90s (and I mean '91 or '92), you could set up a system-wide color scheme. Inverse color schemes were an unfortunate vestige of the late '80s, early '90s... the advent of the Mac, "desktop publishing," and the effort to make the screen an analog for a piece of paper. That analogy fails.
The result was millions of people reading black text off the surface of a glaring light bulb all day, every day. The first thing I did was set up a charcoal theme in Windows, pretty much exactly what all the "dark" schemes are today. And all properly written applications inherited it and all was good.
So... just in time for people to realize that this was the way, Microsoft REMOVED the color-scheme editor from windows. Only to have to hastily slap a hard-coded "dark mode" back onto the OS. So damned stupid.
You're thinking of apps for work. There's no reason why people should not be able to have fun when not working
Am I? Why would you assume that? Do you think that usability and accessibility are only important for work?
I'd rather weird windows everywhere than material design everywhere.
I'm all for Win32, but those odd-shapes and custom skins were the precursors and the normalizing precedent 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!
It's the worst of both worlds. Not only are the bland, but they don't even follow the platform's conventions, have horrible accessibility (because they no longer get it for free from the platform), and don't respect my desktop environment's theming, fonts, colors, and so on.
If I want to release a native app ASAP, I would chose .NET, Delphi, C++ Builder, Qt,...
If it has to be Web stack, it would be hosted somewhere and delivered as a proper Web application.
I think they want an app, but prefer to use web stack, so that's the result. The reason they want an app instead of a web application, is maybe an app gives them more control.
Which gives the worse of both.
Web development has been part of my life, on and off, since around 1998, and I never shipped browsers inside applications, not even during MSHTML glory days.
Either proper application, or delivered to the already installed browser.
I even refused a job offer where that was going to be part of it, some Electron like thingy.
Nowadays true native app work is very limited and many companies just use Electron. Oh well.
For your average business app, yes, I agree, however there are a lot of apps I use on my iPad that have essentially moved this "custom skin" UI into elements in a full-screen wrapper and they look and work wonderfully. There are also lots of smart devices that have hyper individualized UIs, modern cars, anything in the audio realm with a screen, plenty of examples.
But yes, you're showing a series of forms to fill out? Use the platform native controls and make it work perfectly.
> 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.
> 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.
The docs are great too.
Of course absolutely ancient, but once you learn how to read them, they're very comprehensive.
And the 3rd party content written about win32 is pretty evergreen. I regularly find articles written in the '90s that are helpful today. The beauty of an incredibly stable API, and documentation written before everyone had the internet.
Just like the frontend dev ecosystem. Wait...
> skeuomorphic design
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.
> 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.
Another way to say this is: cost cutting. We gave up superior usability so software could be made more cheaply. See also: replacing buttons and knobs in cars with a big iPad.
I think HiDPI is another reason - these were from the "96 DPI" era where pixels looked the same on every screen. You can draw all your pixel art at 2x (or 3x) and scale it down at load time, but it's not super easy. Also, some of the RAM usage of modern apps is the need for a full backing store for each window - in the "true" win32 days like Windows 95, XP, or Win7 in classic mode, you'd be drawing directly to the front buffer, with no extra RAM/VRAM usage per pixel. Of course it flickered and looked bad, but it was fast and cheap.
The two root causes of these sort of windows disappearing is what you've said (DPI) and just a change in tastes.
People now view those styles as kind of garish. Between that and the difficulty of making it work and look good at a variety of DPIs, it just wasn't going to stick around.
I admit, I like things to have some more color and texture. Simple black and white boxes are a bit soul crushing. But I see why they disappeared.
> The point was usually not usability. It was identity.
Is it bad that when I read that I immediately thought "this was written by an LLM."
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.
Every single line in this article was written by an LLM...
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.
My memory from the old days is you can use Win32 hooks to modify the MessageBox. HCBT_CREATEWND gets you the HWND of the MessageBox, and you can subclass it (in the Win32 sense) to insert your own WndProc. Then you're off to the races--it's your dialog now.
But it wasn't just one window, there were lots of controls on that window and the relationship between them wasn't as obvious as you'd assume. Trust me, recreating the whole thing from scratch was easier.
The fun part was making a C++ class that could build up an in-memory dialog template. You had to do it that way because it was dynamically sized based on the message you displayed and the buttons you needed. If you used the default colors, you might be able to tell they were different if you squinted but you wouldn't know which was mine and which was Microsoft's.
I've done this for real, in commercial code that shipped. No trust needed; I have personal experience. For typical minor MessageBox additions, this can be easier than rebuilding the whole dialog yourself. Sometimes, we just wanted to add a "Don't ask again" checkbox which didn't require touching the existing child windows at all. I also used this technique to simply change the labels on the buttons to custom text. I had a MessageBox wrapper that accepted a list of button strings instead of a predefined constant. We've all built various custom message boxes, of course, but not every situation required that level of effort.
These days you can just use a TaskDialog, of course, and it's way more flexible than MessageBox. But it's fun to remember the old techniques.
You can modify this stuff if you go deep enough and are willing to detour the native Win32 API functions. Some things implemented in User32.dll don't make the appropriate API calls back to other User32.dll functions, and you need to detour Win32U.dll instead.
Wow this could be painful, to try to recreate something from scratch. Would QT make it work?
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.
The biggest problem was when there was an established protocol, but it wasn't always followed. I remember scroll bars being the worst. Usually you could respond to the messages and everything would work the way you want, but there were some edge cases where Windows would update those scroll bars without even telling you it was doing so. And of course it would paint those updates in the default colors.
I honestly don't know if Qt would have made it any easier. But this was a large and old app that relied on Win32 at its core, and nobody was going to accept rewriting it for just one feature. Plus our customers were very time sensitive, and anything that could have slowed it down by a few ms was off the table.
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 and 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.
To my delight, The article also mentioned desktop mascots! I saw a cool video recently where someone made a desktop pet in Godot, and it seems to be cross platform as well.
It seems to be a little fiddly, but not quite win32 level fiddly :) So, maybe a more approachable option for the desktop pet enthusiast.
https://youtu.be/x8BO9C6YtlE
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.
> A freaking notepad app takes almost 50mb in memory when equivalent NOTEPAD done in pure Win32 C takes 1.8mb of memory.
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
Even a minimal Hello World program (1.5KB executable) takes 340K of active private working set, and 552K of commit size. Windows just don't allow programs to use any less memory than that. You're bound by what the system libraries allocate (either statically or dynamically).
Once you create a window, even if you haven't drawn that window, your minimum is now around 500KB.
Given that I assume NOTEPAD.EXE is still basically a window containing an optional status bar and a multiline edit control with a custom WNDPROC for managing features like word wrap, I'm actually curious why it opens with such a large private working set, even on Windows 11.
Possibly space for data allocated by one of the 50+ DLLs it loads directly or indirectly to support features like Unicode text input and rendering.
Actually, it gets much worse. By default, recent Windows 11 versions use a completely new version of Notepad with support for things like tabs, styled text, and AI (!).
Even with all the new features disabled, this one has a 32 MB private working set before opening a single file.
Amusingly, GNU Emacs, a.k.a. Eight Megabytes And Constantly Swapping at a time when entry-level UNIX workstations actually shipped with as little as 4 MB RAM, opens on the same machine with a smaller (25 MB) private working set than the new Notepad.
To be fair to at least one team at Microsoft, the EDIT.EXE text-mode editor recently added to Windows 11, with a user interface that somehow manages to be more consistent with basic Windows UI conventions than many modern Windows GUI apps despite not being a GUI app at all, opens with a private working set size of only 520 kB.
Window transparency is available on all major platforms, and there are cross platform libs which support it, such as SDL3: https://wiki.libsdl.org/SDL3/SDL_WINDOW_TRANSPARENT (for rendering, making underlying windows visible where window surface pixels are transparent), https://wiki.libsdl.org/SDL3/SDL_SetWindowShape (for input, making pointer events pass to underlying windows where surface pixels are fully transparent)
I (ab)use it in my image (pre)viewer to have image presentation area always fitting image during pan&zoom without window borders limiting it, while having underlying windows visible outside of it (transparent fullscreen overlay): https://github.com/shatsky/lightning-image-viewer
> 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.
> Unused memory is wasted memory.
Why does my computer freeze and become unusable when the RAM is 90%, then? That myth is complete nonsense - RAM is like a seatbelt or a crumple zone, serves as a buffer between the user and crashes, and will hopefully never be tested under use.
Article only mentions manually building an irregularly shaped region from an image
> Every horizontal run of non-transparent pixels becomes a tiny rectangle region, and those runs are combined into one final window region
but there's an easier way: you just use a LWA_COLORKEY with SetLayeredWindowAttributes to make a color transparent, like a green screen. I recall building my own desktop mascot that way. Doesn't work with arbitrary image/content of course since the color can't appear in the content region.
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.
Editing this to add: I really miss that level of coding and working with Win32. I get that the world has moved on and HTML or some runtime flavour of it has taken over but I too lament the los of true control I once had. I hate that my stack can be broken because some runtime was updated out of my control or the crazy load times of simple projects. I know many today would say it was messy and problematic (and it could be) but it's definitely a lost art form.
Also the 3 pane GIMP experience.
I think that's just how early Mac Photoshop worked. So they copied that and didn't update it for decades.
Sonique media player, Trillian messenger and NeoPlanet web browser. I was there, man. Before flat UI and sensible color schemes took hold. For a moment, it was pretty wild.
https://en.wikipedia.org/wiki/Trillian_(software)
https://en.wikipedia.org/wiki/NeoPlanet
https://en.wikipedia.org/wiki/Sonique_(media_player)
Minor trivia: the original motivation for adding SetWindowRgn was for Microsoft Bob characters and speech bubbles.
> Desktop UI culture shifted from “look at this crazy skin” to “work reliably and get out of my way.”
I miss the wobbly windows I had in Linux when we started playing with Compiz.
Or neko on my Sun machines.
As for weird-shaped windows, I think it is about ergonomics. A different shape requires more thinking to operate. Form should follow function, not the other way around - if the odd shape serves a purpose, then it makes sense. If it's just to show off, or to make the app look different, then it becomes a usability issue.
> I miss the wobbly windows I had in Linux when we started playing with Compiz.
KDE still has them: Settings -> Window Management -> Desktop Effects -> Wobbly Windows
I don't, though I still have fond memories of olwm, AfterStep, and WindowMaker, as well as the NEXTSTEP 3.3 GUI running on greyscale NeXT hardware fished out of a dumpster behind the Indiana University School of Journalism in the late '90s following a hot tip from a friend who worked for university IT (as well as NeXT tech support who graciously sent me a full OS media kit free of charge so I could actually use it).
Olwm was gorgeous. Elegant and stays out of the way.
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.
From what I understand, there's now a substantial stack of Windows app frameworks from Win32 to MFC and then 4-6 others that came after. There was a good post covering this last month: https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-...
The addition of frameworks like Qt and yes, web wrappers certainly complicates things unless you're presumably deep in it.
What isn't clear to me is whether Win32 is still technically a viable choice for "modern" Windows 10/11 development. In other words, could you submit a Win32 app to the Microsoft Store, if that was something you felt like doing?
> What isn't clear to me is whether Win32 is still technically a viable choice for "modern" Windows 10/11 development. In other words, could you submit a Win32 app to the Microsoft Store, if that was something you felt like doing?
I believe so, although originally the store required other toolkits, they changed thier mind.
That said, I don't think it's very important for windows programs to come from the microsoft store... the limitations are not worth the market, especially since the store is unreliable: at least in my experience, the installation can get messed up and it won't self repair, and then you can't install new software... Why would you want to support that, when you could just provide a downloadable installer and license keys? (And tell people the sequence to escape store only mode)
Don't get me wrong; I absolutely refuse to use the store.
I'm just not deep enough in this to know the correct terminology. What I think I'm trying to ask is whether Win32 is still considered viable / equal opportunity compared to something built with, for example, WinForms. (To pick a name I remember.)
From the outside, all of this churn makes me completely understand why web wrappers are so popular.
Yes, because anything WinRT has been messed up, it was going well between Windows 8 and Project Reunion, as it was progressively getting feature parity with Win32, then everything went downhill and you can safely ignore anything from Microsoft marketing related to WinUI/WinAppSDK.
It was so bad that on BUILD 2024, WPF regained its official status out of deprecation.
So, Win32 (+ COM, most new APIs since Vista are COM based), Forms, and WPF, or oldie MFC, if on Microsoft own stacks.
Otherwise Delphi, FreePascal, C++ Builder, Qt, Avalonia, Uno if going 3rd party.
You can deploy any of them to the store.
Well, that's clear as mud.
Don't get me wrong; I actually appreciate the breakdown. It just makes me not want to even consider native Windows development. This is definitely an example of too many choices being a very bad thing.
Like the continuously fragmented Linux Desktop, or the multiple ways to do Apple UIs nowadays?
All desktops have issues nowadays, and many devs only make it worse by helping Google's takeover the Web, by shipping Electron crap.
Winforms is built on top of Win32, and you can use your own Win32 code alongside it, even overriding how a control behaves.
Win32 is allowed on the store.
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!
> Win32 does not revolve around an update loop you own
...How much more could you own it, really? Is that the LLM talking?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.
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.
Presumably you're talking about /SUBSYSTEM:NATIVE, and while you're correct that it changes the default entry point (to NtProcessStartup in this case), it also sets the Subsystem field in the PE optional header to IMAGE_SUBSYSTEM_NATIVE, which causes CreateProcess to fail to start the executable with ERROR_CHILD_NOT_COMPLETE ("The %1 application cannot be run in Win32 mode.").
To see this, try press Windows+R and try running C:\Windows\System32\autochk.exe.
There are workarounds, but AFAIK there's no officially supported way to launch a native executable.
But that doesn't matter unless you want to avoid creating Win32 process structures, loading default Win32 DLLs, etc., as no windows are created and no messages are dispatched by code other than your own unless peculiar startup code is injected into your process at load time.
In particular, you have access to untranslated messages by default, and if you don't want translated messages to be posted, just don't call TranslateMessage in your message loop.
"GetMessage" can do a lot of things you don't expect it to do. Ever used a global keyboard hook? Your keyboard handler code is called because "GetMessage" is calling other functions to have it get handled.
He means its about a message loop, as opposed to an update loop.
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.
Here's the thing, you absolutely can do this in exactly the same way: Make the background transparent and draw within the bounds. You can argue about whether or not you should, but that is the argument. There's no technical limitation.
https://www.electronjs.org/docs/latest/tutorial/custom-windo...
Is it not the fact that Win32 is not the dominant platform anymore? It would be mobile phones now, right?
No need to mess with Win32, Godot supports it: https://docs.godotengine.org/en/stable/classes/class_window....
There’s a resurgence of transparent apps and games just because of that.
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.
They're becoming more popular in Florida, as a poured concrete geodesic dome is basically immune to a hurricane.
So no one here has used winamp or seen an intro screen to a video game? Are you all chatgpt?
This article brings some flashback from Winamp skinning days.
Anyone else liked to skin they Winamp?
Oh yeah. Browsing the submissions and forums on customize.org are among my first forays into the internet.
How else would you whip the llama's ass?
You summon Wesley Willis of course (rip).
The weird windows were a fun fad for sure, but thankfully, a fad. Winamp was probably the best example of a program with an OS agnostic UI that didn't seem too out of place. It stood out for sure.
Besides custom outter shapes, you can as well have holes in your windows.
I agree on the memory usage of electron apps though. Been using Slack for 10 years now and it has never been slower. A freshly started Slack app on my macOS takes up nearly 1GB. It's nuts imho.
>A freaking notepad app takes almost 50mb in memory when equivalent NOTEPAD done in pure Win32 C takes [only] 1.8mb of memory.
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).
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.
I wish Skeuomorphism returned. I like that these apps were cool and distinct. They were also running in way less memory than electron apps.
This is bringing back some horrible memories. When product wants your app to have a slide-out that looks like a paper scroll...
This reminds me of the mid to late 90's warez scene, all of the key crackers had neat interfaces like this.
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):
* 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.
This starts out as a rant, wouldn't know how it ends.
It's good weird-shaped windows disappeared. They are a usability nightmare and override what theme that the users wants for himself.
Have they? I see stupid corner radius way too often.
is it possible to do this in linux?
Sure, in X11 https://www.x.org/releases/X11R7.7/doc/xextproto/shape.html
And for Wayland I found this
https://dev.tizen.narkive.com/AkKHZRHh/wayland-non-rectangul...
SDL3 can handle both Wayland and X11: https://news.ycombinator.com/item?id=47790895
xeyes must work somehow.
Yeah X11 even allows for holes in windows.
I remember some of the malarkey done with the X11 SHAPE extension. There was a program called xmascot. You could give it an xpm of a character or use one of the presets—typically a cute animal of some sort or a chibi anime waifu. It would show a dangling figurine of this character right on your desktop, autogenerating a few frames of rotation so it could swing from side to side.
Of course X11 is four olds, and there's probably some security justification for not having nonrectangular windows in Wayland, and/or "that's a compositor implementation detail and outside the scope of the Wayland protocol".
Weird window shapes were really great when you were seated at a desktop computer. Not so great on laptops. Not viable on tablets or phones.