4 ms·

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

by b800h 1y ago

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.

IAmLiterallyAB 1y ago
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-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
Arnavion 1y ago
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-drill-configuring-a-debugger-using-image-file-execution-options/373478 https://techcommunity.microsoft.com/blog/askperf/two-minute-...
- Joe_Cool 1y ago
  Renaming anything (without a manifest) setup.exe will cause Windows to ask for UAC elevation. The user cannot opt-out. There are a few other hard coded strings like "install" that cause this AFAIR. You can also use its_a_setup_mr_bond.exe for example.
  - deleted 1y ago
    [deleted]
  - high_priest 1y ago
    Funny, you are right. But it needs to be something without correct .exe metadata. "you_are_an_install_wizard_harry.exe" also triggers different behaviour/query for UAC.
asveikau 1y ago
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.
- charcircuit 1y ago
  >It comes from the era in which it would not be expected for a vendor to patch a program they already shipped This is still the case today. An operating system breaking apps is not desirable behavior. Not all apps are still in development, the work may have been contacted out, the development studio may have been bankrupted, the source code may have been lost, etc. Either you add a compatibility hack to the OS or you drop support for that app.
  - asveikau 1y ago
    > Either you add a compatibility hack to the OS or you drop support for that app. It isn't really a binary choice like this in real life. This really depends on the specifics of what the breakage is. The best way is to not break the caller's expectation to begin with. Anyway, my point is that patching on the vendor side is way more common than it would be in the days before internet updates were common.
    - charcircuit 1y ago
      It's still common with modern operating systems. I think the bias may just be from historical blog posts talking about old events than newer ones. The developers adding these are under NDA so they aren't going to be sharing with the world what they are doing. You are right that it's not a binary choice, they are others like maintaining tech debt forever or paying out of pocket to upgrade people's apps. But it's common for those to not be viable options and operating systems need to keep evolving forward.
    - mrguyorama 1y ago
      The reality that Microsoft discovered decades ago is that "Don't break the callers expectation" doesn't work at all because the callers didn't read the manual, and had blatantly incorrect expectations!. Windows 1.0 apps that properly follow all the documented caveats still work, often without anything more than the compatibility hacks to emulate "Windows 3" or similar. But even back in the 90s, Microsoft found that devs would do things that the documentation explicitly said would break things, and ship it as is. Things like copy/pasting the code the manual said, in big bold letters, DO NOT DO THIS Most popular computer games in the 90s did things like "try to allocate all virtual memory and crash if that's possible" and "turn off interrupts globally" despite being written against virtual driver systems that were meant to cooperatively manage interrupts! >https://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf https://ptgmedia.pearsoncmg.com/images/9780321440303/samplec... "How to ensure your Program does not run on Windows 95"
saagarjha 1y ago
This is common across all platforms that have a backwards compatibility story
BearOso 1y ago
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/util/00-mesa-defaults.conf https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/uti...
ZeWaka 1y ago
Quite a lot of this in proton, except it's by steam appid: https://github.com/ValveSoftware/Proton/blob/proton_10.0/proton#L1209 https://github.com/ValveSoftware/Proton/blob/proton_10.0/pro...
- rendaw 1y ago
  That's fine because app ids are unique.
meinersbur 1y ago
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
- saati 1y ago
  But 1-5 is the executable making decisions based on it's command name, not the OS changing behavior.
- LelouBil 1y ago
  Your examples are interested, but not comparable. In your list these are executables that change their own behaviour based on how they are called, whereas in the OP it's the OS changing code based on the name of an application.
- db48x 1y ago
  In all but the last example these are the programs themselves having multiple names. There are literally multiple names on the file system that point to the same executable. So `ping`, `ping4`, and `ping6` are all the same program but it checks $0 to see which name it was invoked as in order to change it’s own behavior. This is entirely different than when DirectX behaves differently for a program named foo.exe and another one called bar.exe. AppArmor (and for that matter SELinux) are a different thing yet again. Here the goal is not to fix bugs or incompatibilities, but to add extra security. Similar perhaps, but not nearly as intrusive. Neither involve runtime patching, which is the most salient feature of this crash report.
mrguyorama 1y ago
>It seems incredible to me that Microsoft would alter the execution of programs based on the filename of the executable. This has been one of the primary ways microsoft has managed compatibility for decades. Windows 95 had hacks based on filenames of games to make sure popular stuff worked on Windows. Raymond Chen has an entire book! (And a free chapter about exactly this!) https://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf https://ptgmedia.pearsoncmg.com/images/9780321440303/samplec... They had to do these hacks for things like Wing Commander, Simcity, even Microsoft Office itself needed massive hacks (to the point that a significant portion of the profanity in the Windows 2000 source leaks is explicitly calling the Office team a bunch of idiots and losers who don't know what they are doing) >For all we know, there was another game with the same filename and this game has been caught in the crossfire Microsoft has been doing this for 30 years and I am unaware of even one case of "program got wrong compatibility hacks"! It would be unlikely to be reported well so that's not great evidence, but it's been a massive success.

