Hacker News Reader

Comment by Alupis | Hacker News Reader

I find these sort of articles so very tiring...

I realize this is from the OS/2 Museum and not Microsoft - but the result is the same:

Article written about a poor engineering decision made decades ago, which for reasons that perplex everyone still live-on today. Then the Microsoft apologists come out of the woodwork to explain how easy it is to live with these poor engineering decisions and how smart Microsoft Engineers are, and how it's literally all other operating systems that somehow are lacking, blah blah blah.

Backwards compatibility is usually the smoke screen apologists deploy during these discussions. As-if in the past few decades Microsoft couldn't have written a simple '\' -> '/' converter... Hell, if you look in the Explorer address bar, Microsoft even hides the path separator - opting to replace it with arrows instead.

Let's not even start on the CRLF thing...

Yes, Windows owes it's origin to OS/2, and OS/2 used '\' instead of '/' - so we should never correct a decision inherited from an OS that died 22 years ago...

View on HN

As a long time *nix user who briefly worked at Microsoft (and therefore on Windows), I was very happy to learn that Powershell is perfectly happy with forward slashes in paths. If you tab-complete it switches them to backslashes (which is "fine"), but you can type commands using forward slashes without issue. Also common linux commands (ls, cd, mv, cp) all work in Powershell. It really makes the transition painless.

I personally have found PowerShell to be obnoxious. It doesn't seem to know what it's supposed to be and tries to be everything all at once. The syntax for commands is super "Microsofty" if you know what I mean.

I get around by using Git Bash (which is actually quite good for being a bundled afterthought), cygwin, or lately even WSL containers.

Git Bash, cygwin, WSL containers are all completely different things. PowerShell is a shell like bash, just with a different syntax.

What different things do you think it is trying to be?

I have nothing against PowerShell. I've used it for avoiding detection etc. in the past. Fun tool that surprises and delights in unexpected ways.

It is pretty powerful/insane that stuff like this is a part of PowerShell and that's probably what the GP is talking about:

    Add-Type -TypeDefinition @"
    using System;
    namespace DemoCode
    {
        public class DemoClass
        {
            public static void WriteHello()
            {
                Console.WriteLine("Hello");
            }
        }
    }
    "@
    [DemoCode.DemoClass]::WriteHello()

Or LoadLibrary call and invocation from PowerShell. [0] [1]

It blurs the lines as to what it is no matter how you look at it.

In contrast, try doing that in cmd.exe or invoking a function from a shared object after getting a pointer to it using dlopen through a POSIX shell.

[0] - https://www.powershellgallery.com/packages/PSReflect-Functio...

[1] - https://fuzzysecurity.com/tutorials/24.html

Windows itself is fine with forward slashes as a path separator, as well, though LOTS of userland Windows applications weren’t aware of this and enforced backslashes themselves.

Command lines, graphical shells, OS save and open file dialogs do not care if you use slash or backslash, and the Win32 API has never enforced backslashes as a path separator.

You'll be surprised what the Win32 API will accept as a path. You can run 'type \\?\GLOBALROOT\Device\OSDataDevice\Windows\win.ini' at a command prompt, and it will succeed. You can even provide a path like that to MS Paint on the command line, and it will happily open the file. But Shell32 (Windows Explorer and File Load/Save dialogs) won't accept that kind of path.

This is also true if you e.g. write a C program to create a file whose pathname contains a slash. This is deep within the OS, likely due to posix compatibility

I work a lot in powershell, and I want to like it. It is built around good ideas.. but oof, every time I have to special case on a return value being either a list or a single item depending on the result-len==1 or not, I die a little inside.

$alwaysList = @( Get-Something )

I think there are some tricks to ensure a list in pwsh for these sort of operations. I vaguely recall ending variable assignments with a comma to avoid this.

Windows used many of the MSDOS services, like file system access. Windows was built on top of MSDOS in the beginning.

Windows predates OS/2 (OS/2 development started in 1985 according to Wikipedia)

How is it a poor engineering decision?

What about the original Mac OS using colon as a path separator? Or Lisa OS using the hyphen as a path separator?

see https://retrocomputing.stackexchange.com/questions/17069/why...

Japanese DOS had ¥ as the path separator or more specific at 0x5C. It still causes headache with the MS Mincho font. Japanese users are used to seeing ¥ at the DOS prompt so some Windows Console fonts just replace the backslash.

Since you never know if it's a backslash or an actual Yen sign. Total fun.

