_______               __                   _______
|   |   |.---.-..----.|  |--..-----..----. |    |  |.-----..--.--.--..-----.
|       ||  _  ||  __||    < |  -__||   _| |       ||  -__||  |  |  ||__ --|
|___|___||___._||____||__|__||_____||__|   |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web

COMMENT PAGE FOR:
URI   Why is the DOS path character "\"? (2005)

ChrisArchitect wrote 2 days ago:
why post this wayback version?

Post is still up here: [1] and anyways, (2005)....
here's plenty of other discussion from one of the previous posts:

URI  [1]: https://docs.microsoft.com/en-us/archive/blogs/larryosterman/w...
URI  [2]: https://news.ycombinator.com/item?id=3723355

ratsmack wrote 2 days ago:
>*nix defines hierarchical paths with a simple hierarchy rooted at "/"
- in *nix's naming hierarchy, there's no way of differentiating between
files and directories, etc (this isn't bad, btw, it just is).

I don't see the problem, but I guess it's just a personal preference.

thesuitonym wrote 2 days ago:

hilbert42 wrote 2 days ago:
During the time DOS 2.0 was in development, I visited Microsoft with a
group of colleagues.  (We were touring computer manufactures both in
Seattle and in Silicon Valley (where we visited Digital Research, Intel
and many othersâin those days it was comparatively easy to visit
these enterprises for a tour.)

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
i.e.:

Books.<â¦>.with_very_long_names_are_common_on_the_IA_+_the_Internet_Ar
chive_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.

Lammy wrote 2 days ago:
> If Microsoft had fixed the problem back then, then there would have
been pressure for other operating system developers to also fix the
problem.

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: [1]
Otherwise, try using those long paths as e.g.
mmon_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.

URI    [1]: https://docs.microsoft.com/en-us/windows/win32/fileio/maximu...

mycall wrote 2 days ago:
I was happy when I learned that "Docume~1" worked for "Documents
and Settings".

hilbert42 wrote 2 days ago:
"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."

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). bsenftner wrote 2 days ago: The person that made this decision was the author of the original DOS - Al (Allan) Alcorn. I had a conversation with him nearly 2 decades ago about this very subject. I remarked to him how using the "opposite slash" caused grief for untold numbers of developers. His reply was "yeah, I know. It was a poor decision, and I remember it clearly. I was trying to make DOS a bit unique, and that was all. It was stupid, in retrospect." From the author's mouth. chasd00 wrote 2 days ago: Funny, i've always imagined it was chosen only because it wasn't a regular slash like other systems. I never mentioned it though because i figured I was wrong. greggman3 wrote 2 days ago: Personally I find unix or whatever OS chose / as the bad choice. / is a commonly used character, at least in the USA as dates. It would completely normal for someone to want to name a file "Meeting 12/20/1980.txt" or "Budget Sep/12/1985.doc" 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 : jhallenworld wrote 2 days ago: RM/COS used . as a path separator. I think this is from OS/360. It makes sense to me in that member selection in C also uses '.'. 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." michaelcampbell wrote 2 days ago: My son used to use \ for dates when he was learning to write; to the point I wondered if he was somewhere above 0 on the dyslexia scale. He's 20 now, and I think has grown out of it. kps wrote 2 days ago: Backslash has no non-computer use since it was invented for ASCII to represent ââ§â and ââ¨â as â/\â and â\/â. emondi wrote 3 days ago: Where it says FileName.Extension[,Version] MONITR.EXE,4 What was the version used for? Did it track the changes? SloopJon wrote 2 days ago: I don't know about DEC-20, but on VMS, changing a file makes a copy with a new version number:$ edit foo.txt
...
Ctrl-Z
$dir foo.txt;1$ edit foo.txt
...
Ctrl-Z
$dir foo.txt;1 foo.txt;2 When you delete a file, you have to specify a version field (blank for latest):$ del foo.txt;
$dir foo.txt;1 IIRC, you can configure how many versions to keep. tragomaskhalos wrote 2 days ago: Yes that's right, the versions to retain was configurable, and the whole versioning mechanism was really useful and a great miss from today's OSes. The VMS file and directory syntax otoh was a real pain, Unix definitely wins there. vincent-manis wrote 2 days ago: The version number was used the same way in TOPS-20 (which I never used) and Tenex, its predecessor (which I did). Emacs still has a facility for numbering backup files in the same way. timonoko wrote 3 days ago: All wrong. "/" was the options-switch-character in CP/M, which had no sub-directories. DECs and VAXes had nothing to do this decision, because only few humans had access to such machines. I even remember I had problems adapting to directory trees in MSDOS because files were kinda hidden and lost in a floppy directory. simonh wrote 2 days ago: It's true that DOS was originally a CP/M clone, but CP/M didn't have a defined standard option switch character, and in fact many command option switches weren't preceded by a switch indicator or differed as to what option switch character was used. If anything + and - were the most common prefixes for an option switch. [1] The article is quite right that the convention of using / for command line switches came from IBM. URI [1]: http://www.cpm.z80.de/manuals/cpm3-cmd.pdf culturedsystems wrote 2 days ago: CP/M was surely the direct influence. Wikipedia says CP/M was itself influenced by TOPS-10, which I think also used the slash for options, so the ultimate origin may be with DEC. tgv wrote 2 days ago: CP/M had them because of DEC, IIRC. Commands like "DIR" and "TYPE" are also indicative. And "PIP". SulphurCrested wrote 3 days ago: It was an unfortunate choice because \ is one of the 12 characters that vary between country versions of ISO 646 (of which ASCII was the US profile). This was why Japanese MS-DOS used Â¥ instead of \ for the directory separator: it occupied the same code point in the Japanese profile of ISO 646 that \ did in ASCII, and Shift-JIS encoded that as a single byte with the high bit clear. 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.

hackerbabz wrote 3 days ago:
Do you correct people when they say âback slashâ when reading out a
url? When itâs actually a forward slash?

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.

chaorace wrote 2 days ago:
Contextually, yes. Sometimes it matters, sometimes it doesn't. Same
thing goes for the dash/underscore distinction. I imagine there must
be similar grappling in the editor world between usages of dash vs.
hyphen

bregma wrote 3 days ago:
I have to suppress the urge to correct people both when they refer to
it as a backslash and when they use the term "forward slash". I've
already lost all my friends by being that guy; I don't need to also
earn the enmity of random strangers on the internet.

But technically it's a solidus not a slash.

jimmaswell wrote 2 days ago:
Nothing is wrong with "forward slash.

bregma wrote 2 days ago:
"forward slash" vs. "forward backslash" would be more consistent.

veltas wrote 3 days ago:
I don't have an answer but it's exactly the same phenomenon as when
people refer to '#' as a hash-tag.

hackerbabz wrote 2 days ago:
That's not the same at all. Hash-tag is just a name for that
symbol. It's not the original name, but it is a name. "/" is slash!
"\" is a backslash! People who do not type windows paths have
probably never actually encountered a backslash in their entire
lives, but when they see a url they think that the symbol they see
all the time in other contexts (/) suddenly has a different name!

veltas wrote 2 days ago:
A 'hash-tag' is a feature of internet apps like Twitter where you
put a '#' in front of some topic name to relate your content with
similar content. It's named after the character which is known as
a 'hash' among other things.

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.

hackerbabz wrote 1 day ago:
But there isnât another character that anyone calls
âhashtagâ. Itâs like if everyone nontech called â:â a
âsemicolonâ only when itâs preceeded by âhttpâ. There
is something else called semicolon and its not the thing in the
url.

dylan604 wrote 2 days ago:
I remember it being the number sign when first learning to type in
school. I then heard it refered to as pound sign. And once I
started into the dev world, it became the ubiqutous comment. Then
my favorite became the shebang when paired with the friendly
bang/exclamation/pling.

lovegoblin wrote 2 days ago:
What you mean the octothorpe?!

There are many valid names and usages for this symbol:

URI        [1]: https://en.wikipedia.org/wiki/Number_sign#Names_of_the_c...

vcanales wrote 2 days ago:
everyone knows it's called 'tictactoe'

mbg721 wrote 2 days ago:
Or you can raise musicians' blood pressure by calling it a
sharp-sign.

marcosdumay wrote 2 days ago:
I'm content because that character finally has a name that people
will recognize.

But confusing the name of the two slashes (how come?) has the exact
opposite effect, so I don't like it.

timoth3y wrote 3 days ago:
Exactly. Everyone knows it's an octothorp.

chasd00 wrote 2 days ago:
i've just started calling it "shift 3". that seems to be the
least confusing way to communicate the character haha

dylan604 wrote 2 days ago:
Is it shift-3 on all keyboards? Maybe it is, but I've seen
other keyboard layoutss where symbols are in different
locations.

pwinnski wrote 2 days ago:
That will usually work in the US, but Shift-3 returns Â£ on
keyboards configured for the UK!

kbelder wrote 2 days ago:
Is that related in any way to the fact that both symbols can
be referred to as a 'pound' symbol, or is it a complete
coincidence?

veltas wrote 2 days ago:
I believe it is related to them both being called 'pound',
and it is very annoying. The two are not the same symbol, I
don't know why they equivocated them. Technically in a
distant root they are related, but they are distinct in
usage and meaning.

paulmooreparks wrote 2 days ago:
Just don't call it "pound" when standing in Britain. :)

veltas wrote 2 days ago:
I live in Britain and don't have an issue with it, '#' is
originally a symbol for pounds, a shorthand for 'lb', and we
are used to the idea that pounds can mean weight, as well as
our currency, so why not this symbol as well?

It's believed the 'pound' in pound sterling came from a pound
of silver or silver coins in weight originally as well.

agys wrote 3 days ago:
It bothered me as a kid that the (ROM) font used in DOS had different
thickness for slash and backslashâ¦ it wasnât just a mirrored glyph.

URI  [1]: https://int10h.org/oldschool-pc-fonts/fontlist/font?ibm_ega_8x...

Minor49er wrote 2 days ago:
Me too, particularly since some of my favorite programs (various DOS
games, especially MegaZeux) used text mode for their graphics

toolslive wrote 3 days ago:
hm, because of CP/M, no?
it's also where the drive letters came from (and some command names)

inglor_cz wrote 3 days ago:
You mean CP\M? :-)

