3 ms·
> In contrast an application written in 1995 that uses Win32 will run out of the box in Windows 10 without any changes. A user can run such an application perfe
by jcelerier 7y ago
> In contrast an application written in 1995 that uses Win32 will run out of the box in Windows 10 without any changes. A user can run such an application perfectly fine (and personally i have several applications like that that i'm using) and a developer who wants to work with the code will be able to focus on the application itself (since chances are he already learned Win32 at the past if he worked in any other Win32 program).
I'm sorry but your definition of "works fine" is likely very uncommon. Old applications won't even have @2x pixmaps which leads to everything being a blurry upscaled mess.
If it were that easy we wouldn't be getting regular requests to port MFC applications to Qt at the company I work at ;)
- badsectoracula 7y agoI do not know why you are getting requests to do that but keep in mind that people who are fine with your MFC applications are not going to contact you - what you are seeing is only people who have issues, not all people (EDIT: also i'm certain you can make MFC applications work in hidpi monitors, you do not need to port them to Qt for that). Old applications will certainly not support "@2x pixmaps" (though many do support hidpi monitors if you use the "Override high DPI scaling behavior" to let the application do it - however the majority do not, which is why this isn't the default) but despite being blurred they'll still work (and that is assuming you are using a hidpi monitor, in practice nowadays hidpi monitors are still a very tiny minority so chances are you wont even notice it). Though FWIW i personally do not use hidpi monitors and one of the reasons is that (the other is that i play games a lot and i do not feel the slightly higher crispiness is worth the massively reduced performance). However breaking the ABI wont work at all, blurry or not. (also note that Windows 10 will not use bilinear filtering for integer scaling so in -e.g.- 4K monitors running at 200% scaling you shouldn't get blurriness)
- pjmlp 7y agoHow to do HiDPI with MFC, https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dp... https://devblogs.microsoft.com/cppblog/mfc-applications-now-default-to-being-dpi-aware/ https://devblogs.microsoft.com/cppblog/mfc-applications-now-... (Unfortunately the images are still broken after the blog migration)
- int_19h 7y agoIf it's not a high-DPI screen, then it will look the same. If it's a high-DPI screen, then it will be upscaled to look the same as it did on the old low-res screen, so it's not any worse than it has been before. It's only a "blurry mess" when contrasted to an app with high-res text and graphics, making use of that new screen. So it won't magically become a high-DPI app, of course, but it will still run perfectly fine, if your baseline is "runs the same as it always did". High-DPI support is a new feature, so it stands to reason that it requires app to be updated.
- badsectoracula 7y agoAs a sidenote, it does look worse with bilinear upscaling, sadly. This is why both Windows 10 in recent versions as well as new GPU driver offer the option for nearest-neighbor integer scaling where possible. For example my laptop has a 1080p monitor - not exactly hidpi, but the monitor is small enough for Windows to suggest a 150% scale. But this makes anything that doesn't support scaling look blurry (and also break several games, but that is another matter) so i prefer to use 100% even though it makes things a bit harder to see.