Why is the DOS path character "\"? (2005)
web.archive.org
web.archive.org
;
; xenix file calls for MSDOS
;
TITLE XENIX - IO system to mimic UNIX
AVAILDEV = <TRUE or FALSE>
The default is TRUE which means both /dev/<dev> and
<dev> will reference the device <dev>. If FALSE is
selected, only /dev/<dev> refers to device <dev>,
<dev> by itself means a file in the current directory
with the same name as one of the devices.
A typical configuration file might look like this:
BUFFERS = 10
FILES = 10
DEVICE = /bin/network.sys
BREAK = ON
SWITCHAR = -
SHELL = a:/bin/command.com a:/bin -p
[1] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/...
[2] https://github.com/microsoft/MS-DOS/blob/master/v2.0/bin/CON...
;)
If we're picking on Linux here we should also mention that this issue cannot exist on Windows because it doesn't support anything else besides NTFS and a couple of options dating back to the 18th century or so.
Oh, and WinFS, of course, F being short for future which is like the horizon, or the communism, always out there just a month or two away.
What? Can you elaborate? I mean if you want non blocking IO from an fd in Linux, you can just do that. Not sure what defaults have to do with anything. Your code will still have to be written appropriately.
On NT the standard way is async, and doing things in the block-and-wait way is abnormal and unusual.
Defaults matter. Because that's what most people will do.
Since Vista, official support for a C++ subset.
In kernel IPC, namely LPC, to mimic micro-kernels architectures.
* it is optimized for integration with third party software from people who don’t have the source, so for instance the driver model is interesting
* the built in configuration system (the registry) and how it’s used throughout
* the (underused) personalities system you can use to show different apis to different binaries
* the security model is much more interesting, while in Linux you have ‘root’ and everything else, on Windows this is much more granular (unfortunately it’s so complex it’s basically impossible to use).
The architecture is really quite interesting, even though Microsoft didn’t make a lot of use of a large part of it.
Well, you do have:
- capabilities (which are so coarse-grained as to be practically useless)
- 8 types of namespaces
- seccomp-bpf
- LSM (AppArmor, SELinux, TOMOYO, etc)
A lot of innovations on NT are late as well to be fair, like the whole Application Views (?) of the system (basically an FS/Registry app sandboxing)
https://docs.microsoft.com/en-us/troubleshoot/windows-server...
Windows also differentiates between the human ADMINISTRATOR account and machine "root" accounts like "LOCALSYSTEM".
User accounts are also disambiguated by "domain"; ADMINISTRATOR on the local machine is not automatically the same as the domain-wide ADMINISTRATOR.
The limitation is that there is one user ID, 0 which can do everything and all the other IDs can do almost nothing.
This has nothing to do with domains and everything with the distinction you describe between the Windows Administrator, local system or even more powerful trustedinstaller accounts.
This does technically give Windows some advantage here as SID's are namespaced - you can have multiple domains in a forest, domain trusts, etc - but I don't think as far as realistic number of users accessing a network it makes much of a difference.
Where it does suck on Linux, however, is user namespaces. 32-bits is a lot when it comes to just giving out accounts, but it's nowhere near enough to give every user a 16-bit chunk of accounts for mapping the traditional 0-65535 (because nobody) ranges for use with unprivileged user namespaces. I'd really like to see a push for 64-bit uid/gid's for this reason.
Also, Windows SIDs are fixed-size 128 bit. They were supposed to be GUIDs, but they are not that random; user SIDs contain common prefix from the domain SID.
Linux has this, but it is, as you say, underused.
Sadly, that usually means it’s bugged as hell and impossible to use unless you’ve been trained for many years at ms to do that.
Hardware is actually mapped as an object namespace, which is presented to the user as the drive letters. This was exposed with Windows XP booting in safe mode; during the boot process it would print file paths as object paths, not drive paths.
Much as I'm more in the *nix way now, there's plenty of curiosities to explore and tinker in Windows.
Online the oldest is the 7th edition appendies which has details on A)Unix bsd B)Mach and c)windows 2000.
Windows 2000 was the next version of NT. Interesting if long reads about OS architecture.
http://bcs.wiley.com/he-bcs/Books?action=resource&itemId=047...
“ n the mid-1980s, Microsoft and IBM cooperated to develop the OS/2 operating system, which was written in assembly language for single-processor Intel 80286 systems. In 1988, Microsoft decided to make a fresh start and to develop a “new technology” (or NT) portable operating system that supported both the OS/2 and POSIX application programming interfaces (APIs). In October 1988, Dave Cutler, the architect of the DEC VAX/VMS operating system, was hired and given the charter of building this new operating system.”
The kernel itself is very interesting, regardless of what happened in the Linux world. If all you ever look at is Linux, you get stuck in Linux ideas of how things should, or even can, be done.
We'd finally have the GPL-licenced microkernel OS of Stallman's dreams.
And they were kind of right, the Year of Desktop UNIX/POSIX is WSL, Android, ChromeOS, macOS.
https://web.archive.org/web/20100612011533/http://thocp.net/...
You're right of course, I was just relaying what the post there said. There was prior usage as early as in the 1940s as you mentioned. According to Wikipedia, [1] its origins are unknown:
> As of January 2021, Wikipedia editors have not been able to find the origin of this character nor even the purposes to which it was put before the 1960s. The earliest known reference found to date is a 1945 bulletin from the Teletype Corporation that lists it as a replaceable part for its Wheatstone perforator.
On the other hand, I think it's safe to say it would have remained an obscure character had it not been for Bob Bemer.
Is there a name for this phenomenon? Everyone knows it’s a slash except when its used for something computery. Then it somehow becomes a backslash.
It's believed the 'pound' in pound sterling came from a pound of silver or silver coins in weight originally as well.
But confusing the name of the two slashes (how come?) has the exact opposite effect, so I don't like it.
There are many valid names and usages for this symbol: https://en.wikipedia.org/wiki/Number_sign#Names_of_the_chara...
Or are you saying 'hash-tag' is the name because although it's a mistake it's used so much now it's considered language?
Language isn't one big blob, even though among many people it could now be considered an alternative pronunciation, and eventually it could be adopted even in places where people would otherwise know better, right now among people in tech and certainly on this site 'hash-tag' to mean the character is incorrect and confusing.
But technically it's a solidus not a slash.
It was really weird working on it at first after having used both Unix systems and DOS for so long. I was very familiar with DOS and even used CP/M way back in the day when I was a teenager (I'm that old), VMS was a weird amalgam of a pretty advanced OS with a very capable command line environment like unix, but with a lot of conventions that felt familiar from DOS. I was a ware of some of the history of VMS influence on DOS so it was fascinating to work on and I quite enjoyed it even though it was clearly a dead end at that point.
The complete list of the 12 was: # $ @ [ ] \ ^ ` { } | ~. Notice that / is safe.
They avoided the problem for all the Western languages by inventing their own 8-bit code (this was before the ISO 8859 standards) and always using ASCII in the lower half.
https://int10h.org/oldschool-pc-fonts/fontlist/font?ibm_ega_...
http://www.cpm.z80.de/manuals/cpm3-cmd.pdf
The article is quite right that the convention of using / for command line switches came from IBM.
"DIR \W" does a DIR of the "\W" directory on the current drive.
"DIR /W" does a DIR listing in wide format.
(Another key difference is that on UNIX the shell expands '*' before passing it to a program, but CMD doesn't so each program has to do its own globbing)
"DIR/W" is the same as "DIR /W".
Which would have made it impossible to determine whether you want to invoke the command "DIR" in the current directory, or the command "W" in a subdirectory named "DIR".
Of course, they didn't use unixy paths for directories. A fully-qualified file name would be something like (and it's been decades so if I get it wrong forgive me) DRA0:[SYS.USERS.BREGMA.PROJECT.SOURCES]HELLO.C;1 and anyone who was sane would use logical names in DCL to make things readable.
On modern Windows you can use slash, but you have to quote the argument e.g. dir "C:/windows"
You can even mix both types together e.g. dir "C:/windows\system32" which is convenient when using code modules that only output unix style paths. No need to clean them up.
Backslash has no common use I know of outside of computer related stuff like regular expressions and escaping things.
Some of you might also have forgotten but on Mac pre OS-X, at least in standard Mac devtools provided by Apple the separator was colon :
Yeah, from the OS/360 wiki: "The file naming system allows files to be managed as hierarchies with at most 8 character names at each level, e.g. PROJECT.USER.FILENAME. This is tied to the implementation of the system catalog (SYSCTLG) and Control Volumes (CVOLs), which used records with 8 byte keys."
Post is still up here: https://docs.microsoft.com/en-us/archive/blogs/larryosterman...
and anyways, (2005).... here's plenty of other discussion from one of the previous posts:
I don't see the problem, but I guess it's just a personal preference.
We were at Microsoft quite some hours (and we seemed important enough to be fed lunch which consisted of very good sandwiches). One of the people who toured us around was a DOS developer (who in his 'spare' time also contributed to the Flight Simulator development). He spent considerable time discussing the new DOS subdirectory matter as it was a hot topic back then. Anyway, he received somewhat of a tongue-lashing from us about the backslash 'problem' and it was very clear to us that he too was not in favor of it although for obvious reasons he chose his words carefully.
This brings me to more ergonomic problems that Microsoft has never bothered to solve with its operating systems—DOS or Windows. The first I'll mention is the annoying reserved character problem, specifically: < > : " / \ | ? * cannot be used in a filename. I'm aware these characters are also deemed illegal in the filenames of other operating systems but I fail to see why after about 30 years that we still have to worry about avoiding them. If Microsoft had fixed the problem back then, then there would have been pressure for other operating system developers to also fix the problem. Just because other operating systems were behind the times, it didn't mean Microsoft had to be—after all, in the early days, Microsoft went to considerable trouble to please users in the useability stakes, even to the extent that it put security severely at risk in the process.
I fail to see why Microsoft couldn't have coded around this problem and allowed the use of these characters. It went part of the way by allowing spaces within filenames in Windows and it also allowed spaces to be entered into the command line filenames with quotes "My first Name.doc". The fact that these characters cannot be used has caused considerable trouble for IT staff over the years.
It'd hate to think how many thousands of hours have been wasted by both users and IT staff over the past three decades or so on what ought to have been a trivial matter to fix. Similarly, I hate to think how many times I've had to enter a ¿ into a filename just because the damn operating system will not let me enter normal question mark: ?.
Another major stuff-up is the maximum filename length/max path length of 254/255 - 260 when the path length could be potentially 32,767 characters—as it already calculates the path to this length internally (the exact length varies between O/S versions). These days, this limit is ridiculous. If, say, you have a file with a filename of say 245 characters long in directory \MyFiles then move the directory way down deep into nested directories then one automatically has a problem that one's not necessarily aware of until a cannot-continue crash occurs during a backup. Having to regularly run a Max-Path-Length utility across the disk to search for potential problems is a damn nuisance and it ought to be completely unnecessary.
Same problem occurs when saving web pages with long names, these often exceed the maximum filename length and the page cannot be saved without manual intervention. To say ≈255 characters for a filename is long enough is just not being realistic these days. Here's another instance: say one wants to save a book with a long title from the Internet Archive and to avoid confusion later over having a cryptic filename one adds the book's title to the already-cryptic IA filename, i.e.:
Books.<…>.with_very_long_names_are_common_on_the_IA_+_the_Internet_Archive_filename_abcxzy123.pdf
Many a time I've had the title combined with the IA O/S filename exceeds 255 characters, and sometimes it's by a large margin. Shortening the filename at this juncture wastes considerable time, especially if there are many files involved.
Oh, and there's another PIA worth mentioning: .MSI files cannot be loaded from a directory when the directory has a leading blank (space) in its filename whereas an .EXE file can. Now how did that come about (and it's never been fixed)? [Leading spaces in directories are useful as directories and files are automatically sent to the top of the file manager tree—which is a very useful technique I've adopted for years to highlight temporary work files or sorting directories, etc. Again, this is necessary due another operating system limitation, which is that neither DOS nor Windows has any way of allowing a user to order the file/directory structure to meet his or her needs.] Other obvious limitations are that we cannot highlight filenames or directories in that we cannot make them different colors or even have filenames with different typefaces. Why not?
As I've said for years, operating system developers don't care much about user ergonomics. If they did then by now we'd even have a new file system to replace the existing one which is truly antiquated. A new file system would include metadata extension(s) within files that OSes and programs would both understand (but that's a far too big a matter to discuss here).
When one thinks about it, we users really have been shortchanged by the likes of Microsoft and others over the years.
I don't know about all of the other reserved characters, but the colon is the path-separator character in classic Macintosh APIs and I doubt they would have ever been able to "fix" that.
> To say ≈255 characters for a filename is long enough is just not being realistic these days.
This was a limitation of old APIs and has been possible using the Unicode-aware APIs for a couple decades now, but as of Windows 10 it's possible to use long paths via the traditional APIs as well if an application declares a special manifest flag. Check out "Enable Long Paths in Windows 10, Version 1607, and Later" here: https://docs.microsoft.com/en-us/windows/win32/fileio/maximu...
Otherwise, try using those long paths as e.g. "\\?\C:\Users\Lammy\Downloads\Books.<…>.with_very_long_names_are_common_on_the_IA_+_the_Internet_Archive_filename_abcxzy123.pdf"
My number one peeve for a long time was "Documents and Settings" instead of "Users" on Windows XP, but I've come around to that once I realized it was probably intentionally-annoyingly-named to force app developers to use modern APIs since it seems to intentionally break the 8.3 length convention and force you to deal with escaping the spaces.
The fundamental issues is that users should be able to type any characters including colons that appear in day-to-day use, whether it be a book title, report name, movie title or whatever without ever having to worry about it.
The fact that they cannot do so and that they deliberately have to transcribe a name to another or shorten it to accommodate an operating system's limitations wastes time and leads to errors and confusion (anyone who has ever run an IT help desk in a large organization knows this).
I'm aware of the Win 10 'long paths' fix and I've also seen the registry patch which some suggest possibly fixes earlier versions of Win 10 (I've not tried the patch). That said, the filename length limitations remains a problem for two reasons - the filename is still too short and that many programs are likely to crash if filenames were to exceed 255 chr$ (as they'd be unaware of it). To overcome this, the operating system would have to also present a shortened 255-character filename to the program in the fashion it did back in the early days for programs that only understood 8 * 3 filenames. As I see it, it's only a halfhearted too-little-too-late tweak and the job needs to be done properly.
"My number one peeve for a long time was "Documents and Settings" instead of "Users" on Windows XP..."
This is still a problem, in fact it's a real pain. Right, D&S was a pain but so too is 'Users' and 'ProgramData', both should be completely movable even to the extent of having them work from a USB stick. Whenever I set up Windows it takes me days to configure my programs so as they dump their data/save files to specific locations on other drives (this makes transferring data to Linux etc. much easier and it's much safer too if files can be kept in locations where they aren't expected to be found). In fact, this should apply to all user info including users' program files. As I see it, these limitations are just bloody-mindedness on Microsoft's part (where the user isn't an administrator, the administrator would be able to still lock user directories and files to suit the local policy).
Yes, there was an excuse for the problem 20-30 years ago but not nowadays. Unfortunately, this is a 'mindset' problem of programmers. They're so used to acronyms and shortening things that they don't realize or care that ordinary users do not understand why they just cannot type anything as they did on typewriters (and something I've not yet mentioned: why they cannot type between already-typed lines or within margins, as the old-timers continually claim they once could do with ease but can no longer do so).
$ edit foo.txt
...
Ctrl-Z
$ dir
foo.txt;1
$ edit foo.txt
...
Ctrl-Z
$ dir
foo.txt;1 foo.txt;2
$ del foo.txt;
$ dir
foo.txt;1
https://news.ycombinator.com/item?id=26272844
So in principle they could have thought of having something like PATHCHAR=/ as well.
Discuss... :)
https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retra...
> This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.[26]
So much time, and therefore money, working around `\` escaping characters in file paths.
It is also worth looking at https://retrocomputing.stackexchange.com/questions/4695/slas... where there is some discussion of the history.
Along with https://retrocomputing.stackexchange.com/questions/7030/why-...
and
https://retrocomputing.stackexchange.com/questions/4686/wher...
> (I still think the Multics path seperator looks more natural >etc>bin - too bad Unix diverted here)
Looks more natural indeed. In fact it's visually similar to how paths are stylised in some file picker GUIs.
Imagine their horror when having to type AltGr+- to get a backslash. At least with Shift you can choose which of the Shift keys to use, but there is only one AltGr key (it is to the right of the spacebar, the US keyboard layout has the right Alt key there). It used to be you could use Ctrl+Alt+-, too, and at least those were available on the left hand side, too. But I do not know if Ctrl+Alt works nowadays.
Those that are too stubborn to use QWERTY, yes. Seriously, the german keyboard layout is horrible for programming and the few umlauts can easily be entered using compose keys / dead keys / alt combinations / whatever you fancy.
rmdir /f /usr
Is that force-deleting the /usr directory, or the /usr and /f directories?
rd /s /q \path\to\something
Also, most non-unix operating systems that don't happen to be made by Microsoft also use the forward slashes for paths.
The average user ignores the contents of the address bar. "That's all tech gobbledegook". Increasingly, browsers even hide its contents from the user, just displaying the domain name, making the average user even less aware of it.
> Also, most non-unix operating systems that don't happen to be made by Microsoft also use the forward slashes for paths.
What are "non-unix operating systems that don't happen to be made by Microsoft". Non-Microsoft operating systems in common use – Linux (including Android), macOS/iOS/Darwin/XNU, *BSD – are Unix-like, and hence I wouldn't really call them "non-unix" (even if they are not strictly speaking certified as such)
If we look at non-Microsoft non-Unix(-like) operating systems (none of which are commonly encountered nowadays), we see a lot which use neither forward nor backslashes for directories. For example, OpenVMS and RISC OS both use dots, classic MacOS used colons. Stratus VOS uses the greater-than sign, which it inherited from Multics. The IBM mainframe operating system MVS (nowadays called z/OS) uses dots to separate the components of a dataset name – although those components aren't exactly directories. (It also supports forward slashes in its Unix compatibility subsystem, but that wasn't around for the first 25 years of its existence.)
It's a pretty big list. To name a few:
Beos (and derivatives), AmigaOS (and derrivatives), GEOS, Commodore DOS, Temple OS, TRON, plenty of Real Time Operating Systems...
I personally think Unix allowing almost any character in filenames was a mistake. You can put newlines and other control characters in filenames. That has very little legitimate use, and is a potential source of security and other bugs. There is a proposal to amend the Unix standards to disallow control characters in filenames. But it doesn't look like it is going to be successful: https://www.austingroupbugs.net/view.php?id=251
Most Unixes don't allow any character; they allow any byte other than ascii slash or zero. Turning bytes into characters is outside the scope of most Unix kernels and the filesystems therein.
All the major contemporary Unix(-like) kernels do have code in them to do file path charset translation. It is very important when dealing with removable media (ISO-9660, UDF), FAT filesystems, network filesystems (especially CIFS/SMB, but even some NFS implementations), filesystems defined in terms of Unicode such as NTFS, HFS+, APFS.
Traditional Unix filesystems don't do this, but they were originally designed at a time when few clearly distinguished the concept of byte from the concept of character.
Shell scripting would be so much more sane (and safe) if filenames couldn't contain spaces (or control chars) and couldn't begin with a '-' character. Then the shell's default $IFS would work as intended in the presence of pathname expansion, and there would be no need to use '--' to delineate the filename arguments from the option arguments when executing commands.
> They couldn't use the *nix form of path separator of "/", because the "/" was being used for the switch character.