DrBazza wrote 3 days ago:
Probably the second most expensive mistake after 'null'.

Discuss...  :)

burntoutfire wrote 3 days ago:
What 'null' mistake?

DrBazza wrote 3 days ago:
Tony Hoare apologising for inventing the null reference: [1] > 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.

URI      [1]: https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_ret...

r00f wrote 3 days ago:
Can anyone explain why was that a problem, from technical point of
unix with just "/". Why would it be a problem for parser to distinguish
between filepaths and arguments switch?

hnick wrote 3 days ago:
Paths can drop the drive letter e.g. del \file will try to delete a
file in the root of the current drive.

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.

skissane wrote 3 days ago:
Because paths don't have to start with a drive letter â a path like
\foo\bar is relative to the current drive.

"DIR \W" does a DIR of the "\W" directory on the current drive.

"DIR /W" does a DIR listing in wide format.

kijin wrote 3 days ago:
Even worse, there was (and still is) no requirement for a command
and its switches to be separated with whitespace.

"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".

bregma wrote 3 days ago:
The DEC operating systems (eg. RSX with its MCR shell and VMS
with its DCL shell) also handled command-line switches this way
(eg. PIP/LIST to list files in a directory).

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.

r00f wrote 3 days ago:
I see, didn't know that

pjc50 wrote 3 days ago:
Yes, and this is absolutely maddening when trying to do
cross-platform work because some programs support / in filenames
while others interpret them as arguments.

