ZDoom

Actually there's a dpiAware per monitor setting for win8.1, should we add a dpiAwareness per monitor v2 setting for win10 then?
I think i will revert that commit but Zandronum doesn't even declare compatibility with Vista and seems it works well. Precisely a common complaint from those users is "Zandronum works".

@dpJudas Thanks for the explanation.
That commit is only in my legacy and g3.3mgw branches. Of course i know it wouldn't make sense for modern versions.
I don't think it will be a problem but i could revert it, i prefer myself running the app in 8.1 compatibility mode with the right click properties tab if that works than using an external tool.

dpJudas wrote: I can see some sense in it for LZDoom. I was specifically talking about why I think it should never be used to GZDoom.

I firmly believe in letting deprecated hardware rest in peace. Even without the fallout from 2 years ago I am certain that I'd have dropped GL 2 for good by now. I seriously have to wonder how many users of LZDoom are actually using old hardware - there's probably a large group who just stick to it for the old look of the option menus - and for those altering the manifest may be a disservice.

Rachael wrote: Nevertheless, I don't think drfrag has any intention to put that commit in GZDoom - and there's no way it would be merged if he did. I think it DOES make sense to use it for LZDoom, though.

For GZDoom it'd be pointless. The hardware in question isn't even supported anymore because its OpenGL support is insufficient.

I didn't think drfrag was going to target GZDoom with that change, but I would definitely agree with you: GZDoom should definitely not be forced to run in Windows 8.1 compatibility - in fact, that was suggested before and it was outright denied by Graf, and I agree with you also that there are a myriad of ways that a shim may affect an app that may not be obvious or apparent until it is too late. And by "too late" I mean you take it for granted to the point where you don't think it can cause a problem, when by then it does.

Nevertheless, I don't think drfrag has any intention to put that commit in GZDoom - and there's no way it would be merged if he did. I think it DOES make sense to use it for LZDoom, though.

The purpose of the manifest is let the OS know which version this executable was developed and tested for. When it doesn't match it applies a number of compatibility shims as a best effort to try make sure the program still runs. But such methods are not perfect and will make your program deviate from how the current documentation says it will behave. For example, if you call your application shows a wizard that sort of looks like an installer, and you forgot to inform the OS that it was tested with Windows 10, then the OS may display an annoying "Did this program install correctly?" dialog. It alters how DirectDraw behaves, like you can see on your own list - all kinds of crap like that.

Keep in mind that while a Windows 8.1 app may run on Windows 10, it by no means guarantees it will run well. Just like a Windows 95 app will run. Old games using old versions of DirectInput got mouse acceleration in them today that they didn't have when they were new. That kind of stuff - minor things that changed in the OS but the compatibility shims didn't account for. But if you absolutely want an example of how it can affect LZDoom, consider this: you just told Intel that it is Windows 8.1, but you also at the same time told the Nvidia and AMD drivers the same thing. There may be something in Windows 10 they could use for better performance that they will now not tap into because they think they are running on Windows 8.1. This stuff gets complex fast in a way where nobody can see the full picture, and for that reason it is dangerous to run your app in compatibility land.

I can see some sense in it for LZDoom. I was specifically talking about why I think it should never be used to GZDoom.

I don't see what the problem is, there is no DPI awareness setting in the manifest so AFAIK it doesn't matter if it's a win8.1 or win10 app.
I read this and there's no entry for later versions: https://docs.microsoft.com/en-us/window ... e-manifest
I'm not going to maintain that branch forever so i'm not updating the manifest in the future. What if it was a win8.1 app from the start? Then it wouldn't be a hack but i see no difference. I don't know the volume of the hardware affected but do you mean that LZDoom will look worse on HI DPI monitors just becouse it's not a Win10 app?

I'm quite familiar with this kind of reasoning. It works perfectly well until the number of hacks (*) implemented in the codebase overwhelm them or start interacting in complex ways nobody can figure out. Yes, even Windows 7 has DPI awareness, but I'm guessing you haven't actually tried it on an actual hi-dpi monitor. It was extremely broken. In fact, it was the reason I upgraded from Windows 7 to Windows 10 in the first place. Also worth mentioning here that the old DPI awareness required a restart of the computer if it changed. For most users this doesn't really matter much, but if you're someone that plugs in an external monitor once in a while with a different DPI scale then you reduced the quality of your product for those people, just so that you could include support for hardware Intel no longer wants to support.

