I've used both the original MS/DOS and IBM's CMS, but never made the connection between both of them using drive letters. It just seemed like a natural way of concisely referring to disk devices.
In current Windows systems without floppy drives, you can map A: and B: to network drives with the NET USE command, just like any other unused drive letter.
> I've used both the original MS/DOS and IBM's CMS, but never made the connection between both of them using drive letters. It just seemed like a natural way of concisely referring to disk devices.
I've used both of them too and in the case of CMS the one thing I didn't like about it was the lack of tree-structured directories. You couldn't easily explore the filesystem without them. Also, if I remember correctly, the drives addressed by letters were virtual drives - certainly our IBM 4381s did not have 26 physical drives :)
Still, I wrote a lot of useful software in CMS, so perhaps it's not that important.
I think CMS finally added tree structured directories, but it was after I was using it regularly so I never used them much.
> Also, if I remember correctly, the drives addressed by letters were virtual drives
In most cases they were virtual drives (attached to your virtual machine) that were mapped to a set of contiguous cylinders on a physical drive. (But you could allocate a virtual drive that consisted of an entire physical drive if you wanted to, which could be useful if you wanted an entire device to be managed by some guest operating system that was running in a VM/370 virtual machine.)
If you map A: but not B: do you still get B: mapped to the same drive, as you would in a computer with only one floppy drive, or does that magic only apply to drives that hold removable media?
A better question is why are hard drives still being assigned drive letters? Multiple "roots" in the file system hierarchy is just plain stupid. You need to special case your path navigation commands for for drive letters. (E.g. cd v/s cd /d). etc.
I had an old Windows machine with 2 drives (C and D of course). I wanted to use it for Linux but keep the old system. I moved all of D into a directory on C, but obviously all the old paths would be wrong. But it turns out that tinkering with the registry I could declare the new folder as D!
I wonder what would happen if you called it A or B?
It's not mandatory. You can tell Windows not to assign a letter to a new volume (but I wouldn't try to remove the assignment from C:). And you can mount new volumes under an empty directory, just like *nix.
The best place to do this is in the Disk Management app. The easiest way to access it is via the Win+X menu.
In the command line in Windows you can still do magical things like, say you want to convert some videos in D:\Videos\ and ffmpeg is in C:\Program Files\ffmpeg\bin . You can open the command line and enter:
D: # changes to D: Drive
cd Videos # enter the Videos directory
cd "C:\Program Files\ffmpeg\bin"
At this point the prompt will still say D:\Videos>
and you can type "C:ffmpeg my-movie.avi" and Windows will execute ffmpeg from the "current directory" of the C: drive, but process the file D:\Videos\my-movie.avi .
The root of the hierarchy being one of the arbitrary drives seems a bit strange. Why is my USB stick (a physical thing I can hold) part of a Linux partition of my hard disk?
Having fixed letters is a bit antiquated, but drives as separate entities seems to match the real world quite well.
>> Why is my USB stick (a physical thing I can hold) part of a Linux partition of my hard disk?
It is not part of the partition. It is just an arbitrary path that is mapped to your USB stick. You can choose where you want it to be mapped depending on your needs and what you are trying to do. There are conventions about where most Linux distributions will map removable media (/mnt or /media), but conventions do not have to be followed if you do not want to.
The "one filesystem" design of Unix / Linux is all about abstraction. Anything that follows file-like conventions can be mapped into the filesystem. For example, on Linux there is a virtual filesystem under /proc.
"/proc is very special in that it is also a virtual filesystem. It's sometimes referred to as a process information pseudo-file system. It doesn't contain 'real' files but runtime system information (e.g. system memory, devices mounted, hardware configuration, etc). For this reason it can be regarded as a control and information centre for the kernel. In fact, quite a lot of system utilities are simply calls to files in this directory. For example, 'lsmod' is the same as 'cat /proc/modules' while 'lspci' is a synonym for 'cat /proc/pci'. By altering files located in this directory you can even read/change kernel parameters (sysctl) while the system is running."
Are there any mainstream distros (not things like OpenWRT) that have / as not-your-main-hard-disk though? If / were some abstract place then sure it would make sense, but that isn't usually the case.
GP's point was that the flash drive, which is not the hard disk, is mapped to a filepath under /, which is the hard disk. The pathing seems to imply that the flash drive is inside the hard disk, whereas on Windows they have distinct roots. GP suggests that / should instead refer to an imaginary place under which both the flash drive and hard disk reside.
This allowed them to run very fast since the entire base filesystem was in RAM and also be ephemeral since the filesystem would disappear on reboot or power off.
Your could still mount the computer's hard disk or other removable disks, but / was in RAM.
Other larger Linux live CD / live USB distributions such as Knoppix (https://en.wikipedia.org/wiki/Knoppix) would place a core portion of the system on a RAM disk and then read from the CD / USB to get other files as needed.
Plan 9 (https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) is not a Linux distro, but a Unix successor that extended the "everything is a file" Unix idea even further to allow multiple computers to act as one using the 9P protocol. This means that you could "mount" server _programs_ running on other computers somewhere under / and use file-like operations to interact with them. Almost like a REST API, but with 9P instead of TCP and file-like I/O instead of HTTP GET, PUT, and POST.
I've used Linux primarily since Debian potato, but the great wizards have not yet convinced me that the tree, starting at the holy / and a system with binaries, their data and their libraries spread throughout the system is a wiser way than each partition an island, and each program living with all it needs in its own folder.
I have heard the arguments but I have learned nothing.
Each program in Windows does not live with all its needs in its own folder though. Some store some of their stuff in the installation directory, others in AppData, others in ProgramData, others in the User's home folder (C:/<username/...) and so on.
I've got lots of programs that are entirely self-contained and the folder can simply be moved to a new computer and it "just works", they include all the data files and dll's they want, and they keep their user-data under their own directory too, which is exactly how I want it for a _PERSONAL_ computer.
That's fine. But it's not really a standard. Just an approach, and not one that is guaranteed to work unless that's an explicit goal for the program involved.
Tbf, you can do the same thing on Linux with AppImages.
You can do the same with normal linux programs too, mine work fine, but the insistence of pulling apart a program and spread throughout the filesystem is in my opinion misunderstood. Sure, it made sense when it was introduced, for the reasons it was introduced, mainly, that drives were so small that you had to.
There are very very few cases today where your program and it's accompanying files are so large that they cannot be expected to live on only a single disk.
Well, you're conflating two things there - a unified filesystem starting at /, and the pattern of organization that puts all runnable binaries into one location.
The filesystem, on unix-like systems, is a namespace that contains every resource on the system (everything is a file). / is the root of the namespace. There is no good reason for a particular physical disk used to store some data to be at the root of the namespace; it's an implementation detail, and maybe not even the correct implementation detail. You might want to back a particularly weighty location with a larger disk, or a faster disk, or you might even want to run your system entirely off NFS. The filesystem abstracts all that away from applications. You can arrange your data physically however you like, and with a few lines in fstab, only the lowest levels of the OS need to know about it. You can also change all this on the fly. Contrast with Windows, where running out of space on disk C - THE disk, decided at installation and forever unchangeable - is a catastrophe, and there's no way of moving a weighty program to another disk without "reinstalling" it.
The advantage IMO is that programs don't care what physical drive they are on. On the Windows side I've run into a few that refuse to be installed on anything BUT C: even if D: or E: is a perfectly good or maybe even the same HDD.
As mostly a Windows user, I like the macOS approach. Applications go to /Applications/, application data go to ~/Library/Application Support, settings go to ~/Library/Preferences. Installing an application is mostly done by drag and dropping to Application directory. To delete an app, just delete it from Applications directory.
"GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way."
It's a shame AmigaOS' volume system never caught on. It would have solved the problems the article describes re. drive letter assumptions:
"Assign A: DH0:" - Problem solved!
I really miss how you could assign drive names to disks too, so you might have some reference to a file on a particular disk and it would prompt you to insert that specific disk (into any convenient floppy drive) and if you got the wrong disk it would know and ask you again.
Otoh I don't miss all the swapping between the 5 floppies that SAS C compiler came on before I finally got my hands on a humongous 40 megabyte hard drive.
Also remember how the drives would click every second to check if you had actually inserted anything and how there was some freeware anticlick program on one of the Fish disks that reconfigured to somehow work without the annoying clicky noise. (Or you could just feed it a disk). Fun times.
So... recently I've started using a physical box running Debian for some retro computing work (dd'ing images etc.) and I have a need to use a USB floppy drive.
I think there is some daemon running in the background trying to automount stuff, as the USB drive constantly clicks when empty just like the Amiga used to.
There used to be a weird trick here: Who says drive letters have to be letters? If you had more than 26 drives, msdos just took whatever was in the ascii table after Z: . This was easy to cause with network drives. Programs mostly just went with it unquestioningly. I don 't remember what happens if your drive letter itself is a backslash.
A few years ago it was still possible to do stuff like
subst ?: C:\somepath
Then you had a drive ?: which was accepted by half of your programs but not the others.
I don't have a win10 laying around so I can't test if this is still true today.
Yes that still works under Windows 10/11. Useful if you are working in the command line, and have tools somewhere else that you are accessing (that are not in the PATH) and you get tired of typing the full path to the tools.
I don't think subst is a good idea for security purposes. You can't hide the original drive, some tools look right trough it, and UNC path names allow other ways.
Windows has the concepts of window stations and sessions. One of these 2 is the namespace for drive letters, as it allows different rdp users to have their own network drives, and also give services their own security context . Take sysinternals winobj to look around. Maybe you can build something chrootlike out of it, I dont really know, I am a bit out of my depth here.
Fun sidebar fact: Under MS-DOS you can't go higher than E: without issuing the LASTDRIVE=x command in config.sys (Where x is the maximum drive letter you want to go up to)
53 comments
[ 3.3 ms ] story [ 89.1 ms ] thread"Oh, that's what we used before we had hard disks".
"Hard disks? What's that"?
"Well, it's a kind of permanent data storage for computers".
"..."
"..."
"Grampa, what's 'computers'"?
Feel bettter now? :P
In current Windows systems without floppy drives, you can map A: and B: to network drives with the NET USE command, just like any other unused drive letter.
I've used both of them too and in the case of CMS the one thing I didn't like about it was the lack of tree-structured directories. You couldn't easily explore the filesystem without them. Also, if I remember correctly, the drives addressed by letters were virtual drives - certainly our IBM 4381s did not have 26 physical drives :)
Still, I wrote a lot of useful software in CMS, so perhaps it's not that important.
> Also, if I remember correctly, the drives addressed by letters were virtual drives
In most cases they were virtual drives (attached to your virtual machine) that were mapped to a set of contiguous cylinders on a physical drive. (But you could allocate a virtual drive that consisted of an entire physical drive if you wanted to, which could be useful if you wanted an entire device to be managed by some guest operating system that was running in a VM/370 virtual machine.)
Backwards compatibility. I agree it is unfortunate.
I wonder what would happen if you called it A or B?
The best place to do this is in the Disk Management app. The easiest way to access it is via the Win+X menu.
\\machine\c\your_folders \\machine\d\yet_more_folders
D: # changes to D: Drive
cd Videos # enter the Videos directory
cd "C:\Program Files\ffmpeg\bin"
At this point the prompt will still say D:\Videos>
and you can type "C:ffmpeg my-movie.avi" and Windows will execute ffmpeg from the "current directory" of the C: drive, but process the file D:\Videos\my-movie.avi .
Having fixed letters is a bit antiquated, but drives as separate entities seems to match the real world quite well.
It is not part of the partition. It is just an arbitrary path that is mapped to your USB stick. You can choose where you want it to be mapped depending on your needs and what you are trying to do. There are conventions about where most Linux distributions will map removable media (/mnt or /media), but conventions do not have to be followed if you do not want to.
The "one filesystem" design of Unix / Linux is all about abstraction. Anything that follows file-like conventions can be mapped into the filesystem. For example, on Linux there is a virtual filesystem under /proc.
"/proc is very special in that it is also a virtual filesystem. It's sometimes referred to as a process information pseudo-file system. It doesn't contain 'real' files but runtime system information (e.g. system memory, devices mounted, hardware configuration, etc). For this reason it can be regarded as a control and information centre for the kernel. In fact, quite a lot of system utilities are simply calls to files in this directory. For example, 'lsmod' is the same as 'cat /proc/modules' while 'lspci' is a synonym for 'cat /proc/pci'. By altering files located in this directory you can even read/change kernel parameters (sysctl) while the system is running."
Source: https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.ht...
What's wrong with it being your main hard disk?
Sort of.
Some smaller Linux live CD / live USB distributions such as Damn Small Linux (DSL) (https://en.wikipedia.org/wiki/Damn_Small_Linux) and Puppy Linux (https://en.wikipedia.org/wiki/Puppy_Linux) had the option to load the entire distribution into memory (RAM disk) and run completely from memory.
This allowed them to run very fast since the entire base filesystem was in RAM and also be ephemeral since the filesystem would disappear on reboot or power off.
Your could still mount the computer's hard disk or other removable disks, but / was in RAM.
Other larger Linux live CD / live USB distributions such as Knoppix (https://en.wikipedia.org/wiki/Knoppix) would place a core portion of the system on a RAM disk and then read from the CD / USB to get other files as needed.
Plan 9 (https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) is not a Linux distro, but a Unix successor that extended the "everything is a file" Unix idea even further to allow multiple computers to act as one using the 9P protocol. This means that you could "mount" server _programs_ running on other computers somewhere under / and use file-like operations to interact with them. Almost like a REST API, but with 9P instead of TCP and file-like I/O instead of HTTP GET, PUT, and POST.
I have heard the arguments but I have learned nothing.
Tbf, you can do the same thing on Linux with AppImages.
There are very very few cases today where your program and it's accompanying files are so large that they cannot be expected to live on only a single disk.
The filesystem, on unix-like systems, is a namespace that contains every resource on the system (everything is a file). / is the root of the namespace. There is no good reason for a particular physical disk used to store some data to be at the root of the namespace; it's an implementation detail, and maybe not even the correct implementation detail. You might want to back a particularly weighty location with a larger disk, or a faster disk, or you might even want to run your system entirely off NFS. The filesystem abstracts all that away from applications. You can arrange your data physically however you like, and with a few lines in fstab, only the lowest levels of the OS need to know about it. You can also change all this on the fly. Contrast with Windows, where running out of space on disk C - THE disk, decided at installation and forever unchangeable - is a catastrophe, and there's no way of moving a weighty program to another disk without "reinstalling" it.
"GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way."
It's a shame AmigaOS' volume system never caught on. It would have solved the problems the article describes re. drive letter assumptions: "Assign A: DH0:" - Problem solved!
I feel really old now.
Otoh I don't miss all the swapping between the 5 floppies that SAS C compiler came on before I finally got my hands on a humongous 40 megabyte hard drive.
Also remember how the drives would click every second to check if you had actually inserted anything and how there was some freeware anticlick program on one of the Fish disks that reconfigured to somehow work without the annoying clicky noise. (Or you could just feed it a disk). Fun times.
I think there is some daemon running in the background trying to automount stuff, as the USB drive constantly clicks when empty just like the Amiga used to.
Very irritating.
A few years ago it was still possible to do stuff like
Then you had a drive ?: which was accepted by half of your programs but not the others.I don't have a win10 laying around so I can't test if this is still true today.
> subst ?: C:\somepath
>Then you had a drive ?: which was accepted by half of your programs but not the others.
Neat! Like a Windows version of chroot? Can it be used to stop programs from accessing C?
Windows has the concepts of window stations and sessions. One of these 2 is the namespace for drive letters, as it allows different rdp users to have their own network drives, and also give services their own security context . Take sysinternals winobj to look around. Maybe you can build something chrootlike out of it, I dont really know, I am a bit out of my depth here.
As a DoS of DOS: x:\> copy c:\config.sys CLOCK$
Also special DOS filenames:
https://superuser.com/questions/1362080/which-characters-are...Print autoexec.bat to the dot matrix printer on LPT1?
Create a file called foo.txt without an editor? A social DoS of any machine with BASIC or similar. When good floppies go bad: