Customer somehow managed to set up their Windows servers so Program Files -> Program Files (x86) doesn't happen for 32 bit applications. The other redirections of Windows\System32 -> Windows\Syswow64 and HKLM\SOFTWARE -> HKLM\SOFTWARE\Wow6432Node are still in effect.
I'm pretty confident they did not inject a DLL everywhere that does Wow64DisableWow64FsRedirection but some other magic is in effect that I've never heard of. Unfortunately the customer doesn't know either. The server admin didn't know about 32 bit redirection of disk paths but only registry.
I'd really like to know how this could be done so I could study the dynamics of this behavior. Our application really sensitive to folder redirection and normally doesn't work if installed to C:\Program Files because of it; but somehow this customer managed to evade both 32 bit redirection and UAC redirection. I suspect the latter is because of the former and UAC redirection simply doesn't exist on C:\Program Files but only C:\Program Files (x86).
I wasn't able to directly check what the 64 bit Program Files directory is, but the 32 bit Program Files directory is C:\Program Files (x86).
Our own installer is 32 bit (most of the software is compiled as .NET Any CPU so the same install package works for both.) Testing on my machines results in trying to install to C:\Program Files actually installs to C:\Program Files (x86) as expected (however the application doesn't work correctly because the installation directory registry key was set wrong for 64 bit view).
There's some strange things going on on their servers and they're opening support requests and I'd really rather not tell them to rebuild their environment without real evidence, especially because I don't know what's allowing it to work in the first place. Changing the install path might not actually help. My understanding is this should blow up as soon as a 32 bit application (such as MS Office -- they're stuck with 32 bit MS Office because Access DB reasons) tries to load a dll from C:\Program Files\Common Files Note that our application also has 32 bit components; and 32 bit executables can start and load dlls from C:\Program Files in their environment.
The OS is either Windows Server 2016 or 2019.
Yes I would normally conclude trying to do this is a bad idea. I would be in a much better position if I could test and see how bad.
Please don't tell me this can't be done. I've seen it done. I have no idea how.