MS Mincho and MS Gothic (and many others including Meiryo) both use the Yen Sign (unicode 0xA5) character graphic for the Backslash character. There are also a few Japanese fonts (such as Sazanami Gothic) that don't do this.

The separate halfwidth yen sign does not exist in Shift-JIS at all. So any time a non-unicode Japanese Win32 application needs to draw a halfwidth yen sign, it must draw a backslash. And you can't make the official character mapping convert Backslash 0x5C into Yen sign 0xA5, otherwise all file paths would break.

Yeah I think it's far more interesting to view this as a series of people making probably the best possible decision at the time, and winding up in a slightly unfortunate, suboptimal place.

That's hardly uncommon! Examine the history of basically anything.

> Microsoft reportedly wanted to use the forward slash as path separator, but IBM nixed the idea because it would have created an incompatibility with DOS 1.x, which already used the forward slash as a switch character, separating command options.

It isn’t a poor engineering decision, that guy just didn’t read the decision criteria.

Also, according to spec, CRLF is the proper sequence for a newline, and both Unix and MacOS chose incorrectly.

Which spec would that be? It's not the ISO spec, nor POSIX.

CRLF existed originally because of mechanical typerwriters required two separate actions - Carriage Return (move the carriage back to the start of the line), Line Feed (advance the page to the next line).

CR is a waste for computing... it literally does nothing beneficial.

Someone should figure out the climate impact of decades of wasted processing of CR characters... that might motivate people to fix this as well.

> Someone should figure out the climate impact of decades of wasted processing of CR characters... that might motivate people to fix this as well.

LF vs CRLF is a single molecule of water compared to the seven seas of waste created by Electron apps or even just JavaScript itself. Todays developers are lazy as FUCK and there is no pressure for them to stop being lazy.

See: https://tonsky.me/blog/js-bloat/

> CR is a waste for computing... it literally does nothing beneficial.

When “LF” means “line feed and carriage return” both, as it does thanks to UNIX, yes. On teletype machines “line feed” meant “line feed” and “carriage return” meant “carriage return”. You need both.

Today we use an LF which means both “CR” and “LF” and we act like CR is the problem, when it was us choosing a single byte to mean two separate things joined together.

Even as a kid in school in typing class, I used a typewriter with a parallel port (probably serial, really, because you could use the keyboard without putting text on paper), and it could be used to print text sent to it. CR and LF had very different meanings on that typewriter. I wish I remembered what make and model it was…

> Which spec would that be? It's not the ISO spec, nor POSIX.

RFC3676, RFC2045, among others. CRLF is the Internet standard newline

Which explains it's use in operating systems how exactly?

How did it become the Internet standard? Because at the time it was adopted as the Internet standard the majority of operating systems used it. Probably the biggest influence on both the Internet standard and Microsoft was DEC. And actually, it is used by Unix too, in the TTY layer: Unix by default translates LF to CRLF on output - and that translation is in the POSIX standard. So the claim that CRLF isn’t in POSIX is false

thank you. I was about to look, but saw this.

> CR is a waste for computing... it literally does nothing beneficial

CR enables to update a line of text. Print some text without newline at the end, print CR, print another line, and the old text will be overwritten with the new one.

Some command-line apps are using the trick to print progress bars, progress percentage, or similar. This is very beneficial.

This is almost always implemented using direct placement of the cursor, not via a literal CR char/command. CR is literally useless, except for being artificially required in some windows text editors.

Cursor placement is hard to do portably because every OS has incompatible ways for that. You gonna need SetConsoleCursorPosition on Windows, and multiple versions of these terminal escape codes on Linux.

printf( "\rsomething " ) is much easier.

It's not the same in many terminals... I also think lack of Vertical tabs on keyboards is sometimes a shortcoming.

> Let's not even start on the CRLF thing...

CRLF is actually the Internet standard. It wasn't something Microsoft came up with, it was something they inherited from DEC

> Yes, Windows owes it's origin to OS/2, and OS/2 used '\' instead of '/' - so we should never correct a decision inherited from an OS that died 22 years ago...

That's not what the article actually says though. DOS 2.0 decided on '\' instead of '/', and both OS/2 and Windows inherited that decision from DOS.

Why is / better than \ ?

