This is due to an overall odd strategy by the DirectX graphics team, which is to implement many of the optimization and enhancement features by Detour-ing API calls in the OS. Essentially, the Windows OS is patching itself to implement features.
Unfortunately, this is being done without core OS assistance like the AppCompat system, so it comes with similar problems to unassisted regular user-space patching. In this case, the Detours code used by DXGI is unable to support the current PAC-enabled function prologues in the current version of Windows 11 ARM64. It isn't limited to just the OP's scenario; attempting to enable Auto Super Resolution (AutoSR) on any native ARM64 program using DirectX will also currently crash in a similar manner in EnumDisplaySettings().
The full screen optimization that is mentioned also has some history. It's well intentioned to remove an entire full-screen copy per frame and increase performance/efficiency, but had some problems. When it was originally implemented in Windows 10, it broke full screen mode for some DirectX 9 apps because it made some incorrect assumptions about the window handle supplied by the application for focus tracking. But it was frustrating to deal with, because the mechanism was nearly undocumented and had no opt-out besides a manual user compatibility checkbox. It took me a couple of days of tearing apart the core windowing guts of my program to figure out what Microsoft had done and how to work around it, and it took several months for the Windows team to fix it on their end.
It seems incredible to me that Microsoft would alter the execution of programs based on the filename of the executable. For all we know, there was another game with the same filename and this game has been caught in the crossfire. This is crazy stuff.
The title is a bit clickbait but nice article ;) This is widespread in API-level software, from OSes to GPU drivers. I'm not sure how documented this is but you can find interesting stuff by renaming your exe to Quake, or FIFA, or Minecraft or whatever.
> I’d rather just spend the brain power on ditching OpenGL, rather than trying to continue working with this broken API
Is "this broken API" responsible for a library monkey patching?
Also, we are lucky that linux libraries generally don't use such hacks. That's really bad style of programming. Also legacy games probably would run just fine with a bitblt if they were running fine on older software.
> It only happens when the program is called SS14.Loader.exe
This isn't something only Microsoft does but also graphics drivers, etc. TBH sometimes i consider using using GUIDs in exe names at build time to avoid such lists :-P.
You are a unique person. You have detailedknowlage of graphics assembly and windows api. And you have the creativity to write games. Which need the side ability of drawing.
This insane amount of knowlage is rare. And the ability to write about it is also not common.
Man I gotta give this person props, that is a LOT of effort to get your game to run native ARM64 on Windows. How many people out there are trying to game on ARM64 Windows devices?
I would like to disable these compatibility lists on Windows and to actually be able to report any issues and crashes to devs. But this might be a very Linux mindset thing for me to want.
What, Microsoft is still doing this?!? Back in the day Windows 95 developers went the extra mile to ensure compatibility with SimCity and a bunch of other games:
This is due to an overall odd strategy by the DirectX graphics team, which is to implement many of the optimization and enhancement features by Detour-ing API calls in the OS. Essentially, the Windows OS is patching itself to implement features.
Unfortunately, this is being done without core OS assistance like the AppCompat system, so it comes with similar problems to unassisted regular user-space patching. In this case, the Detours code used by DXGI is unable to support the current PAC-enabled function prologues in the current version of Windows 11 ARM64. It isn't limited to just the OP's scenario; attempting to enable Auto Super Resolution (AutoSR) on any native ARM64 program using DirectX will also currently crash in a similar manner in EnumDisplaySettings().
The full screen optimization that is mentioned also has some history. It's well intentioned to remove an entire full-screen copy per frame and increase performance/efficiency, but had some problems. When it was originally implemented in Windows 10, it broke full screen mode for some DirectX 9 apps because it made some incorrect assumptions about the window handle supplied by the application for focus tracking. But it was frustrating to deal with, because the mechanism was nearly undocumented and had no opt-out besides a manual user compatibility checkbox. It took me a couple of days of tearing apart the core windowing guts of my program to figure out what Microsoft had done and how to work around it, and it took several months for the Windows team to fix it on their end.
It seems incredible to me that Microsoft would alter the execution of programs based on the filename of the executable. For all we know, there was another game with the same filename and this game has been caught in the crossfire. This is crazy stuff.
> Of course it’s the goddamn filename.
Cue in a few dozen oldschool game developers thinking, right from the first paragraph, "did he name his game game.exe"?
When I read about stuff like this it makes me feel lucky never having had to do Windows development.
The title is a bit clickbait but nice article ;) This is widespread in API-level software, from OSes to GPU drivers. I'm not sure how documented this is but you can find interesting stuff by renaming your exe to Quake, or FIFA, or Minecraft or whatever.
> I’d rather just spend the brain power on ditching OpenGL, rather than trying to continue working with this broken API
Is "this broken API" responsible for a library monkey patching?
Also, we are lucky that linux libraries generally don't use such hacks. That's really bad style of programming. Also legacy games probably would run just fine with a bitblt if they were running fine on older software.
> It only happens when the program is called SS14.Loader.exe
This isn't something only Microsoft does but also graphics drivers, etc. TBH sometimes i consider using using GUIDs in exe names at build time to avoid such lists :-P.
You are a unique person. You have detailedknowlage of graphics assembly and windows api. And you have the creativity to write games. Which need the side ability of drawing.
This insane amount of knowlage is rare. And the ability to write about it is also not common.
You are very talented and hard working person.
I am in awe.
Man I gotta give this person props, that is a LOT of effort to get your game to run native ARM64 on Windows. How many people out there are trying to game on ARM64 Windows devices?
I would like to disable these compatibility lists on Windows and to actually be able to report any issues and crashes to devs. But this might be a very Linux mindset thing for me to want.
> It only happens when the program is called SS14.Loader.exe.
Could you have a SS14.Loader.arm.exe for arm? Then the exe name wouldn't match and it woildn't trigger the crash?
What, Microsoft is still doing this?!? Back in the day Windows 95 developers went the extra mile to ensure compatibility with SimCity and a bunch of other games:
https://news.ycombinator.com/item?id=34138028
If you’re on a list for an app you haven’t released and you didn’t know, what kinds of spyware do you have on your machine? Oh, windows…