6 ms·

"Windows: A 64-bit extension to a 32-bit patch for a 16-bit GUI shell running on top of an 8-bit operating system written for a 4-bit processor by a 2-bit compa

by dreen 13y ago

"Windows: A 64-bit extension to a 32-bit patch for a 16-bit GUI shell running on top of an 8-bit operating system written for a 4-bit processor by a 2-bit company who cannot stand 1 bit of competition."

eru 13y ago
Unfortunately, no longer really true since they switched from the DOS based Windows to the Windows NT branch. (At least I think so.) The snide about competition has also become somewhat hollow. Microsoft would love to go back to the monopoly days of the late nineties. But those days are gone.
- speeder 13y ago
  In fact a merge happened, windows kernel now is mostly NT based but has DOS era artifacts on it.
  - anonymfus 13y ago
    This is how jokes become urban legends.
  - kabdib 13y ago
    When I had access, I decided one afternoon to read the source to the CMD interpreter. It was about as bad as I thought it would be. About an hour into using my Mac Pro's shell, I wanted to weep in relief. Microsoft does not get it. (Or if they do, it gets perverted into something like PowerShell, which I recently wasted a week on).
    - manojlds 13y ago
      What is Mac Pro's shell? You mean your shell on OS X? And what did you find so bad with Powershell?
      - kabdib 13y ago
        The "terminal" on MacOS X. It has: - tabs - cut and paste that actually works - various ways to focus windows - hey, search! ... and a bunch of other stuff. While CMD.EXE has its feet firmly rooted in 1982 or so. Yeah, I know you can buy more whizzy shells. But MS really has no excuse for letting the NT console system rot as much as it has. Given that their programmers use it /all the time/, I find it hard to believe that someone hasn't written something better. (PowerShell overshot the mark, and wound up being unusable).
        yuhong 13y ago
        I think CONHOST/CSRSS is to blame for this not CMD.
        kabdib 13y ago
        As far as I can tell, they're joined at the hip. You /could/ redo one without redoing the other. No problem. But the result would be poor. :-/
        msie 13y ago
        Aside from good cut&paste behaviour, one of the biggest problems with cmd.exe is you cannot resize the window horizontally larger than its set size by dragging on the window side. I do this when I see wrapped text from the output of a command. And if you experience wrapped text in a window smaller than its max size, enlarging the window doesn't reflow the text! Oh I see the same problem happens in Powershell too. :-(
        to3m 13y ago
        Powershell and the command prompt use the same underlying console subsystem, that handles character-mode programs running and displaying their output in a window. It's a core part of Windows, rather than something supplied by each program. The console system doesn't provide a TTY, as in Unix, but instead uses a CGA/MDA text mode metaphor: a matrix of (character,colour) pairs. This leaves no information about the text that's been printed, per se - it's more like the text equivalent of a bitmap. No carriage returns, no tabs, just an arrangement of characters that happened to have been put in the right places. If you widen the screen, there's not much Windows can do except for leave the new area blank, because it has no idea at all which line breaks are significant and which were just wrapped. (And indeed, if you resize the buffer in the console window's properties, this blanking is exactly what it does.) There's sort-of nothing wrong with this system, in that it makes sense for a certain style of text-mode GUI console program, that were at one point exceedingly popular in MS-DOS - but unfortunately, it's not so hot for the TTY style of console program that everybody uses these days :) (Fingers crossed for a much-needed shakeup, but this nonsense has stuck around for so long - I don't think that console properties dialog has changed one pixel since Windows NT 4 - that it's probably a bit late now. Meanwhile, one solution might be to run cmd.exe with a better class of terminal emulator - emacs will do this.)
    - Already__Taken 13y ago
      The Powershell interpreter is made for the Powershell ISE. They just can't touch the CMD interpreter for the same reasons you found, Someone depends on that awful for console apps and god knows what. So all the work went into the ISE instead of fixing CMD. Powershell console and cmd run powershell are just compatibility layers to make it more familiar.
  - nbevans 13y ago
    "Merge" is overstating it. It is a NT kernel with some very small and inconsequential "fixups" done to it to make certain DOS constructs work.
  - asveikau 13y ago
    This is made up. The design of NT was such that you could plug in "subsystems" such as Windows, POSIX, OS/2 etc. The Windows subsystem has had the most development, sure, but there is no "DOS" in the kernel.
- rsynnott 13y ago
  Modern Windows (NT stream) carries a lot of baggage from Win16, however; Win32 wasn't a green-field effort.
