3 ms·

The classic Windows shell has many flaws in its design, appears to have come from OS/2, and it's amazing that it works at all for how it has been used: https:/

by chasil 4y ago

The classic Windows shell has many flaws in its design, appears to have come from OS/2, and it's amazing that it works at all for how it has been used: https://blog.nullspace.io/batch.html https://blog.nullspace.io/batch.html Powershell is a new arrival, limited outside of Windows. I admit that I don't know it. The POSIX shell also has severe problems with ambiguity, and it is not an LR-parsed language: https://archive.fosdem.org/2018/schedule/event/code_parsing_posix_s_hell/ https://archive.fosdem.org/2018/schedule/event/code_parsing_... Use the right tool for the job, imperfect as they may be. It is unfortunate that awk didn't grow and supplant the shell, as for many years the BWK "One True Awk" did use straightforward lex and yacc grammars.

layer8 4y ago
> The classic Windows shell […] appears to have come from OS/2 It’s actually based on the DOS command shell [1], which in turn was modeled after CP/M [2]. [1] https://en.m.wikipedia.org/wiki/COMMAND.COM https://en.m.wikipedia.org/wiki/COMMAND.COM [2] https://en.m.wikipedia.org/wiki/CP/M https://en.m.wikipedia.org/wiki/CP/M
- chasil 4y ago
  Alas, incorrect. Notice the "Comparison with COMMAND.COM" section. https://en.wikipedia.org/wiki/Cmd.exe https://en.wikipedia.org/wiki/Cmd.exe
  - layer8 4y ago
    Could you elaborate on what exactly you think is incorrect?
    - chasil 4y ago
      From the wiki, command.com did not run pipelines in parallel, and in consequence could not redirect standard error: "For example, on OS/2 and Windows, it can use real pipes in command pipelines, allowing both sides of the pipeline to run concurrently. As a result, it is possible to redirect the standard error stream. (COMMAND.COM uses temporary files, and runs the two sides serially, one after the other.)" Obviously, this process and I/O management would require a massive rewrite, sufficient to make cmd.exe a new (but somewhat compatible) implementation. This was not possible in DOS or CP/M. Delayed variable expansion, pushd/popd, file name completion, expression evaluation and improved control structures are all fundamental changes that are strongly influenced by the Berkeley C Shell written by Bill Joy. The wiki specifically mentions the C Shell. The 8086(/8) binary for command.com is not found in modern windows (I think the "wow16" layer was removed from 64-bit windows); cmd.exe is a 32-bit binary running under wow32, which it must be to invoke these new features in system calls that could not exist in DOS. The wiki says this about the relation between command.com and cmd.exe: "cmd.exe is the counterpart of COMMAND.COM in DOS and Windows 9x systems, and analogous to the Unix shells used on Unix-like systems." I think that very little source code from command.com ended up in cmd.exe.
      - layer8 4y ago
        Yeah, I didn’t mean it in terms of of source code and implementation, and certainly a lot of features were added since DOS, but since both OS/2 and Windows (NT) were intended to be successors of DOS, their shell took over the syntax and conventions of the DOS shell.
        chasil 4y ago
        ...but also some of Bill Joy's influence as well. It is compatible with, but distinct from what preceded it.

by chasil 4y ago

layer8 4y ago

> The classic Windows shell […] appears to have come from OS/2 It’s actually based on the DOS command shell [1], which in turn was modeled after CP/M [2]. [1] https://en.m.wikipedia.org/wiki/COMMAND.COM https://en.m.wikipedia.org/wiki/COMMAND.COM [2] https://en.m.wikipedia.org/wiki/CP/M https://en.m.wikipedia.org/wiki/CP/M

chasil 4y ago
Alas, incorrect. Notice the "Comparison with COMMAND.COM" section. https://en.wikipedia.org/wiki/Cmd.exe https://en.wikipedia.org/wiki/Cmd.exe
- layer8 4y ago
  Could you elaborate on what exactly you think is incorrect?
  - chasil 4y ago
    From the wiki, command.com did not run pipelines in parallel, and in consequence could not redirect standard error: "For example, on OS/2 and Windows, it can use real pipes in command pipelines, allowing both sides of the pipeline to run concurrently. As a result, it is possible to redirect the standard error stream. (COMMAND.COM uses temporary files, and runs the two sides serially, one after the other.)" Obviously, this process and I/O management would require a massive rewrite, sufficient to make cmd.exe a new (but somewhat compatible) implementation. This was not possible in DOS or CP/M. Delayed variable expansion, pushd/popd, file name completion, expression evaluation and improved control structures are all fundamental changes that are strongly influenced by the Berkeley C Shell written by Bill Joy. The wiki specifically mentions the C Shell. The 8086(/8) binary for command.com is not found in modern windows (I think the "wow16" layer was removed from 64-bit windows); cmd.exe is a 32-bit binary running under wow32, which it must be to invoke these new features in system calls that could not exist in DOS. The wiki says this about the relation between command.com and cmd.exe: "cmd.exe is the counterpart of COMMAND.COM in DOS and Windows 9x systems, and analogous to the Unix shells used on Unix-like systems." I think that very little source code from command.com ended up in cmd.exe.
    - layer8 4y ago
      Yeah, I didn’t mean it in terms of of source code and implementation, and certainly a lot of features were added since DOS, but since both OS/2 and Windows (NT) were intended to be successors of DOS, their shell took over the syntax and conventions of the DOS shell.
      - chasil 4y ago
        ...but also some of Bill Joy's influence as well. It is compatible with, but distinct from what preceded it.