That strategy is described here, and comes from game developers wanting DirectX to be untied from OS versions as it used to be.

https://devblogs.microsoft.com/directx/gettingstarted-dx12ag...

>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

Surely microsoft could avoid patching this on arm in the first place though right? As in whatever gating they use should make sure it’s not on arm.

Doing things based on exe filename is quite standard in Windows land. There's literally a registry key called "Image File Execution Options" where you can add a subkey with the name of the exe and then add values to control things like what interpreter to launch it under by default. Similar to Linux's binfmt registration, but based on filename rather than magic bytes. Very useful for attaching debuggers to specific subprocesses that you can't launch manually, as long as the process is named sufficiently uniquely.

https://techcommunity.microsoft.com/blog/askperf/two-minute-...

I don't know if it was filename exactly, but a similar story:

> Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

It's not limited to Microsoft. Nvidia and AMD Windows drivers also do the same. Even mesa has a few lists of program-specific flags:

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/uti...

Quite a lot of this in proton, except it's by steam appid: https://github.com/ValveSoftware/Proton/blob/proton_10.0/pro...

This is common across all platforms that have a backwards compatibility story

There is a ton of this in the app compatibility support. It comes from the era in which it would not be expected for a vendor to patch a program they already shipped. So, you know, they enable the hacks that keep SimCity working if they notice you're running SimCity. And the SimCity CD-Rom would never see an update.

Changing execution behaviour based on filename is common in Linux environments too. Some examples:

1. BusyBox is a single executable that executes different commands based on which symlink was used to call it

2. Bash puts itself into compatibility mode if invoked as "sh"

3. "ping" can be invoked as "ping4" or "ping6"

4. Some of git's subcommands are symlinks back to the main executable

5. Clang switches to C++ mode if invoked as "clang++"

6. AppArmor profiles activate on file paths

He should try quack.exe

No worries, the same experience can be done with OpenGL or Vulkan, depending on the specific OS flavour and OEM drivers.

Each operating system has such layers of cruft, they're sometimes just harder to debug.

I've personally run into stuff like this on Windows but I want to emphasize that the vast majority of developers won't run into these problems. It's basically the equivalent of finding a compiler bug - yes, you might, but usually the problems you hit are not caused by the compiler or OS, as a general thing.

Are OS or compiler problems more common now than they were 10 years ago? Possibly, but I wouldn't be surprised if they're less common, either.

I have run into driver bugs multiple times though, perhaps more often than OS bugs. And that's really frustrating.

I never understand these drive-by comments. It's not like developing on/for the competition is any easier or less convoluted. The author is debugging a cross-language (both managed and native), cross-architecture video game with a variety of third-party libraries.

Turns out that the Windows graphics stack is complicated (mainly because it needs to support a variety of closed-source programs that never saw maintenance after initial release), so compatibility layers meant to optimise for certain programs (an easy optimisation, frankly) accidentally caught the author's program in the master list, too.

Back in 2001, ATI got in some hot water after it was revealed that they intentionally blurred all textures (used a lower resolution mipmap) if you were running Quake 3 Arena. Changing all strings from "Quake" to "Quack" (including renaming the executable) disabled the degraded mipmaps, and improved the graphics (and reduced framerates).

https://web.archive.org/web/20190728022442/https://techrepor...

Sounds pretty click-baity but if a company put the name of my software on an opaque list that ships with the OS that makes my software behave differently than I expect it to and didn't even TELL ME about it I'd be way WAY more pissed than this guy is.

TrickNvidiaDriversForPerformance_javaw.exe.minecraft.exe

Its also not surprising to anyone who spent time reading Raymond Chen's The Old New Thing blog posts back in the day, a lot of them were about these rather absurd hoops Microsoft was always jumping through to increase backward and forward compatibility with these sorts of tricks.

It may have lead to an unfortunate situation for this developer in this one very niche corner case, but overall it has been wildly beneficial for users over the years (decades even) to have most software Just Work regardless of how deprecated the underlying APIs they were built on are now.

Knowing the author it can only mean OpenGL/EGL and similar.

They ranted/vented about OpenGL sucking and DirectX being best thing since butter on toast was invented.

The Linux kernel contains biiiig piles of hacks for individual motherboards, systems, devices. It's like this at every level everywhere, unfortunately. I mean, it was only very recently that your 64 core CPU stopped pretending to be an 8086 during initial boot

It goes both ways! https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...

Not only that, he also does sysadmin for the game's infrastructure and administrates the drama-prone community. And whatever else happens behind the scenes. Honestly one of the greatest developers I've seen.

We get a lot of people wanting to run the game on ChromeOS school laptops, which is also ARM-based.

I played Silksong recently on my Surface Pro 11, it worked fine. 2D game with minimal graphics requirements so it's a different case, though.

Read the article; the list is based on EXE filenames. They developer was trying to port an existing application from AMD64 to ARM64.

The author of the post indicated that they are releasing an update to an existing game, which we can presume has the same executable filename.

You could. The fix is easy. The problem was the painfully long debugging in order to find the root cause of the issue.