yuhong 13y ago
Ah, my favorite problem with Win9x in fact was how Caldera was able to continue to sue MS based on the fact that it was based on DOS. I mentioned it in my blog article on the MS OS/2 2.0 fiasco and it should be obvious why.

by dreen 13y ago

eru 13y ago

Unfortunately, no longer really true since they switched from the DOS based Windows to the Windows NT branch. (At least I think so.) The snide about competition has also become somewhat hollow. Microsoft would love to go back to the monopoly days of the late nineties. But those days are gone.

speeder 13y ago
In fact a merge happened, windows kernel now is mostly NT based but has DOS era artifacts on it.
- anonymfus 13y ago
  This is how jokes become urban legends.
- kabdib 13y ago
  When I had access, I decided one afternoon to read the source to the CMD interpreter. It was about as bad as I thought it would be. About an hour into using my Mac Pro's shell, I wanted to weep in relief. Microsoft does not get it. (Or if they do, it gets perverted into something like PowerShell, which I recently wasted a week on).
  - manojlds 13y ago
    What is Mac Pro's shell? You mean your shell on OS X? And what did you find so bad with Powershell?
    - kabdib 13y ago
      The "terminal" on MacOS X. It has: - tabs - cut and paste that actually works - various ways to focus windows - hey, search! ... and a bunch of other stuff. While CMD.EXE has its feet firmly rooted in 1982 or so. Yeah, I know you can buy more whizzy shells. But MS really has no excuse for letting the NT console system rot as much as it has. Given that their programmers use it /all the time/, I find it hard to believe that someone hasn't written something better. (PowerShell overshot the mark, and wound up being unusable).
      - yuhong 13y ago
        I think CONHOST/CSRSS is to blame for this not CMD.
        kabdib 13y ago
        As far as I can tell, they're joined at the hip. You /could/ redo one without redoing the other. No problem. But the result would be poor. :-/
      - msie 13y ago
        Aside from good cut&paste behaviour, one of the biggest problems with cmd.exe is you cannot resize the window horizontally larger than its set size by dragging on the window side. I do this when I see wrapped text from the output of a command. And if you experience wrapped text in a window smaller than its max size, enlarging the window doesn't reflow the text! Oh I see the same problem happens in Powershell too. :-(
        to3m 13y ago
        Powershell and the command prompt use the same underlying console subsystem, that handles character-mode programs running and displaying their output in a window. It's a core part of Windows, rather than something supplied by each program. The console system doesn't provide a TTY, as in Unix, but instead uses a CGA/MDA text mode metaphor: a matrix of (character,colour) pairs. This leaves no information about the text that's been printed, per se - it's more like the text equivalent of a bitmap. No carriage returns, no tabs, just an arrangement of characters that happened to have been put in the right places. If you widen the screen, there's not much Windows can do except for leave the new area blank, because it has no idea at all which line breaks are significant and which were just wrapped. (And indeed, if you resize the buffer in the console window's properties, this blanking is exactly what it does.) There's sort-of nothing wrong with this system, in that it makes sense for a certain style of text-mode GUI console program, that were at one point exceedingly popular in MS-DOS - but unfortunately, it's not so hot for the TTY style of console program that everybody uses these days :) (Fingers crossed for a much-needed shakeup, but this nonsense has stuck around for so long - I don't think that console properties dialog has changed one pixel since Windows NT 4 - that it's probably a bit late now. Meanwhile, one solution might be to run cmd.exe with a better class of terminal emulator - emacs will do this.)
  - Already__Taken 13y ago
    The Powershell interpreter is made for the Powershell ISE. They just can't touch the CMD interpreter for the same reasons you found, Someone depends on that awful for console apps and god knows what. So all the work went into the ISE instead of fixing CMD. Powershell console and cmd run powershell are just compatibility layers to make it more familiar.
- nbevans 13y ago
  "Merge" is overstating it. It is a NT kernel with some very small and inconsequential "fixups" done to it to make certain DOS constructs work.
- asveikau 13y ago
  This is made up. The design of NT was such that you could plug in "subsystems" such as Windows, POSIX, OS/2 etc. The Windows subsystem has had the most development, sure, but there is no "DOS" in the kernel.
rsynnott 13y ago
Modern Windows (NT stream) carries a lot of baggage from Win16, however; Win32 wasn't a green-field effort.

yuhong 13y ago

Ah, my favorite problem with Win9x in fact was how Caldera was able to continue to sue MS based on the fact that it was based on DOS. I mentioned it in my blog article on the MS OS/2 2.0 fiasco and it should be obvious why.