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