4 ms·

Freed from such constraints, the Windows console subsystem metaphor is a CGA-style text mode display from the early 1980s. That's the kind of progress you just

by to3m 10y ago

Freed from such constraints, the Windows console subsystem metaphor is a CGA-style text mode display from the early 1980s. That's the kind of progress you just don't ever get with POSIX.

i336_ 10y ago
In 32-bit Windows (which you can still get). The NTVDM was removed from 64-bit Windows, and presumably the graphics hardware emulation was too since it's not used by anything else. On x86_64 cmd.exe is purely a console. [EDIT: I misunderstood; the exact component the parent commentator was referring to was not removed.] I say "presumably" because cmd.exe is a fair bit of a rats' nest due to its organic development over the years. One of its biggest issues is that you must use cmd.exe in order to read/write stdio while a program is running; there's no API to do it any other way. (So you have to open a hidden window then use a bunch of fancy tricks to poll it every so often per second. Yup.) However, this is being tracked and will (at last!) be fixed (apparently soonish): https://github.com/Microsoft/BashOnWindows/issues/111#issuecomment-238068283 https://github.com/Microsoft/BashOnWindows/issues/111#issuec... (that's the relevant comment, the whole thread is interesting - there's actually a carefully-shot photo of the whiteboard all of this is on!)
- to3m 10y ago
  The console window is a grid of (char,attr) - see ReadConsoleOutput/WriteConsoleOutput - i.e., CGA text mode. It's only a metaphor. (As for standard handles, you can redirect them without needing cmd, but there's some fiddly stuff involved. I don't remember the exact details, but it's something like: redirect parent process's handles to appropriate pipes, spawn the child, retract the original redirection, access pipes as appropriate. The API implies that you can just supply the pipes directly, but it doesn't work that way, because Windows is stupid. Which everybody knows. (But what not everybody knows: it's still not as stupid as POSIX.))
  - i336_ 10y ago
    Ah, I see. I finally get it: cmd.exe must be running for the *ConsoleOutput API calls to work. I don't have the specifics for POSIX pipe redirection, but I do know that you use dup2() to redirect everything appropriately. Oh... as for actually launching a terminal, yeah, that's insane. Or rather it has an insane history.
    - to3m 10y ago
      No, the console window is separate from cmd - it's a builtin Windows thing. If your Windows program (that isn't cmd) needs a console, and it doesn't have one, it can call AllocConsole(), and one will be added for it. (A new console window will appear with your program's EXE's path in the title bar.) If your program is tagged as a console program, Windows will usually open a console for it when run - or, at its parent process's discretion, it can be made to use the parent's console. This is how cmd.exe gets a window when you run it from Explorer, and it's how cmd /k runs the new cmd inside the same window when you run it from cmd itself.
    - JdeBP 10y ago
      No. A command interpreter is not a console. * http://jdebp.eu./FGA/a-command-interpreter-is-not-a-console.html http://jdebp.eu./FGA/a-command-interpreter-is-not-a-console....

by to3m 10y ago

Freed from such constraints, the Windows console subsystem metaphor is a CGA-style text mode display from the early 1980s. That's the kind of progress you just don't ever get with POSIX.

i336_ 10y ago

In 32-bit Windows (which you can still get). The NTVDM was removed from 64-bit Windows, and presumably the graphics hardware emulation was too since it's not used by anything else. On x86_64 cmd.exe is purely a console. [EDIT: I misunderstood; the exact component the parent commentator was referring to was not removed.] I say "presumably" because cmd.exe is a fair bit of a rats' nest due to its organic development over the years. One of its biggest issues is that you must use cmd.exe in order to read/write stdio while a program is running; there's no API to do it any other way. (So you have to open a hidden window then use a bunch of fancy tricks to poll it every so often per second. Yup.) However, this is being tracked and will (at last!) be fixed (apparently soonish): https://github.com/Microsoft/BashOnWindows/issues/111#issuecomment-238068283 https://github.com/Microsoft/BashOnWindows/issues/111#issuec... (that's the relevant comment, the whole thread is interesting - there's actually a carefully-shot photo of the whiteboard all of this is on!)

to3m 10y ago
The console window is a grid of (char,attr) - see ReadConsoleOutput/WriteConsoleOutput - i.e., CGA text mode. It's only a metaphor. (As for standard handles, you can redirect them without needing cmd, but there's some fiddly stuff involved. I don't remember the exact details, but it's something like: redirect parent process's handles to appropriate pipes, spawn the child, retract the original redirection, access pipes as appropriate. The API implies that you can just supply the pipes directly, but it doesn't work that way, because Windows is stupid. Which everybody knows. (But what not everybody knows: it's still not as stupid as POSIX.))
- i336_ 10y ago
  Ah, I see. I finally get it: cmd.exe must be running for the *ConsoleOutput API calls to work. I don't have the specifics for POSIX pipe redirection, but I do know that you use dup2() to redirect everything appropriately. Oh... as for actually launching a terminal, yeah, that's insane. Or rather it has an insane history.
  - to3m 10y ago
    No, the console window is separate from cmd - it's a builtin Windows thing. If your Windows program (that isn't cmd) needs a console, and it doesn't have one, it can call AllocConsole(), and one will be added for it. (A new console window will appear with your program's EXE's path in the title bar.) If your program is tagged as a console program, Windows will usually open a console for it when run - or, at its parent process's discretion, it can be made to use the parent's console. This is how cmd.exe gets a window when you run it from Explorer, and it's how cmd /k runs the new cmd inside the same window when you run it from cmd itself.
  - JdeBP 10y ago
    No. A command interpreter is not a console. * http://jdebp.eu./FGA/a-command-interpreter-is-not-a-console.html http://jdebp.eu./FGA/a-command-interpreter-is-not-a-console....