Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Asking the obvious question: why aren't the UIs in newer Windows versions not "just" different themes over Win32 widgets? Instead the UI theme seems to be tied to UI frameworks which seem to be created and discarded annually at Microsoft, so each time some genius decides to overhaul the UI, a completely new sediment layer is created instead of letting some UI designers tinker with a theme editor.

I don't get it. Functional UI changes should be different from visual fluff, yet Windows seems to the only OS where the two aren't separated.

View on HN

This was historically the case, it's why despite the article calling out winver, folder properties, the run dialog as being from the win9x -> win2k period, they didn't look remotely as out of place in win7 as win10.

Of course there are limits. iirc Windows 7 RTM had an obviously 3.1 derived file picker make it into the add fonts dialog until it was replaced in SP1 if my memory has the timing right. Despite using win32 widgets which had the correct theming, that didn't look native at all

FWIW: I consider fixes like the improved environment variable editor in the "old" system control panel in Win10 much more important than the entire new settings panel mess. The same type of improvements would make a lot more sense for the rest of the builtin UIs instead of creating entirely new "construction sites" all the time, which will be left incomplete and outdated in a few years time as the current people are replaced with new people.

There is no such thing as canonical “win32 widgets.” There have always been several different UI libraries even for win32. The original win32 styling you get with CreateWindow doesn’t support modern font rendering, high DPI, doesn’t work well with touch, is only software rendering, doesn’t support latest accessibility features, etc.

The newer stuff sits on top of DirectX.

The latest UI framework (XAML/WinUI) sits on top of a better rendering architecture (compositor) that itself wraps DirectX tech.

There's no reason why the old Win32 window and widget foundation couldn't have been lifted on top of a modern rendering architecture though, there was certainly enough time to achieve this. This would also reduce the need for creating entirely new UI frameworks every year (or even better, higher level UI frameworks could be built on top of a modernized but backward compatible Win32 widget foundation instead of doing all their own rendering directly on top of DirectX).

(TL;DR: the Windows UI mess looks to me like an organizational problem, not a technological problem. From the outside it looks like as the old guard is leaving, the new people coming in discard all the old code and instead prefer to start completely new projects, which of course is destined to fail, because the new people are repeating the same errors which had been identified and fixed decades ago).

If you listed out all the requirements a modern UI framework needs you would find that the original Win32 UI API’s are not viable. Especially if you want to support more than just C and C++.

So much code is required to do things we now take for granted that the resulting patterns became new frameworks.

The Apple APIs date back to NeXTStep at the end of the 80s, yet they managed to mostly keep them fresh.

Win32 is old and unviable because Microsoft hasn't bothered making comprehensive upgrades for it and never laid out a gap-free plan for how to move off it. They could have upgraded it more smoothly but never did.

My experience with apple has not been smooth at all, it has been one of deprecating without concern for compatibility.

> The latest UI framework (XAML/WinUI) sits on top of a better rendering architecture (compositor) that itself wraps DirectX tech.

WinUI/UWP still uses CreateWindowEx and good old WndProc for event loop message handling at the top level on Windows 10.

I guess one challenge with this is that old school Win32 doesn't really support anything resembling automatic / responsive layout. All controls are of a fixed size in a fixed pixel location. This means you can't for example change the default font, add margin or padding or do any other significant changes without essentially breaking all existing applications.

We had layout managers in the 90s, perhaps not in the 80s.

> I guess one challenge with this is that old school Win32 doesn't really support anything resembling automatic / responsive layout.

It gives you all the building blocks to implement it yourself.

Remember that Win32 is not UI framework but OS API which allow you to build yourself one (wxWidgets, QT, SWT).

That's not quite true. Win32 apps that use CreateDialog use absolute positioning for widgets, but the "dialog units" used for that purpose are specifically defined to scale with DPI and font size (one DU is defined as "average width and height of characters in the system font").

Reply on news.ycombinator.com