(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)

ynik wrote 1 day ago:
Pretty much all Windows programs support / in filenames.
The main issue is some cmd builtins like mkdir/cd/del which
have weird parsing rules where every / is interpreted as
starting a command-line switch, even if not preceded by a
space.
But even there, you only need to use quotes (mkdir "c:/test")
to suppress the interpretation as a switch and then you can use
paths with slashes just fine in batch files.

kiwidrew wrote 3 days ago:
Thanks to Microsoft's recent release of the MS-DOS 2.0 source code, we
can now peek under the hood and confirm that Microsoft specifically
intended for the DOS 2.0 file APIs to be compatible with Unix.    From
XENIX.ASM [1], the code that implements the new API:

;
; xenix file calls for MSDOS
;

TITLE   XENIX - IO system to mimic UNIX

And the CONFIG.DOC [2] file discusses the 'AVAILDEV' option which lets
the system mimic Unix even more:

AVAILDEV =
The  default  is  TRUE which means both /dev/ and
will reference the device .   If  FALSE  is
selected,  only  /dev/    refers    to  device ,
by itself means a file in the current    directory
with the same name as one of the devices.

Finally, an example CONFIG.SYS file from the same document:

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

I think it's pretty clear how Microsoft intended for MS-DOS to be
configured, but alas IBM had other ideas... [1]

