4 ms·

> It's not broke, stop trying to fix it. There could have been better ways to keep it modern, but just leaving everything alone because “it works” isn’t really

> It's not broke, stop trying to fix it. There could have been better ways to keep it modern, but just leaving everything alone because “it works” isn’t really an option. First comes Unicode, then 4K/High-dpi scaling, then touch support and so on. Once high DPI screens arrived, UIs that scaled poorly literally don’t work.

foobiekr 5y ago
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, ...)
- corty 5y ago
  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.
zozbot234 5y ago
The Win32 widgets are scalable, actually. They support device-independent units out of the box, even in Windows 95.
- Dork1234 5y ago
  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.
  - jussij 5y ago
    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.
    - mycall 5y ago
      How do you patch these executables? I know 7zip can open .exe but there must be a better way.
      - jussij 5y ago
        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/desktop/ms701681(v=vs.85) 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.
    - Dork1234 5y ago
      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.
      - jussij 5y ago
        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.
    - Joeri 5y ago
      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.
matja 5y ago
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 https://en.wikipedia.org/wiki/Marlett
tonyedgecombe 5y ago
Apple managed to support high-dpi without turning the whole thing upside down.
- flohofwoe 5y ago
  Because they had aquired a solid foundation that had fixed this problem already 30 years ago (NextStep with Display PostScript).
- vetinari 5y ago
  Apple doesn't run 20 years old binaries. On the contrary, they break ABIs faster than Linux distros, so they can move faster.
  - tonyedgecombe 5y ago
    What did they break in order to support high-dpi?

foobiekr 5y ago

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, ...)

corty 5y ago
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.

zozbot234 5y ago

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

Dork1234 5y ago
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.
- jussij 5y ago
  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.
  - mycall 5y ago
    How do you patch these executables? I know 7zip can open .exe but there must be a better way.
    - jussij 5y ago
      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/desktop/ms701681(v=vs.85) 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.
  - Dork1234 5y ago
    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.
    - jussij 5y ago
      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.
  - Joeri 5y ago
    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.

matja 5y ago

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 https://en.wikipedia.org/wiki/Marlett

tonyedgecombe 5y ago

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

flohofwoe 5y ago
Because they had aquired a solid foundation that had fixed this problem already 30 years ago (NextStep with Display PostScript).
vetinari 5y ago
Apple doesn't run 20 years old binaries. On the contrary, they break ABIs faster than Linux distros, so they can move faster.
- tonyedgecombe 5y ago
  What did they break in order to support high-dpi?