7 ms·

As someone who hasn't had to use Windows since XP, is anyone able to explain the technicals of how this even happens? I mean, at a complete OS layman's level, o

As someone who hasn't had to use Windows since XP, is anyone able to explain the technicals of how this even happens? I mean, at a complete OS layman's level, one would assume that someone somewhere comes up with the design for how a text input should look across the OS, someone else probably writes the UI code for that, someone else maybe writes the plumbing for it, then _everyone_ uses it whenever they need a text input. What is it about Windows that means this is impossible? Their UIs are like the jumble sale aisle down the middle of Lidl.

pjmlp 5y ago
Easy, they need to make sure Win32, MFC, Windows Forms, WPF, UWP and WinUI (basically UWP on Win32 without going into details) underlying rendering infrastructure gets aligned with the OS design language. 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.
- sjmulder 5y ago
  > Guess what, I am 100% sure they do the basic for Win32 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?
  - ktpsns 5y ago
    Probably third party toolkits such as wxwidgets or Java AWT (the Swing predecessor)?
  - pjmlp 5y ago
    Kind of, only for WinUI 2.6, the UWP version. 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/release-notes/winui-2.6 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/make-apps-great-for-windows https://docs.microsoft.com/en-us/windows/apps/get-started/ma...
    - sjmulder 5y ago
      Looks like WinUI 2.6 is the way to go then. But I'm surprised that there doesn't appear to be any sort of official built in canonical thing with standard widgets (like what Win32 used to be). All these separate frameworks are implementing everything for themselves.
      - pjmlp 5y ago
        That train departed long ago. 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. https://en.wikipedia.org/wiki/Visual_Basic_Extension https://en.wikipedia.org/wiki/Visual_Basic_Extension
      - ectopod 5y ago
        WPF is nuts. It appeared to have native controls but in reality they reimplemented everything, with a unique style definition for every control on every supported version of Windows. It would have been a huge amount of work. It seems like they haven't bothered to keep up with it as control styles have evolved though.
        pjmlp 5y ago
        If you check the github issues and community talks on YouTube, it is quite clear that when Microsoft went full steam with WinRT, most likely the remaining UI teams got ramped down. As they pivoted back into Reunion and merging Win32 and UWP worlds, new teams were created, so....
- drcongo 5y ago
  I get why they'd need to support all that for 3rd party app backwards compatibility, but surely for their own OS they can just use the current toolkit for everything? They own it after all.
  - pjmlp 5y ago
    What is the current toolkit? 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.
sjmulder 5y ago
I think the core problem is that they all use different toolkits. The design teams come up with these great widget designs and then they all have to be implemented on a per-toolkit or even per-app basis. 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?
- oblio 5y ago
  MacOS breaks compatibility regularly. 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.
- whywhywhywhy 5y ago
  Really wish they'd just completely rewrite Explorer from the ground up. 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.
  - jcelerier 5y ago
    at some point you could use KDE's Dolphin on windows, that was awesome
  - ComputerGuru 5y ago
    > Really wish they'd just completely rewrite Explorer from the ground up. 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.
hughrr 5y ago
Yeah that’s easy. Rather than fix the last thing it’s easier to write a new turd from the ground up with the promise that it’ll solve all the last problems. Windows happens to have such legacy support and lack of product direction that’s it’s now layers and layers or turds.
AuthorizedCust 5y ago
Many generations of code and UX standards, all still supported. 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.
- spicybright 5y ago
  The fact I can open most exe files from 1993 today on my window 10 laptop and have it work nearly perfect is an incredible feat. 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).
  - datenarsch 5y ago
    While I agree this is great, it is not really related to and no excuse for the inconsistent mess that Windows' UI has been ever since the Windows 8 Metro disaster. Win32 UI (think Windows 2000) was perfectly line.
  - petepete 5y ago
    If I want to run an old program I'd rather do it in a VM and have a nice, lean, consistent, sensible OS.
    - oblio 5y ago
      You're a technical person. Grandpa would go: "VM? What's that???".
      - eyelidlessness 5y ago
        The answer to this is simpler than it seems: instead of dedicating your compatibility efforts toward a monolithic OS that runs everything, dedicate them toward make the VM/shim layer so transparent “Grandpa” doesn’t have to know it’s an implementation detail. 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.
corty 5y ago
Windows UI has always been a shambles. Each version of Windows, Office and VisualSomething has at least one new toolkit. It might even look the same as the other ones that came before it, but internally is a different library with different incompatible APIs, bitmaps, workings, etc. Third-Party tools usually also provide their own toolkits that are sometimes made to look Windowsy, sometimes not. 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).
- solarkraft 5y ago
  > Windows GUIs and toolkits are usually not designed with compatibility and resizeability in mind and break if you change the looks of anything More often than not they don’t even look designed.
- fenesiistvan 5y ago
  They could add an opt-in flag for this per process. So developers could just turn on some "moderngui" flag in their win32 apps and with some little adjustements most of the apps could be modernized.
  - WorldMaker 5y ago
    Those exist. The Win32 Common Controls libraries are versioned and applications can opt in to them with rebuilds. There are also "application manifests" where in some cases an EXE can claim that "I know I was built with an earlier version of Common Controls, but I do the right things with them and was built with forward compatibility in mind so please display them the newer way". 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…
