The Win32 widgets are scalable, actually. They support device-independent units out of the box, even in Windows 95.

The only people that say Win32 apps are scalable are the ones that haven't dealt with legacy code. There is jut too much legacy code that either doesn't work, or doesn't work correctly with HiDPI screens.

At a minimum, for a Win32 application to work correctly with HiDPI it needs to tell the OS it is DPI aware.

This is done by marking the application DPI aware using the settings found in the manifest file.

The manifest file is then embedded into the resource section of the application, which then lets the OS know the application will be handling it's own DPI.

So the reason many of those 'legacy apps' don't work with HiDPI is they don't have those required manifest changes in place.

That then means the OS does the DPI scaling on behalf of the application and that results in poor scaling outcomes.

So you enable it by editing the manifest file and embedding the manifest file, but with legacy applications the HiDPI scaling might not be calculated correctly, or something assumes Pixels or DIP incorrectly. It might be something in a custom control in MFC, or a library or DLL where the source is long gone and no one can update, or even worst something doing something via COM and VB6.

That is correct. You enable it with the manifest and then you handle the scaling in the application code.

> something assumes Pixels or DIP incorrectly.

These are exactly the types of problems legacy applications run into.

They will contain hard coded assumption in their code and many of those will be 'pixel based' assumptions.

Applications also have to listen for messages that indicate a dpi change (moving between screens) and recalculate and redraw everything for the new dpi. The legacy codebases which are easily retrofitted to do that are the stuff of myths and legends.

> Applications also have to listen for messages that indicate a dpi change

That is how a well behaved 'DPI Aware' application should work.

However, even for those badly written DPI applications that don't listen for those changes, the work around is to first make the required DPI changes and then restart those badly written DPI applications, as they will then pick up those DPI changes on startup.

So the solution is to push a completely new UI framework as though that won't require any code to be touched?

How do you patch these executables? I know 7zip can open .exe but there must be a better way.

It is not a trivial change to make the application DPI ware as it is a coding exercise (starting with that manifest change).

https://docs.microsoft.com/en-us/previous-versions/windows/d...

Marking the app DPI aware just stops Windows doing any application scaling as it leaves that scaling up to the application.

But the real issue is most legacy apps were written before DPI scaling was an issue so they don't have this built in scaling.

To fix this Windows will do a 'one size fits all' scaling on their behalf.

It is this default Windows scaling that makes these legacy apps look so bad at higher DPI settings.

NT 3.1 (that is, the _first_ release of Windows NT in 1993) supported Unicode, at least as far as the UI elements were concerned (that it was UTF-16, well, ...)

Nope, UCS-2. Which is UTF-16, but just the BMP, so only the first 65k codepoints and all characters are fixed-length 16bits. Only later windows versions at some point learned UTF-16.

The UI did scale, but lots of apps were poorly coded.

> Marlett is a TrueType font that has been used in Microsoft Windows since Windows 95. The operating system uses this font to create user interface icons that are used in the menus and windows.

https://en.wikipedia.org/wiki/Marlett

Apple managed to support high-dpi without turning the whole thing upside down.

Apple doesn't run 20 years old binaries. On the contrary, they break ABIs faster than Linux distros, so they can move faster.

What did they break in order to support high-dpi?

Because they had aquired a solid foundation that had fixed this problem already 30 years ago (NextStep with Display PostScript).