Its funny how many quirks of UNIX/C/etc go back to the severe limitations of early day computers. Which is why using modern languages like Rust and its compiler really feels like coming up for air.
> Nobody questions why main drive is C:, remnant of [an] early computer having two floppy (not sure) drives on A: and B:
Recently I was trying to install some obscure driver for a device that doesn't autodetect in my Windows 10 work computer, I had to go through the old school "add device" wizard. When clicking to manually provide the driver, the dialog is exactly (or almost?) the same as the one from Windows 95, and the path defaults to... A:\! There's no floppy on this computer, there even isn't an optical drive!
Windows is a 32 bit shell for a 16 bit extension to an 8 bit Operating System designed for a 4 bit microchip by a 2 bit company which can't stand one bit of competition.
As a user, the main one that really annoys me is the "Program Files" vs "Program Files (x86)" split. I can kinda see why they have to be different folders, but why did they have to name it "... (x86)" instead of "... (32bit)"?
You can call the 64 bit architecture x64 all you like, but it's still using the x86 instruction set and it's frequently referred to as x86-64, so naming that 32 bit only folder "... (x86)" will just make things more confusing than they should be.
I think this was because at the time of picking the name, Windows with a working 65-bit Windows-on-Windows subsystem only ran on x86 and x64, so the naming made sense. DEC builds weren't relevant at the time and ARM was still far away from gaining 64-bit support. There was a 64 bit version of XP for Itanium but that couldn't run x86 code natively.
It'll be interesting to see what Microsoft will do if Windows on ARM actually takes off. As far as I know, the current translation layer can't execute amd64 on ARM, only x86. Will we see Program Files, Program Files (x64) and Program File (x86)? It would make sense; have the redirection system ready to go and the naming scheme would also make perfect sense. ARM doesn't need a special 32-bit folder because there's no notable 32-bit vs 64-bit clash; nobody is migrating upgrading their Windows CE device to Windows 11, after all.
x64 emulation for Windows on arm Already exists. It is not based on WOW style technology. Furthermore 32 bit arm programs do exist on modern Windows on ARM, using a version of WOW64 very similar to WOW64 on x64 cpus. But they also have x86 WOW64, based on the Itanium version, that had to do binary translation.
- "C:\Program Files" <- ARM64 programs go here, as do x64 programs!
- "C:\Program Files (Arm)" <- ARM32 programs go here
- "C:\Program Files (x86)" <- x86 programs go here
I'm not sure how things like "Common Files" work in C:\program files, unless they made mixing arm64 dlls with x64 exes and vice versa just work. Which they probably did. I'm guessing they did not want another WOW version, since it was already bad enough to have to ship 3 different copies of certain system components, and they did not want to need to include a 4th copy, especially as ARM devices are often a bit light on storage space.
Fun fact this is the second time Microsoft have pulled this. The first time was for legacy 16 bit Windows applications running on Windows NT. Since most people have moved to 64bit processors, it has been shuttered.
Yes, in 16-bit windows it was system and then 32-bit binaries would go into system32. By the time 64-bit arrived so much stuff had system32 hard-coded in, there wasn't much point in trying to change it so you ended up with SysWOW64 (when a 32-bit app runs under emulation, it 'sees' SysWOW64 as System32, and can't see the 64-bit system directory)
And both the content of system32 and SysWOW64 is actually hard linked from the side by side folder (WinSxS), hence why this folder is usually half the size of the Windows folder.
It's the Windows way to abstract system folders and provide binary compatibility across architectures. I'd much rather have ld.so.preload and multiarch than this hard links mess though.
I'm a big fan of Scheme, which is just about as old as UNIX, and which is based on the even older LISP (which is even older than UNIX, going back to the 50's).
