4 ms·

Ill take a stab at that. command.com scripts were very similar to cmd.exe scripts. That was important to get people to actually use the thing. You can see th

Ill take a stab at that. command.com scripts were very similar to cmd.exe scripts. That was important to get people to actually use the thing. You can see the same thing today with powershell. PS is in many ways better. Except it does not run the old scripts very well. Even something simple like 'dir /s' does not work in powershell you have to do it the powershell way. If they had moved to sh style command eventually they would have been fine. But... their existing base would have been very unhappy with the results in the short term.

chasil 3y ago
At the same time, Xenix had a huge influence on Microsoft. I can't believe that anyone with taste would want CMD.EXE, and the criticism is deep. https://blog.nullspace.io/batch.html https://blog.nullspace.io/batch.html
- sumtechguy 3y ago
  Oh no doubt it is a rubish language to program in. The thing is their existing base had a set of scripts that already worked. These are not 5 line scripts either. One place I worked at the thing was probably 20k lines of batch script. To hand them a new shell is akin to saying 'throw everything you did out and redo it'. Those scripts were probably home grown by people who had other things to do (you work with what you have). Or by expensive consultants. They 'must work' or 'why am I upgrading to this?' It is not necessarily hard to do. It just an extra expense most businesses are going to skip if they can.
- skissane 3y ago
  Some reasons why CMD.EXE is so bad: (1) COMMAND.COM cut a lot of corners, in significant part due to being written in assembly and designed to run on machines with very low memory (DOS 1.0 would run on machines with only 32KB of RAM) (2) Backward compatibility meant a lot of the questionable decisions in (1) had to be maintained (3) At some point Microsoft stopped investing in it, and didn't do anything further to add new features or file off more rough edges I think (1) and (2) were kind of inevitable, but (3) is a decision Microsoft has made much more recently I wish they'd open-source CMD.EXE and start accepting PRs for it – I think some of the worst things about it (e.g. the "Terminate batch job (Y/N)?" prompt which is impossible to turn off without patching the executable) would get fixed. But I doubt they'll do that because they just want people to focus on PowerShell instead–and before PowerShell, it was the same thing for VBScript
  - WorldMaker 3y ago
    At this point ConHost.exe is open source [0] so it is maybe not a stretch to expect Microsoft to open source CMD.EXE at some point. Though with PowerShell being cross-platform and already open source, I personally don't think there's enough to gain in some sort of better open source CMD.EXE fork. I'd be interested in being proved wrong on that, but I'm also happy enough with PowerShell these days I'm not in a hurry to return to CMD.EXE. [0] https://github.com/microsoft/terminal/tree/main/src/host https://github.com/microsoft/terminal/tree/main/src/host
    - skissane 3y ago
      PowerShell is rather heavy and takes a lot longer to start than CMD.EXE does I think there are plenty of little annoyances in CMD.EXE which could be fixed. That prompt I mentioned is the most obvious one, but I'm sure there are more.
  - chasil 3y ago
    Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc. Neither Korn/pdksh nor CMD.EXE can meet such a requirement. DOS batch compatibility could easily be met with a secondary command shell. NT's primary command shell could have reworked AWK's grammar into an interactive shell. It's a shame that the NT command shell did not recieve the attention that it deserved. DCL would have been preferable (if you like FORTRAN).
    - skissane 3y ago
      > Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc There are plenty of parser generators other than yacc, many of which accept different types of grammars from LR (e.g. LL parsers, PEG parsers). I'm not sure why it should matter whether a command processor's grammar is LR or LL or whatever.
      - chasil 3y ago

chasil 3y ago

At the same time, Xenix had a huge influence on Microsoft. I can't believe that anyone with taste would want CMD.EXE, and the criticism is deep. https://blog.nullspace.io/batch.html https://blog.nullspace.io/batch.html

sumtechguy 3y ago
Oh no doubt it is a rubish language to program in. The thing is their existing base had a set of scripts that already worked. These are not 5 line scripts either. One place I worked at the thing was probably 20k lines of batch script. To hand them a new shell is akin to saying 'throw everything you did out and redo it'. Those scripts were probably home grown by people who had other things to do (you work with what you have). Or by expensive consultants. They 'must work' or 'why am I upgrading to this?' It is not necessarily hard to do. It just an extra expense most businesses are going to skip if they can.
skissane 3y ago
Some reasons why CMD.EXE is so bad: (1) COMMAND.COM cut a lot of corners, in significant part due to being written in assembly and designed to run on machines with very low memory (DOS 1.0 would run on machines with only 32KB of RAM) (2) Backward compatibility meant a lot of the questionable decisions in (1) had to be maintained (3) At some point Microsoft stopped investing in it, and didn't do anything further to add new features or file off more rough edges I think (1) and (2) were kind of inevitable, but (3) is a decision Microsoft has made much more recently I wish they'd open-source CMD.EXE and start accepting PRs for it – I think some of the worst things about it (e.g. the "Terminate batch job (Y/N)?" prompt which is impossible to turn off without patching the executable) would get fixed. But I doubt they'll do that because they just want people to focus on PowerShell instead–and before PowerShell, it was the same thing for VBScript
- WorldMaker 3y ago
  At this point ConHost.exe is open source [0] so it is maybe not a stretch to expect Microsoft to open source CMD.EXE at some point. Though with PowerShell being cross-platform and already open source, I personally don't think there's enough to gain in some sort of better open source CMD.EXE fork. I'd be interested in being proved wrong on that, but I'm also happy enough with PowerShell these days I'm not in a hurry to return to CMD.EXE. [0] https://github.com/microsoft/terminal/tree/main/src/host https://github.com/microsoft/terminal/tree/main/src/host
  - skissane 3y ago
    PowerShell is rather heavy and takes a lot longer to start than CMD.EXE does I think there are plenty of little annoyances in CMD.EXE which could be fixed. That prompt I mentioned is the most obvious one, but I'm sure there are more.
- chasil 3y ago
  Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc. Neither Korn/pdksh nor CMD.EXE can meet such a requirement. DOS batch compatibility could easily be met with a secondary command shell. NT's primary command shell could have reworked AWK's grammar into an interactive shell. It's a shame that the NT command shell did not recieve the attention that it deserved. DCL would have been preferable (if you like FORTRAN).
  - skissane 3y ago
    > Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc There are plenty of parser generators other than yacc, many of which accept different types of grammars from LR (e.g. LL parsers, PEG parsers). I'm not sure why it should matter whether a command processor's grammar is LR or LL or whatever.
    - chasil 3y ago