URI  [1]: https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/XE...
URI  [2]: https://github.com/microsoft/MS-DOS/blob/master/v2.0/bin/CONFI...

pjmlp wrote 3 days ago:
Well, there is this different timeline in the universe where
Microsoft decides to keep selling Xenix instead of focusing on
MS-DOS.

sophistc wrote 3 days ago:
... and where it is not successful.

pjmlp wrote 3 days ago:
That we will never know, Xenix was the most successful PC UNIX
clone after all, Microsoft just decided UNIX wasn't the future of
PCs.

And they were kind of right, the Year of Desktop UNIX/POSIX is
WSL, Android, ChromeOS, macOS.

I really look forward to the day NT's source is released. It's a
truly fascinating kernel. Imagine somebody building an entire Unix on
top of NT! Like WSL, but even beyond.

sophistc wrote 3 days ago:
NT originally had a Unix subsystem:

URI      [1]: https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

Yeah, and WSL1 was something similar, but I was suggesting just
Unix here, no Win32. Imagine GNU/NT!

HeckFeck wrote 2 days ago:
If someone wanted to attempt this absolute bastardisation of
God's will, you could try porting the GNU userland to run atop
the ReactOS kernel.

We'd finally have the GPL-licenced microkernel OS of Stallman's
dreams.

wruza wrote 2 days ago:
Apart from fork() and custom async io (epoll, iocp) arenât
they pretty compatible even without cygwin? GNU relies on POSIX
(afair), so wouldnât NT features be unused extra?

pram wrote 3 days ago:
Isn't that what SFU was?

john4532452 wrote 3 days ago:
What special about NT kernel that's not in linux kernel ?

thesuitonym wrote 2 days ago:
Is the fact that it's a very stable and robust kernel that
evolved over different means, with different priorities and
expectations not enough?

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.

acomjean wrote 2 days ago:
My os book in college had an appendies on various OS.

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
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.â

URI        [1]: http://bcs.wiley.com/he-bcs/Books?action=resource&itemId...

tinus_hn wrote 3 days ago:
* It is (with a lot of ifs and buts) a microkernel

* 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.

HeckFeck wrote 2 days ago:
If I'm not mistaken, the Win32 API is actually a subsystem to
the NT kernel. You can call the kernel itself a layer below
with functions beginning with 'nt*'.

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.

wruza wrote 2 days ago:
The architecture is really quite interesting, even though
Microsoft didnât make a lot of use of a large part of it.

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.

msla wrote 2 days ago:
> the (underused) personalities system you can use to show
different apis to different binaries

Linux has this, but it is, as you say, underused.

URI          [1]: https://man7.org/linux/man-pages/man2/personality.2.ht...

macksd wrote 2 days ago:
I'm very intrigued by that list. Any recommendations on where

tinus_hn wrote 2 days ago:
Thereâs books but also the ReactOS project has been working
for many years on replicating the functionality, so you can
look at their source.

helloooooooo wrote 2 days ago:
Windows Internals 7th edition

>in Linux you have ârootâ and everything else

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)

pjc50 wrote 3 days ago:
The big difference is when you're in a multi-computer (Active
Directory / NIS / LDAP) environment. On UNIX all the IDs are
smallish integers, so you have to be careful to ensure
they're unique and non-overlapping. On Windows you have a
"SID" which is variable length and (for users) usually a big
random number. [1] 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

URI            [1]: https://docs.microsoft.com/en-us/troubleshoot/window...

tinus_hn wrote 3 days ago:
Linux User IDs since decades are 32 bit integers; you can
just use some mapping system to allocate them automatically
and youâll never run out.

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.

