Just looking at Explorer:
- The window itself is a regular Win32 window
- It hosts a WinUI island or such for the top toolbar
- The navigation bar is a ReBar with all custom Win32 widgets
- The content view is a DirectUI widget
You'd think that if they'd standardise on a single toolkit (like macOS with Cocoa) they'd be able to get better results with much less work. Perhaps this is an organisational issue?
If Windows would change the Win32/Winforms spacing and such I wouldn't want to be the developer that gets to keep all the pieces broken off.
Read some Windows Terminal blog entries, they're very enlightening. They're basically working around a huge minefield of compatibility and trying to get things moving again. It's quite a feat of real software engineering, what they're doing over there.
It's woefully antiquated feeling next to Finder. Seeing it struggle to scroll folders with 10,000+ items it can't even load them all in at once you have to scroll bit by bit, seeing it choke reading MP3 file folders because it's trying to do some dumb WinXP era metadata reading on an ancient code path. Seeing it unable to search for files on a sensible timescale or even accurately.
It's infuriating.
Oh god no. They’d nuke all the keyboard shortcuts, make everything take 20x more space, remove any advanced features such as keying by non-primary column, sorting by weird file-specific metadata, etc, add loading screens everywhere, make even the most basic operations require an async dispatch to a runtime host, break credentials authentication with the OS keystore, remove IME and input accelerators, nuke integrations with 3rd party apps for menus, overlays, and previews, hide file extensions, run always in fullscreen, break ClearType text rendering, block access to any system files, break the elevated operations workflow, remove access to non-local files, use 20x as much memory, crash at startup, break when an update ships out-of-band on an older patch release, and then be rewritten in four years.
Why stop at Carbon if you count removed frameworks? They had Classic and X11 too! And HyperCard!
Catalyst is expressly for porting iPad apps. So it's just SwiftUI and Cocoa if you compare macOS to Windows.
This just reveals Microsoft’s prioritization of UX consistency. Whatever the priority is, it’s not enough to overcome the perceived cost of creating consistency.
It also shows why Windows can be a strength: still runs almost everything anyone ever made for it.
Now, I completely understand if some third-party program developed twenty years ago looks inconsistently. I even understand if some recent third party tool also looks inconsistently. But here we're talking about the software that is shipped with Windows and it's created by Microsoft directly. These are examples from Edge, Explorer, Settings, etc. This is more than having a low priority for consistency, this is Microsoft not even considering the possibility of consistency.
I have not tried Windows 11. But I'm baffled to find that in Windows 10, Microsoft still ships parts of its own UI that are not high-dpi ready. They seem to have zero problem showing dialogs with scaled pixelated text.
MacOS couldn't be more opposite in this regard. Linux I also dislike for this reason.
It's expect you compile your own programs, but more often than not it'll fail if the project is abandoned for 5 years (purely anecdotal).
In contrast with the earlier comment about how poorly Apple fares on backcompat: they have twice (thrice, actually, counting 68k->PPC) successfully made breaking platform changes where old software kept working with no required intervention by users or even knowledge it was happening.
Not everyone has been happy with Apple’s deprecation strategy, but there’s no technical reason MS couldn’t use their subsystem prowess to gradually move old technologies out of the core OS into sandboxed environments.
The reason they don’t is partly cultural—the compatibility at all costs trope is real—but I think it’s mostly a combination of lack of motivation and a recognition that the ecosystem produces a lot of abandonware that would quickly show seams.
Shipping an OS where some bits of UI date back to Windows 3.1 is never going to lead to a seamless experience.
Guess what, I am 100% sure they do the basic for Win32, make some efforts for WinUI 2.0 (UWP) and WinUI 3.0 (the Win32 one) and that's it.
The Win32 widgets have been updated but apparently they don't want to mess with the metrics, hence those controls are much more compact, don't use rounded corners, etc.
Is there any public UI toolkit in Windows now that offers the canonical widgets?
The WinUI 3.0 (which is UWP decoupled from OS + UI) is still catching up.
https://docs.microsoft.com/en-us/windows/apps/winui/winui2/r...
Thing is, for Win32 anyone using bare bones Win32 has to do the work themselves for anything that ins't on the OS anyway.
So MFC and Forms get a partiall update via those Win32 changes, while WPF gets nothing due to its own DX rendering stack.
https://docs.microsoft.com/en-us/windows/apps/get-started/ma...
As they pivoted back into Reunion and merging Win32 and UWP worlds, new teams were created, so....
In fact already during the Win16 days, many of us were already jumping into C++, Delphi and VB frameworks, instead of suffering through plain C programming.
Borland common controls used to be quite easy to spot with their green check mark.
Win32 has very few built-in controls, and Windows always enjoyed a good ecosystem from commercial vendors selling custom controls, like Telerik and ComponentOne to refer to two well known ones.
As historical info, modern COM traces back to Visual Basic VBX components.
Win32 is quite basic in the set of controls available, almost everything in traditional Win32 applications is custom drawn, beyond what you also find the HTML forms as components.
Then there are all commercial components that are so common in Windows applications.
However if you will, the future is WinUI/UWP, and that is the only one getting full Mica support.
Windows happens to have such legacy support and lack of product direction that’s it’s now layers and layers or turds.
In some cases, APIs wouldn't be too much of a hindrance, and one could replace one toolkit by a later version with updated designs. But the designs themselves also do have a lot of compatibility problems: It is uncommon in the Windows GUI world to use layout managers (similar to CSS flexboxes and the like) that automatically adapt to different window and UI element sizes. Instead, most widgets are positioned pixel-wise. That is also why most dialogs are non-resizeable and things break e.g. when translated strings have different lengths. So a new design which changes sizes breaks all the pixelwise layouts everywhere.
tl;dr: Windows GUIs and toolkits are usually not designed with compatibility and resizeability in mind and break if you change the looks of anything (beyond just changing colors).
The problem with opt-in flags is that it still requires active application developer work (keeping up to date on dependencies; sometimes worse, keeping up to date on future dependencies and learning their restrictions needs) and still can't solve the inconsistency issues from applications developed by people that don't exist anymore or don't have a maintenance budget or the source code was lost or…
Manifests are a thing since Windows 2000, as they were also introduced to sort out registry issues, and go back into xcopy deployments.
Yet even Microsoft's own teams keep putting into the registry what should be in manifest files.
More often than not they don’t even look designed.
But more modern toolkits like WPF are much closer to html in their function. A text box is a white rectangle with a cursor. If you want to add autocomplete, placeholders, a magnifying glass icon in the edge - you put it there yourself.
So basically, making a text search field in Windows now is the same as making it for a webpage. The toolkit doesn't have options for adding autocomplete, placeholder text or icons. I think this is the correct API design, because controls that could do everything would be very difficult to work with.
That said, there should have been some utility or standard library to make it easier to be consistent, such as creating a "system-standard search box" which would then simply do all the gluing that is required for adding the necessary bells and whistles.
I'm sure there is both documentation and utilitiies for doing exactly this - but the problem is that it's so hard to find because everything keeps moving. Ironically I think internal ms devs feel the same way.