For starters, `\` is used for escape sequences for just about everything... meaning you now have to do the `\\` dance everywhere you need to write this path separator.

Yes, it's true modern languages have things like `Path.separator` and stuff to abstract this away, but you cannot always use them in all contexts.

It's small friction that adds up to a sore bum after a while...

FWIW, I have never wanted to put a \ in a filename, but I have often wanted to put a / in a (pretty) filename, as / is used in standard English all the time; I then find myself using "-" instead and that makes me unhappy. I'd much rather have seen ^ as the escape character and \ as the path separator.

You can put slashes in filenames in MacOS's Finder app. If you use ls to view the filename, you'll see colons where Finder shows slashes.

Want to really mess with someone, do that on a mac file share on a windows server... You won't be able to do anything to that file or directory from Windows. Not sure if it's still an issue, but definitely was in the NT4/Win2k days.

Yeah, because Mac used to : as the separator... but, : is also an extremely commonly-used character that I have off wanted to put in a filename.

The real fun starts with UNC paths. Is it `\\\\server\\share\ with\ space` or `//server/share\ with\ space` or any combination of those, preferably with quotes.

Could be worse of course: Multics (the first system with hierarchical names) used greater-than (>) as separator. Unix/DOS use of slashes gives us the sane pipeline/redirection syntax we all love (see [1] for the Multics redirection syntax).

[1] https://retrocomputing.stackexchange.com/questions/7030/why-...

Apart from the fact \ is used as an escape sequence?

If you're using anything resembling modern Windows, you can use forward slashes for path separators and it works fine pretty much everywhere.

I use forward and backward slash on Windows all the time. I think it's less of a problem of spaces in filenames, which makes a lot of pipe-related stuff harder to do (see find -print0 and xargs -0).

Spaces in filenames in the command line on Windows is a horror in part because there is no kernel level equivalent of argv. In the eyes of the Windows kernel, the command line is an unparsed utf-16 string, and it's up to the application or C library to tokenize it. This means there is no standard way to tokenize it. Ultimately, this means there is no standard way to escape a shell command's arguments, as you would need to do for spaces. Most people just put it in double quotes but this is pretty much the honor system.

I'm not entirely sure what you're saying is different here.

I picked the first MSFT page on argv, https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-c... and compiled and ran that program with various command lines, and it does exactly what I expected (argv array members are tokenized according to my quoting).

Could you be clearer, perhaps by posting a simple C example and a few command lines demonstrating what you mean?

Here's an example of someone citing a disagreement between CRT and shell32:

https://github.com/rust-lang/rust/issues/44650

This in addition to the Rust CVE mentioned elsewhere in the thread which was rooted in this issue:

https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html

Here are some quick programs to test contrasting approaches. I don't have examples of inputs where they parse differently on hand right now, but I know they exist. This was also a problem that was frequently discussed internally when I worked at MSFT.

    #include <stdio.h>
    int main(int argc, char **argv)
    {
       for (int i=0; i<argc; ++i)
          puts(argv[i]);
       return 0;
    }

    #pragma comment(lib, "shell32.lib")
    #include <windows.h>
    #include <stdio.h>
    int main()
    {
       PCWSTR cmdLine = GetCommandLineW();
       if (cmdLine)
       {
          int argc = 0;
          PWSTR *argv = CommandLineToArgvW(cmdLine, &argc);
          if (argv)
          {
             for (int i=0; i<argc; ++i)
                printf("%ls\n", argv[i]);
             LocalFree(argv);
             return 0;
          } 
       }
       return 1;
    }

> it's up to the application or C library to tokenize it

Technically yes, but practically the only correct way to tokenize these command line strings is CommandLineToArgvW WinAPI implemented by Shell32.dll.