pdw wrote 2 days ago:
Compared to Windows SIDs, Linux's 32-bit uid is a
"smallish integer"

vetinari wrote 2 days ago:
And yet in practice the only problem with them is when
mapping Windows SID is needed. Otherwise, they are
fine.

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.

snuxoll wrote 2 days ago:
Yes and no. Bear in mind, a large part of a Windows SID
is a namespace - the actual id within that namespace is
so far without exception under 32-bits. An entire
Active Directory domain (read: single domain, not
forest) is actually limited to 2^30 RID's being issued
- after which no new accounts (including computer
accounts) can be created, period. You can technically
unlock an extra bit and issue 2^31 RID's starting with
WS2012, but compatibility is a potential issue and MS's
documentation says you should only use it while
planning a migration to a new domain (and for good
reason).

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.

raverbashing wrote 3 days ago:
Yes though a lot of this came "long after" the NT kernel (at
least after NT 4.0)

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)

tinus_hn wrote 3 days ago:
This is more like LD_PRELOAD. Iâm not sure this is a
kernel level feature.

pjmlp wrote 3 days ago:
Object based instead of file handles, with capabilities on
everything you can do with them.

Since Vista, official support for a C++ subset.

In kernel IPC, namely LPC, to mimic micro-kernels architectures.

dmitrygr wrote 3 days ago:
Proper support for paged kernel memory? Async-by-default I/O?
Must better power management (compare win vs linux battery life
on same hardware).

cheph wrote 2 days ago:
> Async-by-default I/O?

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.

dmitrygr wrote 2 days ago:
Default in linux is read()/write() and be blocked. Doing
async is a lot more work and until relatively (to NT
timelines) recently quite limited (select).

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.

marcodiego wrote 3 days ago:
Bad power management is really manufacturers fault. See android
phones or chromebooks that can last days without recharging.

pjc50 wrote 3 days ago:
The latter is definitely because the hardware manufacturers QA
with it.

bayindirh wrote 3 days ago:
It's a whole different paradigm and a popular one too. Just being
able to look into it and get inspired is enough to be excited
TBH.

dijit wrote 3 days ago:
IOCP!

URI        [1]: https://en.wikipedia.org/wiki/Input/output_completion_po...

marcodiego wrote 3 days ago:
Almost every time I talked to pseudo nt gurus, IOCP was
mentioned as something nt did and linux don't. Now, io_uring
seems to have finally closed the gap.

muststopmyths wrote 2 days ago:
io_uring is more like RIO, which is better than IOCP if your
packet rates are high.

bitcharmer wrote 3 days ago:
You mean like epoll on Linux?

