What you say is correct, but in a way that is disconnected from the user's POV.

Consider: the command line is a major drawback of Windows, and that's the most obvious manifestation of the Windows/DOS heritage. In addition to its lack of power, the Window doesn't even resize properly.

Plenty of tools that port easily to OSX or Haiku are difficult to port to Windows. Look at the situation with git.

The situation is poor. Technically, NT (and NTFS, etc) might be great, but aspects of the user experience is awful.

The command line for Windows is now Powershell, which I find superior to Bash in many ways (although I appreciate Bash's relative simplicity, and I am still more familiar with the Bourne shell variants than I am Powershell).

CMD.EXE is still included, but it is the red-headed stepchild.

> the Window doesn't even resize properly.

And the PowerShell window still does not resize horizontally by dragging, which is silly. You can do it by adjusting the window's settings, but this is insufficient. Win32 Console apps need to die.

> Plenty of tools that port easily to OSX or Haiku are difficult to port to Windows. Look at the situation with git.

Of course it is, it was originally written targeting a completely different OS. The same could be said the other way, that's why stuff like WINE and Mono exist.

> but aspects of the user experience is awful.

I concur totally. Getting Windows 7 to what I consider usable (in a power user sense) is a 30-45 minute job with a fresh install (as opposed to ~ 20 minutes on Mac OS X).

I complain about the crappy Console subsystem every release, I'll try to shout louder :)

It will get shot down due to legacy requirements. It boggles my mind they didn't start Powershell "legacy-free" and just emulate/re-implement the existing command line commands.

The problem if you do that, as soon as you run a console EXE, you're hosed, weird things will happen.

As any of us who run resource kit, support kit, or development kit tools have found ;)

Thanks for your unofficial input throughout the threads. They've been great nuggets of info and insight from the inside, so to speak.

Thanks - I certainly don't believe that Microsoft always has a good reason for what they do, but I try when I can to illustrate what was going through the engineers' heads when they built the thing.

When you build a system that has to work for everybody, from your grandma who just wants simplicity, all the way to the Federal Gov't who has complex requirements and restrictions, all while making 100% sure that everyone's programs work flawlessly even if they happen to be horribly written, sometimes you have to make lousy compromise choices, I think that's our biggest challenge by-far, is balancing the n-degrees of concerns through smart, disciplined engineering.

Also, here's a great example of how we have to balance "fix the bug!" with "make programs work!":

http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-t...