by b800h 1y ago

IAmLiterallyAB 1y ago

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-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

Arnavion 1y ago

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-drill-configuring-a-debugger-using-image-file-execution-options/373478 https://techcommunity.microsoft.com/blog/askperf/two-minute-...

Joe_Cool 1y ago
Renaming anything (without a manifest) setup.exe will cause Windows to ask for UAC elevation. The user cannot opt-out. There are a few other hard coded strings like "install" that cause this AFAIR. You can also use its_a_setup_mr_bond.exe for example.
- deleted 1y ago
  [deleted]
- high_priest 1y ago
  Funny, you are right. But it needs to be something without correct .exe metadata. "you_are_an_install_wizard_harry.exe" also triggers different behaviour/query for UAC.

asveikau 1y ago

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.

charcircuit 1y ago
>It comes from the era in which it would not be expected for a vendor to patch a program they already shipped This is still the case today. An operating system breaking apps is not desirable behavior. Not all apps are still in development, the work may have been contacted out, the development studio may have been bankrupted, the source code may have been lost, etc. Either you add a compatibility hack to the OS or you drop support for that app.
- asveikau 1y ago
  > Either you add a compatibility hack to the OS or you drop support for that app. It isn't really a binary choice like this in real life. This really depends on the specifics of what the breakage is. The best way is to not break the caller's expectation to begin with. Anyway, my point is that patching on the vendor side is way more common than it would be in the days before internet updates were common.
  - charcircuit 1y ago
    It's still common with modern operating systems. I think the bias may just be from historical blog posts talking about old events than newer ones. The developers adding these are under NDA so they aren't going to be sharing with the world what they are doing. You are right that it's not a binary choice, they are others like maintaining tech debt forever or paying out of pocket to upgrade people's apps. But it's common for those to not be viable options and operating systems need to keep evolving forward.
  - mrguyorama 1y ago
    The reality that Microsoft discovered decades ago is that "Don't break the callers expectation" doesn't work at all because the callers didn't read the manual, and had blatantly incorrect expectations!. Windows 1.0 apps that properly follow all the documented caveats still work, often without anything more than the compatibility hacks to emulate "Windows 3" or similar. But even back in the 90s, Microsoft found that devs would do things that the documentation explicitly said would break things, and ship it as is. Things like copy/pasting the code the manual said, in big bold letters, DO NOT DO THIS Most popular computer games in the 90s did things like "try to allocate all virtual memory and crash if that's possible" and "turn off interrupts globally" despite being written against virtual driver systems that were meant to cooperatively manage interrupts! >https://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf https://ptgmedia.pearsoncmg.com/images/9780321440303/samplec... "How to ensure your Program does not run on Windows 95"

saagarjha 1y ago

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

BearOso 1y ago

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/util/00-mesa-defaults.conf https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/uti...

ZeWaka 1y ago

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

rendaw 1y ago
That's fine because app ids are unique.

meinersbur 1y ago

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

saati 1y ago
But 1-5 is the executable making decisions based on it's command name, not the OS changing behavior.
LelouBil 1y ago
Your examples are interested, but not comparable. In your list these are executables that change their own behaviour based on how they are called, whereas in the OP it's the OS changing code based on the name of an application.
db48x 1y ago
In all but the last example these are the programs themselves having multiple names. There are literally multiple names on the file system that point to the same executable. So `ping`, `ping4`, and `ping6` are all the same program but it checks $0 to see which name it was invoked as in order to change it’s own behavior. This is entirely different than when DirectX behaves differently for a program named foo.exe and another one called bar.exe. AppArmor (and for that matter SELinux) are a different thing yet again. Here the goal is not to fix bugs or incompatibilities, but to add extra security. Similar perhaps, but not nearly as intrusive. Neither involve runtime patching, which is the most salient feature of this crash report.

mrguyorama 1y ago

>It seems incredible to me that Microsoft would alter the execution of programs based on the filename of the executable. This has been one of the primary ways microsoft has managed compatibility for decades. Windows 95 had hacks based on filenames of games to make sure popular stuff worked on Windows. Raymond Chen has an entire book! (And a free chapter about exactly this!) https://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf https://ptgmedia.pearsoncmg.com/images/9780321440303/samplec... They had to do these hacks for things like Wing Commander, Simcity, even Microsoft Office itself needed massive hacks (to the point that a significant portion of the profanity in the Windows 2000 source leaks is explicitly calling the Office team a bunch of idiots and losers who don't know what they are doing) >For all we know, there was another game with the same filename and this game has been caught in the crossfire Microsoft has been doing this for 30 years and I am unaware of even one case of "program got wrong compatibility hacks"! It would be unlikely to be reported well so that's not great evidence, but it's been a massive success.