tobias3 wrote 3 days ago:
No, like io_uring which Linux got in 2019 and still doesn't
cover everything yet (e.g. currently mkdirat() is being
pool, since many e.g. file systems don't implement async IO.

vl wrote 2 days ago:
Annoyingly IOCP didnât cover everything as well - for
example, CreateFile of all things!

>since many e.g. file systems don't implement async IO

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.

vl wrote 2 days ago:
They also have ReFS - new filesystem in NT Server.

tinus_hn wrote 3 days ago:
You can actually for example get drivers for APFS for
Windows from third party vendors.

Sure, and there are third party drivers for ext* and
btrfs and god knows what elseâ¦ but we're talking
about official support here, I think. You can find all
sorts of craziness in out-of-tree patches for the Linux
kernel.

est wrote 3 days ago:
Win2k and WinXP source code are leaked if I am not mistaken

ganafagol wrote 3 days ago:
Release != leak

minxomat wrote 3 days ago:
Even the leaks contain enough of Microsoft's spirit in their

URI          [1]: https://gist.github.com/turbo/75f0905275c29a3049f983cf...

But sadly a lot of interesting fun and research that could be
done with this code won't ever see the light of day because
lawyers are scary.

simonh wrote 3 days ago:
In 2007 I joined a company that sold a derivatives trading platform and
ran VMS on the core component, the order routing engine that dispatched
trading instructions to the respective exchange.

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.

apples_oranges wrote 3 days ago:
TL;DR: Because the / character was used for options. (as opposed to -,
on UNIX)

4cao wrote 3 days ago:
At the time (in MS-DOS 2.0) you could set SWITCHAR=- in CONFIG.SYS to
override this setting. @kiwidrew's post above even has an excerpt
from the source that demonstrates it: [1] So in principle they could
have thought of having something like PATHCHAR=/ as well.

URI    [1]: https://news.ycombinator.com/item?id=26272844

fjfaase wrote 3 days ago:
One reason might be that DOS used the "/" character for options,
whereas in other operating systems the "-" character is used.

laurent123456 wrote 3 days ago:
Not sure if you realise but this is not an "Ask HN" post, it's a link
to an article, which of course mentions the reason:

> They couldn't use the *nix form of path separator of "/", because
the "/" was being used for the switch character.

est wrote 3 days ago:
I never understood why Unix chose "-" for options. It creates
unnecessary confusion. E.g. when deleting a directory called "-rf"

darkwater wrote 3 days ago:
The only solution to that confusion would be not allowing the
options identifying character in file/directory names. Changing the
character would just "change" the confusion.

skissane wrote 3 days ago:
Another viewpoint: the problem is caused by Unix allowing any
character in filenames (other than slash and null). Other platforms
are more restrictive in what characters filenames are allowed to
contain. If you banned the '-' character from starting a filename,
the problem wouldn't happen.

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:

URI      [1]: https://www.austingroupbugs.net/view.php?id=251

kiwidrew wrote 2 days ago:
Agreed!

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. toast0 wrote 2 days ago: > the problem is caused by Unix allowing any character in filenames (other than slash and null). 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. skissane wrote 2 days ago: > 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. shaoonb wrote 3 days ago: A coworker of mine got into trouble when he named a directory ~ and then tried to delete it. bobowzki wrote 3 days ago: I once named a file$HOME and then carelessly tried to delete
it without thinking twice.

st_goliath wrote 3 days ago:
You can make that exact same argument irregardless of what switch
character Unix uses. The real problem is not the switch character
itself, but the approach used by standard Unix tools to "parse
options until parsing fails, then assume it's an argument" which
becomes an amazingly great foot gun if the actual option is
inserted by a shell glob or a shell variable.

eznzt wrote 3 days ago:
For everybody reading, a directory called "-rf" is deleted by
writing "rm -- -rf"; -- indicates the end of all user-provided
options.

duckerude wrote 3 days ago:
If you're working with files, another (perhaps more reliable) way
is rm ./-rf.

kaoD wrote 3 days ago:
There's always going to be ambiguity.

rmdir /f /usr

Is that force-deleting the /usr directory, or the /usr and /f
directories?

est wrote 3 days ago:
I mean on Windows it's

rd /s /q \path\to\something

There's zero ambiguity because both "/" and "\" are special
characters.

hibbelig wrote 2 days ago:
Except that on Windows, you can use "C:/path/to/something"
nearly everywhere where it accepts "C:\path\to\something".

est wrote 2 days ago:
Except C:/ is not a command option, and only Unix people
would write "/"

naewonawonga wrote 2 days ago:
Sounds a bit provincial. That might have been true before
mainstream internet access, but the average user these days
is likely more familiar with unix style paths via URLs than
local filesystem paths.

Also, most non-unix operating systems that don't happen to
be made by Microsoft also use the forward slashes for
paths.

skissane wrote 2 days ago:
> the average user these days is likely more familiar
with unix style paths via URLs than local filesystem
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.)

josefx wrote 3 days ago:
Wouldn't / just cause confusion trying to delete a directory called
/rf ?

est wrote 2 days ago:
There's no directory called /rf so the mistake can do no harm, as
a good design should be.

DHowett wrote 2 days ago:
Your comment is based on the premise that there is, in common
use, a directory called â-rfâ but not one called â/rfâ?
Why would the former be any less likely than the latter?

Felk wrote 3 days ago:
Technically deleting a directory is done with the rmdir command.
But rm with flags is flexible enough that I've seen very few people
use rmdir

Splognosticus wrote 2 days ago:
I use it whenever I expect a directory to be empty and want an
error if for whatever reason it isn't. It's a bit niche, but good