This is fine for parsing command line arguments in your own programs, but unhelpful when attempting to provide a mechanism to reliably pass a user-supplied argument list to an arbitrary external program that is free to interpret the string returned by GetCommandLine arbitrarily (so the notion of "passing a list of arguments" isn't even generally applicable).

cmd.exe is an important and terrible example:

https://learn.microsoft.com/en-us/windows-server/administrat...

Within Microsoft when I was there, it was considered taboo to introduce a dependency to shell32 where it did not already exist. I tried to add a call to CommandLineToArgvW once and it got flagged.

From the part of Microsoft that was focused on cleaning up the windows code base in that era, the shell was not considered a core component. All of the utility functions that it provides like this were considered baggage, improper layering, poor design.

Just use PowerShell. It has no issues with spaces anywhere, and uses explicit quoting rules similar to C# and other “proper” languages.

If powershell is dispatching to other cmdlets then fine. If it needs to call CreateProcess on a win32 program then the issue I'm talking about definitely exists.

(I don't personally like powershell but I don't think my gripes with it are really relevant to this thread.)

I don't think anybody else here is talking about CreateProcess. We're talking about the shell.

This is how a shell works. It works by creating processes.

On Unix, you create a process with fork() and execve(). Execve takes a list of arguments, already parsed and tokenized. A shell is free to interpret the command line however it likes to build this, but at the syscall level it is completely unambiguous what the parsed array looks like.

On Windows, you call CreateProcess. This takes the command line as an unparsed string. It is the child process's responsibility to chop it up into argv. This is the source of ambiguity that I'm talking about.

The comment I wrote starting this thread wasn't about command line parsing, it was about pipes, and the need to use a non-space delimiter NULL to pass lists of files that contain spaces.

What you're talking about is related, but different. You're saying that Windows forces an unnecessary join and split (with all the complex rules required to properly parse a quoted string) when using the Windows equivalent of exec(). which is inelegant, but unrelated to what I'm describing above (what I describe above differs because of how newlines and spaces are treated as delimiters (IFS)).

Further, from the testing I did, there is no noticeable impact on my C application which reads from argv- the C runtime seems to handle this transparently.

> Further, from the testing I did, there is no noticeable impact on my C application which reads from argv- the C runtime seems to handle this transparently.

I disagree with your assessment here.

First, the C runtime doesn't have the "part of the system" feel that it does in the Unix world. There is a CRT in the OS, but most programs link to the CRT that ships with visual studio, so it could theoretically change version to version, compiler to compiler.

Apart from that a Win32 application could choose to bypass the CRT's entry point and use WinMain(). Many do. Even if it does use CRT main there is GetCommandLine() to reach the raw command line underneath. Shell32 even has a function CommandLineToArgvW which behaves differently from CRT. Those two are different from parsing done by cmd.exe. There is a lot of ambiguity is my point.

Relevant: https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html

With respect, what the hell are you talking about?

Win32 file APIs can actually use either '/' or '\\' as a path separator. The stuff this is talking about is mostly around DOS command line tools and the successor, cmd.exe, which yes is mostly meant to run scripts written for DOS.

'\\' was selected by DOS, specifically DOS 2.0 per TFA, several years before OS/2 existed.

When you open Explorer and click in the address bar - what path separator is displayed? How about when you install software - what path separator does it show?

> Win32 file APIs can actually use either '/' or '\\' as a path separator.

Fantastic - so why are we still entertaining this idiotic file separator everywhere within the OS itself?

> '\\' was selected by DOS, specifically DOS 2.0 per TFA, before OS/2 existed

Fine - so why the hell are we still doing things like a dead, defunct OS did and literally nobody else did because, you know, it was unintelligent?

> Fantastic - so why are we still entertaining this idiotic file separator everywhere within the OS itself?

Dude, why are you so angry about what direction a slash goes?

Once they introduced the ability to use either one, they still had a lot of software that hardcoded '\\', including lots of their own. Again, they support either one in most places. The backslash is considered more canonical because it came first.

Going back to DOS for a second, TFA even says Microsoft wanted to use '/' in DOS 2.0 when they introduced directories (1983), but IBM objected.

IBM objected in 1983 - yet that decision lives on today? It's what Windows displays to users, even if you can actually type in / and things still work.

When Microsoft wrote IIS and other web technologies the internal friction of path separators must have been fun to experience. "Why are we still using \ again, Jim? Oh, that's right, we chose poorly a decade ago and for some reason can't be bothered to fix it!"

> Dude, why are you so angry about what direction a slash goes?

Because it's rubbed my bum raw over the years and I've finally had enough! I mostly jest... but seriously, it's super annoying to deal with and a constant reminder of the poor decision making Microsoft products often encompass.

You know what happens when you write a \ --> / converter? You get the python2 to python3 migration mess. Except with Windows it would have been millions of mom and pop shops left out in the lurch.

No it wouldn't - because Microsoft did write a \ -> / converter and none of this bad stuff happened.

Microsoft just chooses to still display \ to you in the UI... which is ridiculous and perpetuates \ living on in all user-facing places.

Are we arguing different things? I.e. removing support for \ altogether from anywhere in the OS vs. not showing it in UIs?

I personally like the latter but it's a matter of taste I guess :-). It gives me warm and fuzzies to see C:\ D:\ etc. live on.

Parsing a URI should not be a straight pass to open(2) [or CreateFile in Windows parlance] to get to the filesystem directly anyway ... Think of the security problems with that, or URIs where they don't actually correspond to filesystem objects. So, IIS already needs to parse the path distinctly. I'm going to say it didn't cause them a lot of trouble.

Note also that Windows tends to use 16 bit Unicode everywhere, that's probably a bigger thing for IIS than the path separator.

Microsoft was very smart to use the backslash. It lead to unrivaled backwards compatibility.

Saying it was the wrong choice is simply revisionist history.

So, we would lose all backwards compatibility by writing a \ -> / converter? I don't buy this logic at all - in fact, as others have pointed out, Windows will accept both separators these days.

You are, unintentionally, being the very sort of apologist my post above complained about.

I think you just need to get over whatever is making you angry. Non-POSIX systems exist, dude. It’s ok for things to exist…

Tempted to bring in the fact that classic Mac used colons as a path separator.

As TFA says it wasn't clear yet that unix would be so dominant. Also, a lot of these systems were introducing the concept of directories for the first time in their history. That's how old we're talking. That directories are novel to some people at that point.

Personal attacks are not welcome on HN.

Microsoft wrote a 'converter'. Terminal, Explorer, and other applications recognize "/" and convert it to "\". If it takes both, it doesn't matter which one is "real".

> You are, unintentionally, being the very sort of apologist my post above complained about.

Hint: the post you are replying to is humorous and the tone should be read as sarcastic.

No, it wasn't and no, it shouldn't be read as sarcastic. Microsoft should be praised for the backwards compatibility they enabled. That is a feat rare in operating systems today.

All right, but in that case, I must ask you to explain the comment, because it make no sense to me at all.

Firstly, the choice of backslash in DOS 2 didn't enable backwards compatibility with anything because nothing prior to DOS 2 used the backslash character for this.

Secondly, I do not see any basis to say that somehow MS looked forward in time, at the future, and chose a character unused by any other OS.

As early-1980s MS did not have a time machine and thus was not looking forwards, then how did that choice help future compatibility? How was the use of backslash better for Windows for Workgroups 3.11 (because that was the first one with its own VFAT filesystem that didn't just call DOS) and subsequent releases? How was a backslash preferable to anything else?

How would using any other character be worse?

Would choosing a character used by other OSes not have been _better_ for long term compatibility, aiding source code conversion and porting?

I really do not see what you are trying to get at.

Incidentally, I entirely agree that its compatibility record is astonishingly good, but I can't see any link from that to the choice of directory delimiter.

When one speaks of Microsoft's backwards compatibility, they are referring to within the Microsoft domain of operating systems and APIs. If I can run an application from 1985 on modern day Windows, that is what backwards compat refers to and is quite unrivaled -- remember, the most stable ABI on Linux is Win32.

> How was a backslash preferable to anything else?

Because it existed prior to Windows 1.0 and beyond application compatibility, you also had to work with user familiarity. Heck, it is annoying enough to swap between macOS and Windows for Ctrl/Cmd-C and Ctrl/Cmd-V, or even within macOS between Mac applications and the Terminal. Or my worst personal enemy, Ctrl-H/Cmd-H (browser History vs. hide window) in a browser. Arg!

> Would choosing a character used by other OSes not have been _better_ for long term compatibility, aiding source code conversion and porting?

Which OS should they have chosen from? [0] Apple SOS [and all future versions of macOS]? VMS/OpenVMS? RiscOS? Domain/OS? TOPS/20? Stratus VOS? What made SysV or BSD special or 'a clear choice' in path separators in the '80s?

> How would using any other character be worse?

I don't believe any other character would be better or worse at the time backwards compatibility was ruled supreme at Microsoft. Since their operating systems already used the backslash character, and the preceding mention of user familiarity, and of course the code base is DOS which they probably didn't want to re-write due to effort and cost, they stuck with it.

I certainly see a point in changing the path separator if you pulled a Mac OS Classic to Mac OS X style switch, but Microsoft never really did that. Yes, they had NT, but that needed to have compatibility with it's DOS-based sibling as it could also run DOS applications.

Oh imagine the threads if they did switch to the forwardslash in Windows... "What else from Linux will Microsoft copy?!" "Did Microsoft switch to the Linux kernel?!". It would make for an exciting day in tech!

I'm certainly not against Microsoft changing the path separator to the forwardslash.

[0] https://en.wikipedia.org/wiki/Path_(computing)

> Fine - so why the hell are we still doing things like a dead, defunct OS did and literally nobody else did because, you know, it was unintelligent?

Nobody is doing it except the people using cmd.exe over Windows Terminal or Powershell. If you're using a DOS terminal you're gonna get DOS results.

Windows existed before OS/2, though, and MS-DOS (where Windows’ path separator comes from) is of course even older.

It’s ok to hate Microsoft, but hate them based on facts, and not whatever nonsense you have in mind.

Reply on news.ycombinator.com