zlacker

[return to "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]
1. sdgdfg+h6[view] [source] 2022-05-11 07:16:08
>>taubek+(OP)
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.
◧◩
2. alecmg+Ca[view] [source] 2022-05-11 07:56:16
>>sdgdfg+h6
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

◧◩◪
3. mlatu+Sd[view] [source] 2022-05-11 08:22:41
>>alecmg+Ca
so C:/windows/system is a remnant from the 16bit era?
◧◩◪◨
4. keving+Mf[view] [source] 2022-05-11 08:45:04
>>mlatu+Sd
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)
◧◩◪◨⬒
5. rahen+am[view] [source] 2022-05-11 09:57:04
>>keving+Mf
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.

[go to top]