Anarch157a wrote 3 days ago:
rmdir is usefull when you want to remove all empty subdirs,
without touching files or directories with files. Just do 'rmdir
*' and you're done.

account42 wrote 3 days ago:
I like using rmdir even for individual directories that I think
are empty just so that I don't accidentally delete any files
that I did not expect to be there.

peteri wrote 3 days ago:
I have a feeling that the "-" character for an option is a unix
(multics) only thing.

It is also worth looking at [1] where there is some discussion of the
history.

Along with [2] and

URI    [1]: https://retrocomputing.stackexchange.com/questions/4695/slas...
URI    [2]: https://retrocomputing.stackexchange.com/questions/7030/why-...
URI    [3]: https://retrocomputing.stackexchange.com/questions/4686/wher...

vincent-manis wrote 2 days ago:
Multics inherited - as a switch character from the earlier MIT
time-sharing system CTSS.

rnhmjoj wrote 3 days ago:

> (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.

account42 wrote 3 days ago:
Yeah but imagine having to use Shift for every path separator you
type.

hibbelig wrote 2 days ago:
Germans type Shift+7 to get /.

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.

account42 wrote 4 hours 56 min ago:
> Germans type Shift+7 to get /.

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.

TheCycoONE wrote 3 days ago:
Keyboards may have evolved differently to compensate. The
location of non-alphanumeric characters wasn't so consistent
back then.

lifthrasiir wrote 3 days ago:
In addition to its use as a path separator in DOS and Windows, the
backslash character itself is also interesting because it is very
likely a modern invention, with the first attestation in 1940s (!). Its
original use in ASCII (1960s) was for ALGOL operator digraphs \/ and
/\. Its early use as the C escape sequence (1970s, replacing * in
BCPL) suggests that it carried no significant semantics at that time.

jimmaswell wrote 2 days ago:
I feel like some people must have written slashes in whatever
direction long before, but it was never formalized until then.

0x0 wrote 3 days ago:
C also has trigraphs, in case your keyboard does not have a \ you can

URI    [1]: https://en.wikibooks.org/wiki/C_Programming/C_trigraph

Apparently there are several digraphs too. Convinced this was
secretly just designed to make IOCCC contests more interesting.

mycall wrote 2 days ago:
I wonder how many regex security filters would break using ??/ for
escape because very few people know this exists.

IgorPartola wrote 2 days ago:
Mind blown. C is truly a terrifying language and I canât help but
love it for that.

zinekeller wrote 2 days ago:
It was designed in a time where keyboards around the world
(German QWERTZ, Cyrillic JCKUEN/ÐÐ¦Ð£ÐÐÐ) and text encoding
(remember that this is pre-Unicode, so we're dealing with ISO 646
and Eastern Asian character sets) has only the subset of Latin
characters used in the US. Nowadays, it is strongly recommended
to simply use the standard American keyboard in programming

samus wrote 2 days ago:
I still cannot decide whether it's better to comment in English
or in my native language. English works, but it's a weird fit
with words from the application domain. Those, I don't really
want to translate, but I have to keep doing it because there is
so much legacy code with the translations. Sure, I could do a
rampage through the code base and fix everything up (would be
done in an afternoon thanks to IntelliJ), but my team would
almost certainly give me lots of flak for this. At the same
time, it also feels weird to conjugate english words in my
native language.

Taniwha wrote 3 days ago:
While it was included in early character sets it just wasn't used
much - largely because the ubiquitous 029 card punch had no \ key (or
[] ... one had to learn the multipunches)

4cao wrote 3 days ago:
One of the comments on that blog post says the backslash was invented
by Bob Bemer at the time he developed ASCII in the 1960s, also
linking to a page that supports the claim:

URI    [1]: https://web.archive.org/web/20100612011533/http://thocp.net/...

lifthrasiir wrote 3 days ago:
I briefly checked comments and missed that. ;-) I would be more
cautious to say that he invented backslashes, as it's unknown that
he was aware of earlier uses of backslashes. (I've checked both the

4cao wrote 3 days ago:
> I would be more cautious to say that he invented backslashes

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.

1.

URI        [1]: https://en.wikipedia.org/wiki/Backslash#History

DIR <- back to front page
`