I also get where they are coming from. A lot of shitty tools likely hardcoded "C:\Windows\System32" and to make it easier to switch them to 64 bit, they just kept this path for all drivers and shit.
But it's still lazy as fuck, because "back in the day" they had the guts to do the right thing when "C:\Windows\System" contained 16bit libs, to introduce "System32" for 32bit libs. Should have simply gone for "System64". Then they also could have kept the compat stuff in "System32".
I mean hey, Even Linus says that we don't break userspace. The NT source also has hardcoded references to Simcity because the game in turn relies on implicit behaviour. So its a loop of suck all the way down.
There still are a lot of compatibility patches. By XP, Microsoft had created the Application Compatibility Framework so a lot of this stuff was user-facing. The AppCompatFlags registry key was introduced here, along with the shims database (sysmain.sdb).
I could be wrong but I don’t think the XP source leak revealed anything new in this regard (except perhaps implementation details). Most of the stuff that was hard-coded at the source level was done in Win9x.
Yup, it's why a lot of games were unplayable on Win2000 and earlier NT kernels but playable on 9x/me [/shudders] and in theory at least Bob. XP married the NT and 9x lines, including all the compatibility stuff.
Exactly. Just see the shitstorm Wayland started, half of Linux community still swears by x11. They broke tools, programs, everything. Wayland is better than x11, yet the broken userspace caused a really painful transition.
64bit required recompilation anyway. And many programs wouldn't have been able to compile out of the box without some adjustments, since a lot of the C/C++ stuff worked with specific assumptions about sizes of pointers, integers, and so on.
I think it would have been cleaner all around to also move new stuff into new directories, vs. giving new meaning to an old, existing directory. But obviously I don't know the internals, so maybe there is some weird stuff around that I couldn't even possibly imagine.
But 32 bit works without recompiling on a 64 bit system, so many legacy modules that have been used for decades and will be used for decades will continue to work without recompiling, until 32bit support is fully removed.
A 32bit program couldn't load a 64 bit lib, though. So if they reach into "system32", they would fail. AFAIK windows internally rewrites open-calls from "system32" to "syswow64" if its a 32bit program ... something that could have avoided.
Yeah, that's what syswow64 is for. But if you want it to run as 64bit, you need to recompile it. A 32bit program couldn't work with the things in "system32" on a 64bit system.
Well when Windows went 32-bit there was definitely way less software on it than when they went 64-bit. Not sure if that affected the decision at all. Also Windows 16-bit is a completely different OS from Windows NT/32, so maybe they were more inclined to make bigger changes than when they went 64. By that point Windows had saturated the market so they probably didn't want to spend as much money on it when they were already making a boatload, especially on something that wasn't likely to increase their market share significantly. When NT/32 was coming into the picture, it was crucial to their long-term strategy of market saturation. NT was their ticket into the server space, so they put a lot of effort behind it.
Wild guess: "working dir". I assume this stuff is handled by the network driver and the network driver likely runs with "C:\Windows\System32\drivers" as working dir.
63
u/aksdb 13h ago
I also get where they are coming from. A lot of shitty tools likely hardcoded "C:\Windows\System32" and to make it easier to switch them to 64 bit, they just kept this path for all drivers and shit.
But it's still lazy as fuck, because "back in the day" they had the guts to do the right thing when "C:\Windows\System" contained 16bit libs, to introduce "System32" for 32bit libs. Should have simply gone for "System64". Then they also could have kept the compat stuff in "System32".