top | item 31337054

(no title)

alecmg | 3 years ago

I think Windows is even more permeated with legacy

Off the top of my head:

Nobody questions why main drive is C:, remnant of [an] early computer having two floppy (not sure) drives on A: and B:

Or more recent - C:/Windows/System32 holds 64 bit executables; 32 bit exectuables live in C:/Windows/SysWOW64

discuss

fer|3 years ago

> 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!

beowulfey|3 years ago

Every time I get one of those it's like falling back in time!

thg|3 years ago

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.

DavidVoid|3 years ago

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.

behnamoh|3 years ago

More still, why do some apps install in other directories such as AppData?

https://stackoverflow.com/questions/12427245/installing-in-p...

jeroenhd|3 years ago

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.

sph|3 years ago

And I'd never map a network voume on D:, that's reserved for the CD drive!

Nick87633|3 years ago

And E, F, G, H for the CD-W, CD-RW, DVD, DVD-RW... :)

teddyh|3 years ago

No, the CD drive lives on SCSI id #4!

majewsky|3 years ago

sph's reaction when someone puts network volumes in the wrong spot:

D:

indrora|3 years ago

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.

https://en.wikipedia.org/wiki/Windows_on_Windows

quickthrower2|3 years ago

Yeah that is a windows gotcha!

mlatu|3 years ago

so C:/windows/system is a remnant from the 16bit era?

kevingadd|3 years ago

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)