C19is20 5y ago
...at least you know where to find the jumble in lidl. And, despite being occasinaly messy, they're often preferabke to shop than to work out wtf is going on in UI land.
alkonaut 5y ago
Initially, that was more or less how it worked. The older and closer to Win32 you are, the less customisable the look is. 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.

pjmlp 5y ago

Easy, they need to make sure Win32, MFC, Windows Forms, WPF, UWP and WinUI (basically UWP on Win32 without going into details) underlying rendering infrastructure gets aligned with the OS design language. 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.

sjmulder 5y ago
> Guess what, I am 100% sure they do the basic for Win32 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?
- ktpsns 5y ago
  Probably third party toolkits such as wxwidgets or Java AWT (the Swing predecessor)?
- pjmlp 5y ago
  Kind of, only for WinUI 2.6, the UWP version. 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/release-notes/winui-2.6 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/make-apps-great-for-windows https://docs.microsoft.com/en-us/windows/apps/get-started/ma...
  - sjmulder 5y ago
    Looks like WinUI 2.6 is the way to go then. But I'm surprised that there doesn't appear to be any sort of official built in canonical thing with standard widgets (like what Win32 used to be). All these separate frameworks are implementing everything for themselves.
    - pjmlp 5y ago
      That train departed long ago. 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. https://en.wikipedia.org/wiki/Visual_Basic_Extension https://en.wikipedia.org/wiki/Visual_Basic_Extension
    - ectopod 5y ago
      WPF is nuts. It appeared to have native controls but in reality they reimplemented everything, with a unique style definition for every control on every supported version of Windows. It would have been a huge amount of work. It seems like they haven't bothered to keep up with it as control styles have evolved though.
      - pjmlp 5y ago
        If you check the github issues and community talks on YouTube, it is quite clear that when Microsoft went full steam with WinRT, most likely the remaining UI teams got ramped down. As they pivoted back into Reunion and merging Win32 and UWP worlds, new teams were created, so....
drcongo 5y ago
I get why they'd need to support all that for 3rd party app backwards compatibility, but surely for their own OS they can just use the current toolkit for everything? They own it after all.
- pjmlp 5y ago
  What is the current toolkit? 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.

sjmulder 5y ago

I think the core problem is that they all use different toolkits. The design teams come up with these great widget designs and then they all have to be implemented on a per-toolkit or even per-app basis. 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?

oblio 5y ago
MacOS breaks compatibility regularly. 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.
whywhywhywhy 5y ago
Really wish they'd just completely rewrite Explorer from the ground up. 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.
- jcelerier 5y ago
  at some point you could use KDE's Dolphin on windows, that was awesome
- ComputerGuru 5y ago
  > Really wish they'd just completely rewrite Explorer from the ground up. 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.

hughrr 5y ago

Yeah that’s easy. Rather than fix the last thing it’s easier to write a new turd from the ground up with the promise that it’ll solve all the last problems. Windows happens to have such legacy support and lack of product direction that’s it’s now layers and layers or turds.

AuthorizedCust 5y ago

Many generations of code and UX standards, all still supported. 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.

spicybright 5y ago
The fact I can open most exe files from 1993 today on my window 10 laptop and have it work nearly perfect is an incredible feat. 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).
- datenarsch 5y ago
  While I agree this is great, it is not really related to and no excuse for the inconsistent mess that Windows' UI has been ever since the Windows 8 Metro disaster. Win32 UI (think Windows 2000) was perfectly line.
- petepete 5y ago
  If I want to run an old program I'd rather do it in a VM and have a nice, lean, consistent, sensible OS.
  - oblio 5y ago
    You're a technical person. Grandpa would go: "VM? What's that???".
    - eyelidlessness 5y ago
      The answer to this is simpler than it seems: instead of dedicating your compatibility efforts toward a monolithic OS that runs everything, dedicate them toward make the VM/shim layer so transparent “Grandpa” doesn’t have to know it’s an implementation detail. 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.

corty 5y ago

Windows UI has always been a shambles. Each version of Windows, Office and VisualSomething has at least one new toolkit. It might even look the same as the other ones that came before it, but internally is a different library with different incompatible APIs, bitmaps, workings, etc. Third-Party tools usually also provide their own toolkits that are sometimes made to look Windowsy, sometimes not. 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).

solarkraft 5y ago
> Windows GUIs and toolkits are usually not designed with compatibility and resizeability in mind and break if you change the looks of anything More often than not they don’t even look designed.
fenesiistvan 5y ago
They could add an opt-in flag for this per process. So developers could just turn on some "moderngui" flag in their win32 apps and with some little adjustements most of the apps could be modernized.
- WorldMaker 5y ago
  Those exist. The Win32 Common Controls libraries are versioned and applications can opt in to them with rebuilds. There are also "application manifests" where in some cases an EXE can claim that "I know I was built with an earlier version of Common Controls, but I do the right things with them and was built with forward compatibility in mind so please display them the newer way". 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…

C19is20 5y ago

...at least you know where to find the jumble in lidl. And, despite being occasinaly messy, they're often preferabke to shop than to work out wtf is going on in UI land.

alkonaut 5y ago

Initially, that was more or less how it worked. The older and closer to Win32 you are, the less customisable the look is. 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.