5 ms·

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 s

by canucker2016 3y ago

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-did-macos-classic-choose-the-colon-as-a-path-separator https://retrocomputing.stackexchange.com/questions/17069/why...

TillE 3y ago
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.
naikrovek 3y ago
> 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.
- Alupis 3y ago
  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.
  - naikrovek 3y ago
    > 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/ 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…
  - deleted 3y ago
    [deleted]
  - tracker1 3y ago
    It's not the same in many terminals... I also think lack of Vertical tabs on keyboards is sometimes a shortcoming.
  - Const-me 3y ago
    > 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.
    - Alupis 3y ago
      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.
Joe_Cool 3y ago
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.
- Dwedit 3y ago
  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.

TillE 3y ago

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.

naikrovek 3y ago

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

Alupis 3y ago
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.
- naikrovek 3y ago
  > 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/ 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…
- deleted 3y ago
  [deleted]
- tracker1 3y ago
  It's not the same in many terminals... I also think lack of Vertical tabs on keyboards is sometimes a shortcoming.
- Const-me 3y ago
  > 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.
  - Alupis 3y ago
    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.

Joe_Cool 3y ago

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.

Dwedit 3y ago
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.