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