*) Make no mistake forcing a compatibility profile is a hack. A very big one, too. You have no idea what else Microsoft might alter about how it runs the executable.

Now they allow to specify DPI awareness per monitor but you could specify system awareness before and there's no entry for that in the manifest. It's an old version with old code anyway, old apps won't stop working for now. ZDoom CL (2.1.8) still works well and has no OS compatibility entries, same for old GZDoom versions.

If Microsoft introduces a new requirement for win10 apps then I would really like to know it when I run it on my computer. By forcing the app into compatibility mode I stop noticing and might even indirectly be blocked from accessing them. For example, Windows 10 introduced new DPI scaling modes and if you don't opt into them the OS may attempt to do a best effort at scaling your application to the monitor for you.

I can understand why LZDoom might opt for taking the risk since it is targeting the ultra lowend anyway. I don't think running GZDoom in a compatibility profile is a very good idea. If I absolutely had to target computers where Intel intentionally chose not to fix them, then I would do it by patching kernel32.dll's GetVersion in memory if I detected an old active Intel iGPU. The last thing I would do in GZDoom is to freeze it in time just because Intel sucks!

But actually not much is sacrificed here, it says Windows 10 or 8.1 instead of 10. And i actually feel safer this way, what happens is monkeysoft introduces a new requirement for win10 apps or drivers?

Rachael wrote: All because one Intel engineer thought it would be a genius idea to lock the drivers to a specific kernel version of Windows - and then the company refuses to hotfix that out.

Actually, I think what happened here is why Microsoft deprecated GetVersion - too many programmers are too stupid to use it correctly.
Windows XP returns major version 5, Vista up to 8.1 return major version 6, and 10 returns 10.
So, what does the smart programmer do:
I have seen code like this myself. The project I am developing at work had a code snippet just like the one above, only on iOS, checking for iOS version 10. Imagine everynbody's surprise when it suddenly broke on iOS 11...

Blzut3 wrote:If it does work, I would assume "turn on compatibility mode" is easier than "download this tool" or "download this other version."

How eager are you to walk someone through getting to the properties sheet to enable this? I am trying to see from an end-user's perspective, and honestly I think if I was pretty green with navigating the operating system in general, since I would at this point already be familiar with downloading tools, I'd rather just let a tool do the work for me, because downloading the tool is a procedure I'd naturally already be more familiar with, than looking at the properties sheet. Some people can do the properties sheet just fine, though - and if they can, more power to them, that method definitely could be encouraged for them.

I think drfrag's solution was appropriate mostly because it focused on LZDoom which itself focuses on legacy hardware. Sure, it isn't ideal, but honestly I can't think of a better one, and while I can't speak for him I do doubt that he is interested in distributing two versions of LZDoom - one for the broken Intel drivers and one for everyone else. So in the end, with focusing on legacy compatibility, some sacrifices have to be made on the modern side - and what is sacrificed is something GZDoom can keep and focus on, instead. All because one Intel engineer thought it would be a genius idea to lock the drivers to a specific kernel version of Windows - and then the company refuses to hotfix that out.

If I am wrong, obviously I am open to being corrected.

Yeah, that would be good if compatibility mode works. But really it doesn't matter whether users are running 8.1 or 10, besides very few people use 8.1. Unless you need the specific win10 build for reports it's no big deal. This only affects old legacy versions which will be discontinued soon anyway.

drfrag wrote:I meant how do users know that they must use a compatibility mode when they get the OpenGL not accelerated error?

Ahh. Although I don't think there's a good automatic solution, changing the error message when running under Windows 10 to include a note about 2nd generation Intel processor graphics would likely help (users don't read, but I personally get a kick out of when they copy and paste a message which contains the exact solution in it). Given that we have code to read CPUID it may even be easy to show the message only to Sandy Bridge users.

The version check functions are discouraged since people get version checks wrong all the time, but GZDoom uses it for reporting the version of Windows (i.e. in crash reports). In my opinion this working as intended would be more important than a few people running hardware not supported by their OS not having to go into properties and work around a driver bug. Assuming that's a viable solution anyway.

If it does work, I would assume "turn on compatibility mode" is easier than "download this tool" or "download this other version."

Well the "solution" would be to use wtfi or a compatibility mode.