Rumors of Cmd’s death have been greatly exaggerated

This post is in response to a story published on December 6th 2016 by ComputerWorld titled "Say goodbye to the MS-DOS command prompt" and its follow-up article "Follow-up: MS-DOS lives on after all".

These "stories" were subsequently picked up by Business Insider and Life Hacker among others and fueled a number of concerned Tweets some of which I responded to directly, along with much discussion on Reddit, Hacker News, and elsewhere. It also resulted in several customers/partners sending me concerned emails asking if this "news" was true.

So, I'd like to take a moment to allay everyone's fears:

The Windows Cmd / Command-Line shell is NOT being removed from Windows in the near or distant future!

The Cmd shell remains an essential part of Windows, and is used daily by millions of businesses, developers, and IT Pro's around the world.

In fact:

  • Much of the automated system that builds and tests Windows itself is a collection of many Cmd scripts that have been
    created over many years, without which we couldn't build Windows itself!
  • Cmd is one of the most frequently run executables on Windows with a similar number of daily launches as File Explorer,
    Edge and Internet Explorer!
  • Many of our customers and partners are totally dependent on Cmd, and all it's quirks, for their companies' existence!

In short: Cmd is an absolutely vital feature of Windows and, until there's almost nobody running Cmd scripts or tools, Cmd will remain within Windows.

So, what was this article actually "reporting"?

The articles above were written in response to this paragraph from the release notes for the Windows 10 Insiders build 14971:

PowerShell in the Shell: In an effort to bring the best command line experiences to the forefront for all power users, PowerShell is now the defacto command shell from File Explorer. It replaces Command Prompt (aka, "cmd.exe") in the WIN + X menu, in File Explorer's File menu, and in the context menu that appears when you shift-right-click the whitespace in File Explorer. Typing "cmd" (or "PowerShell") in File Explorer's address bar will remain a quick way to launch the command shell at that location. For those who prefer to use Command Prompt, you can opt out of the WIN + X change by opening Settings > Personalization > Taskbar, and turning "Replace Command Prompt with Windows PowerShell in the menu when I right-click the Start button or press Windows key+X" to "Off".

Notice the nuance here:

The above paragraph states that "[PowerShell] replaces Command Prompt (aka, "cmd.exe") in the WIN + X menu, in File Explorer's File menu".

It does not say "[PowerShell] replaces Command Prompt", period! The paragraph even goes on to show you how to quickly launch Cmd, and points out that you can revert this default setting to launch Cmd by default instead if you prefer.

So, to be ultra-clear here: All that's happening is that, in the [Win] + [X] ("Power User's menu"), or File Explorer's File menu, PowerShell is presented instead of Cmd. That's all! Nothing is being removed, your scripts will continue to run just as they always have, the sky is not falling! 😉

Also, Cmd != MS-DOS!

I also want to point out a common misconception perpetuated by articles like the ones above: Cmd <> MS-DOS!


  • Microsoft last shipped a "new" version of MS-DOS (v8.0 in Windows ME), on September 16th, 2000 - 16 years ago (as of this writing)!!
  • MS-DOS was an operating system (albeit a relatively simple OS by today's standards) whose primary user-interface was a command-line shell, until Windows 3.x & 9.x arrived and ran on/around MS-DOS
  • MS-DOS' command-line shell's scripting language was relatively terse and moderately powerful, but lacked many of the richer, and more advanced features we enjoy in modern-day PowerShell, Bash, etc.
  • While later versions of MS-DOS grew in sophistication and added/replaced some older assembly with new code written in 'C', much of MS-DOS remained written in x86 assembly for efficiency, and because it was the only way at the time to gain access to many hardware devices and peripherals. This made MS-DOS non-portable to non-x86 CPU's. If you're so inclined, you can actually download the source code for MS-DOS v1.1 and v2.0 to see just how much of the earlier versions of MS-DOS were written in x86 assembly (hint: pretty much all of it)!


Interesting note: 32-bit versions of Windows derived from NT include an additional shell "" which runs many MS-DOS scripts and legacy 16-bit apps in a Windows NT Virtual DOS Machine (NTVDM) using the x86 Virtual 8086 mode along with some legacy "quirks". 64-bit versions of Windows do not include or the NTVDM.

On the other hand:

  • Cmd is a Win32 app written entirely in 'C' - this is important since one of the key goals of NT was to be portable across many different processor and machine architectures
  • Cmd is the default command-line shell built-in to the Windows NT family of OS' (i.e. Windows NT, 2000, XP, Vista, 7, 8, 10)
  • The Cmd scripting language was designed to be generally compatible with many MS-DOS scripts, to help users migrate from MS-DOS and Windows 9x/ME to the new NT-based OS family, but lacks many MS-DOS features since it is a Win32 shell running atop the Windows NT kernel and OS
  • Cmd is used to automate millions of businesses' login scripts, shop floor/manufacturing systems, data capture systems, etc., and millions of developers' build, test and deployment systems, etc.

So why the move to default to PowerShell?

Cmd has served us all well for almost 30 years now, and will continue to do so for a long time to come. But, WHILE CMD IS NOT BEING REMOVED FROM WINDOWS ANYTIME SOON (if ever), the reality is that PowerShell is a far, FAR more powerful shell than Cmd could ever be. Hence PowerShell's name. Surprise! 😉

We've gotten to the point with Cmd that we can no longer easily make improvements, enhancements or modifications to it! On the very rare occasions where we do make a fix, or change something, we generally break someone in the real world whose scripts/tools depend on that legacy feature/behavior. The last thing we want to do is break the Windows build system (that team get really upset when we break them 😉), or worse, break a PC OEM's production line, or damage a farm equipment manufacturer's welding robots, or prevent an enterprise's 150,000+ employees from logging-in to their PC's in the morning! This also means it is tricky to add new usability features such as auto-complete, color highlighting, etc.: If we change Cmd, we tend to break someone!

PowerShell, on the other hand, is much newer than Cmd and was built for today and the future. In fact, PowerShell celebrated its 10th birthday on October 25th 2016! It ably handles the rigors of the most demanding scripting environments on earth today and is highly extensible, flexible and ... well ... powerful! It was also recently open-sourced and ported to run on Linux, and is the backbone of the cross-platform Desired State Configuration (DSC) cross-platform declarative configuration initiative.

PowerShell's full syntax is seen by some as "verbose", esp. compared to some of the more "terse" Linux command-line tools (e.g. 'tar xvzf file-1.0.tar.gz' ... whut?). However, PowerShell was built specifically for long-term readability and discoverability (PowerShell's tab completion is AWESOME).

If you don't enjoy typing the longer commands, PowerShell makes it is easy to create your own shorter aliases (using the "set-alias" command), and scriptlets for more complex/verbose PowerShell operation. PowerShell also pre-defines a set of convenient aliases to abbreviate many common commands (run "get-alias" for the full list), along with aliases for common *NIX commands, e.g.: ls == get-childitem.

Now that we're seeing an ever increasing number of developers and IT admins (the primary users of shells) use PowerShell, we wanted to give them the ability to launch PowerShell as their default shell, instead of Cmd, while still allowing them to revert back to Cmd by default if they're not yet ready to move to PowerShell.

Hence the changes in Windows 10 Creator Update's UI, noted above.

In closing

I hope this post clears-up any last remaining concerns, fears, worries, confusion you may have about Microsoft's commitment to Cmd and the UI changes we're making to Windows 10 Creator Update, to help you find and use PowerShell more often, while still allowing you to revert back to Cmd as your default shell should you wish.

If you do see anyone claiming that Cmd is being removed from Windows, please reply with one or more of "No! Nope! Niet! Non! Negative! Nuh-huh! [Shake head vigorously], etc.", and refer them to this post. Thanks!

If you have any unanswered questions on these subjects, do fire-off below, or ping me on Twitter at richturn_ms!

Comments (106)

  1. Vitor Canova says:

    PowerShell can be great for Power Users but not for Power(ish) Users.
    I would prefer the default option as Cmd and a possibility to change to PowerShell.

    1. Please re-read the article and the included release note – you can choose to have Cmd or PowerShell as the default shell opened via several UI shortcuts if you wish.

      1. Vitor Canova says:

        Sorry Rich. I think I didn’t make myself clear. What I disagreed is the default choice set to Power Shell. I think it should remain Cmd.

        1. I lol'ed says:

          I think people should arrive in the 21st century.

          1. Vitor Canova says:

            I think you could write a more useful answer. But probably you were too busy showing off your script skill to someone.

  2. D. Ebdrup says:

    The CMD is dead, long live the CMD.

  3. Anonymous Coward says:

    I cringed when I read that “So long MS-DOS Prompt” post. Not only did the author clearly only get around to reading the Microsoft notes halfway through, hence the ducking and diving between moderation and outright scaremongering, but calling it an MS-DOS prompt belies a staggering degree of ignorance. Computerworld can do much better than that standard of journalism.

  4. Chasil says:

    The unfortunate fact is that cmd.exe was not designed well. It has many, many traps for the unwary.

    UNIX predates NT by 20+ years. It would have been far better if AWK had been extended to become the NT shell, with retrofitted MS-DOS compatibility hacks.

    Even Digital DCL would have been far preferable.

    1. awk is a text processing language, not a shell. In retrospect, it may have been wise to introduce some *NIX tools into MS-DOS and/or NT. However, remember that back then, IP ownership over UNIX was a legal minefield (and is, in fact STILL ONGOING:, to be replaced by the legal minefield of shipping tools built from GPL code in a commercial closed-source OS.

      I would also argue that the *NIX shells (e.g. sh, csh, ksh, bash, zsh, fish to name but a few) all have their fair share of inconsistencies, quirks, niggles, and gotcha’s

      Retrospect is a wonderful faculty. If only clairvoyance was the same 😉

      1. Chasil says:

        You may find it interesting to know that Steven Bourne removed C as much as he could, and not only built the Bourne shell syntax on ALGOL, but used C pre-processor macros to transform the language itself:

        This is an interesting wart on UNIX, and the Bourne syntax is one of the most incongruous of modern UNIX.

        The fact is that the authors of NT had *profound* experience with RSX11, VAX VMS DCL, UNIX sh, UNIX csh, PRISM, and (likely) DEC ULTRIX. They had likely seen all of this from a source code level.

        These people had profound experience. What posessed them to produce cmd.exe?

        My theory is the MS distaste for command line interfaces led to an extremely painful legacy product.

        1. Great info – thanks for sharing 🙂

          “What posessed them to produce cmd.exe”? Simple: The ability to run many/most existing MS-DOS .bat scripts at the time. Remember, back in 1989 – 1992, when NT was being developed, UNIX was not commonly used by individuals and businesses outside of academia, research & government installations. MS-DOS, on the other hand, was widely prevalent in businesses large and small, and already had a formidable volume of pre-existing scripts to drive and automate an already unimaginably diverse set of tools and scripts.

      2. Chasil says:

        Reviewing my copy of “Showstoppers” by G. Pascal Zachary, I find much discussion of Therese Stowell as the author of much of the mechanics behind cmd.exe – however, the book presents her not in reference to the parser’s grammar as much as the graphics coder who drew an 80×25 ANSI terminal and allowed the existing port of CMD to run.

        Wikipedia seems to think Stowell is the architect of cmd.exe, which appears to have come from the OS/2 world:

        OS/2 appears to have had a more profound influence on the NT shell than MS-DOS.

        In any case, it’s a pity that NT didn’t sideline thie OS/2 shell in favor of a more correct and powerful alternative. This has severely constrained NT for far, far too long.

        1. Eryk Sun says:

          Therese Stowell may have been involved with porting cmd.exe from OS/2 to Win32 in the early 1990s, but the original developers of cmd.exe on OS/2 will probably remain anonymous in long-forgotten corporate history at IBM and Microsoft. Stowell should be credited as the architect and lead developer of the console subsystem itself, which is actually much more important. cmd.exe is just a console client.

  5. Gili says:


    The main reason I personally avoid PowerShell is that the interface is a lot less user-friendly than cmd.exe

    In the latter, you can add /? to pretty much any command and get help. In the former, there doesn’t seem to be a consistent way to get help (at least nothing obvious when I took a quick glance).

    When commands fail in cmd.exe I get a nice user-friendly error message. When they fail in PowerShell I get an ugly stack-trace. While I appreciate a stack-trace, I don’t want to get it by default. I expect a user-friendly interface by default, with a stack-trace displayed if I ask for it (e.g. if I add –verbose or –debug).

    I hope this feedback helps.

    1. In PowerShell you can add /? to the end of almost any command and get MASSES of detailed help & examples (esp. if you run “update-help” from an elevated PS instance beforehand)! Alternatively, you can type get-help to achieve the same.

      Further … wonder what paramaters/arguments a command can accept? Type ” -” and then hit [tab] repeatedly. Also, if you enter “Set-PSReadlineKeyHandler -Key Tab -Function Complete”, and hit tab twice after the ‘-‘. you’ll see all supported arguments listed (so you can see them all at once if you wish).

      While PowerShell does have a learning curve, I cannot stress how unbelievably powerful it is, and that given just a little time to learn some of its core principles, most people end up FAR more productive than when using Cmd.

      I recommend this book, written by the PowerShell language designer, Bruce Payette:

      The first 3 chapters of this book are worth the purchase price as you’ll learn much about the rationale that led to the design of the PowerShell language.

      Your suggestion re error formatting is entirely valid – I suggest you open an issue on the PowerShell team and see if you can encourage them to consider:

      1. Gerry Pearson says:

        And to get even more *nix-like, the “help” command, which is NOT simply an alias for Get-Help, works just like *nix “man”, with “more” as an automatic pager. In fact, “man” is the Powershell alias for “help”.

        Now if we could just get “less” for Powershell. Surely somebody’s written it.

      2. Jon says:

        So I tried the “Set-PSReadlineKeyHandler -Key Tab -Function Complete” thing. Neat, but I don’t like it. How do I revert back to the default behavior?

        1. Jon says:

          Never mind. I see that since I didn’t add it to my PS profile, the behavior reverted back to the default once I closed and reopened the PS window. Thanks!

    2. Jeffrey Snover [MSFT] says:

      You want CategoryView for Errors. Just do this in PowerShell (and add it to your profile)


      That transforms:
      PS> dir asdf
      dir : Cannot find path ‘C:\Users\jsnover\OneDrive\Scripts\asdf’ because it does not exist.
      At line:1 char:1
      + dir asdf
      + ~~~~~~~~
      + CategoryInfo : ObjectNotFound: (C:\Users\jsnover\OneDrive\Scripts\asdf:String) [Get-ChildItem], ItemNotFoundException
      + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

      PS> #INTO THIS:
      PS> $ErrorView=”Categoryview”
      PS> dir asdf
      ObjectNotFound: (C:\Users\jsnover\OneDrive\Scripts\asdf:String) [Get-ChildItem], ItemNotFoundException


    3. warrens says:

      Not sure how anyone with full knowledge of both shells can correctly argue that cmd is “more user-friendly”.

      It’s not.

      You are personally more familiar with it due to more experience, so you /believe/ that it is user-friendly. Words like “user-friendly”, “intuitive” and “obvious” are the catchphrases of personal familiarity, not measurable objectivity.

      For example:
      1) You can type “help gci” to get help on gci.
      2) Any PS command that requires parameters will prompt you for those parameters in precisely the same way
      3) Parameter completion with tab. No other shell has this.
      4) Intellisense is available as of PS 5. Start typing a command then press ctrl-space to see available matches.

      Like, come on, stuff like this makes learning and navigating PS very straightforward. It’s impossible to argue that cmd.exe is any better.

      1. “Parameter completion with tab. No other shell has this.” – actually, the fish (Friendly Interactive SHell) shell does. In fact it does for any CLI program you install that has a man page, without extra configuration.

        fish also has intellisense for all commands, as well as file arguments by default, which is part of its baseline tab completion mechanism.
        That means it shows you all possibilities, like most Unix shells, but in a separate status bar, so as to not mess up your CLI screen. Then, you can cycle between them if you keep hitting tab (like in Windows, except you can see the matches), or you can just type further to narrow down your search (like in most Unix shells).

          1. Yeah, well actually, what I said about the status “bar” is not really true, since when there is a sufficient number of matches, it is more like a separate “screen” full of stuff. Although it does disappear after you are done selecting or have aborted the search, so it is pretty handy.

            Speaking of nice-to-have interactive features, is there a plan for creating an actually usable console for PowerShell?

            PowerShell itself is really nice, having actual data types aside from strings and all, but since I have to work a LOT in Bash and the old Bourne shell, I have learned to avoid any shell if at all possible, and do automation in sane languages like Python when I have the choice.
            Still, shells are invaluable for working interactively, where a GUI just won’t cut it, in which case it is nice to have features that might not be really good for programming, but make manual or in semi-automatized work easier.
            But a lot of that can be added on, like better autocompletion, a more configurable terminal, etc.
            Unfortunately, I think PowerShell is not really at the front in that regard. Were it not for that, I would probably use it all day.

  6. ram says:

    Thank you for clarifying this! It is a huge relief and very helpful for planning maintenance!

    1. Glad it cleared things up for you – sorry that the confusion arose in the first place.

  7. Thibault says:

    This is the kind of article I’d like to see more often. Great structure, very clear, fun tone, lots of crisp details…

    Once you get into a good powershell tutorial, you realise it’s pretty powerfull indeed. Parameters handling, object model, “clean” script language…
    A pray for all of us who have to manage existing .bat and .cmd

    1. Many thanks 🙂 I try to strike a balance between accuracy and humor. Sometimes, I even manage to hit that balance 😉

  8. JohnV says:

    One thing that would really help make this transition smoother for me is if Windows Explorer had options for both Cmd and PowerShell.

    If I shift-right-click in an Explorer window I get a menu option that says “Open Powershell window here”. It would be super duper if there was also a “Open Cmd window here” menu item. That way, I could try out PowerShell, but if I get frustrated temporarily, I could easily bring up a Cmd window instead for the given task I’m trying to do.

    Just a thought…

    1. Explorer menu items are controlled via the Registry – you can put links to almost anything you like in there 😉

      1. JohnV says:

        Thanks for the tip. I tried to follow the tutorial and there’s already a “cmd” entry in the registry there. I tried to rename the key “HideBasedOnVelocityId” to “ShowBasedOnVelocityId” to re-enable it, but it gave me an error:

        “The Registry Editor cannot rename HideBasedOnVelocityId. Error while renaming value.”

        At any rate, I think having both enabled by default, or at least making it easy to do so, would be helpful to many people. I doubt most people are going to bother with registry edits.

  9. Jason says:

    Are you guys still trying to improve the speed of Powershell? That’s our biggest reason for not moving.

    95%+ of our scripts will already work in Powershell, but it’s so slow. It takes a while just to get Powershell started, whereas CMD is instantaneous.

    1. Yes, although I don’t know why your PowerShell starts up noticeably slower than Cmd.

      For reference, PS on my SP4 takes ~0.4s to start up a PowerShell session with no profile loaded.

      Now, I do have a pretty heavily customized PowerShell startup profile ( which takes ~0.57s, but I don’t find that particularly egregious.

      If you are seeing your PowerShell sessions take longer than ~0.5s to load, you might want to try opening cmd and running “powershell -noproile”. If it now loads much faster, you should take a look at what you’ve got in your PowerShell profiles that loads and runs every time you start a new PowerShell session.


      1. FZB says:

        hmm, interesting. never considered -noprofile, but it actually does cut down powershell startup times to make it a viable replacement for those times where you need a command executed fast 😉

        1. Then I definitely encourage you to see what you have in your PowerShell profiles: You may well have too-many/unnecessary scripts that run every time you start a PowerShell prompt!

      2. Jason says:

        We use scripts on new Windows deployments. So these installations have zero customizations; we are using it however Microsoft sent it to us. If the profile is screwed up, it’s because it was like that from Microsoft.

        I will try noprofile, but on every single deployment we have ever done so far, a 10-second wait is not unusual from the time we invoke the script to the time the first line of the script runs.

        Powershell also does not seem to run commands quite as quickly as CMD. Not a big deal in short scripts, but it adds up.

  10. David says:

    I’m sure that in one of the versions of Windows 8/8.1, the default Win-X option was changed to Powershell.
    Why did it get changed back to Command Prompt in Windows 10?

    1. I may be wrong, but I don’t believe PowerShell was ever officially added to Win+X, but since one can modify the menu’s items, perhaps you’d run a script to do so?

      1. DavidY65 says:

        Hello Rich,

        Thanks for replying to me.
        It seems Powershell was added to Win-X around 2013. There are various articles from around that time. such as this one telling you how to put the Command Prompt back:

        It still seems odd that it was switched back in Win 10.

        1. abbodi1406 says:

          It was added as an option to replace cmd with ps, but cmd was still the default

      2. DavidY65 says:

        I figured it out… Powershell was indeed the Win-X default in Windows 8.1 *Preview*. I spent a fair bit of time playing with that Preview, which I guess is why I remembered it.
        But I think by the time Win 8.1 got released, the default was changed back to Command Prompt, with an option to choose Powershell if you wanted.

  11. Renato Golia says:

    I love PowerShell and I already use it a lot, especially with external modules like posh-git and so on.

    Just a question hiding a feature-request…

    Why isn’t mklink natively supported in PowerShell?

    1. Largely because until recently, nobody used symlinks on Windows because one could only create them from elevated Cmd prompts, which nobody did.

      This GitHub issue was tracking the proposal for New-Symlink, but it’s closed – have asked why – follow-up there if interested.

  12. Wendy Krieger says:

    The main reason people confuse cmd.exe with MS-DOS is that in the early days of Windows, Microsoft called cmd.exe the ‘dos prompt’ too. Of course, running DOS programs seamlessly in the cmd.exe window does not help either.

    Under OS/2, separate windows were supplied for the DOS prompt and the OS/2 prompt. You went to one or the other to run the proggies, and no one called OS2 vio programs as ‘DOS’ programs. You fired up an OS2 window to run OS/2 proggies.

    I still use both. It is quite clear under OS/2, that there are ‘dos sessions’ and ‘os2 sessions’ as well as ‘pm sessions’.

    1. Back then it WAS the DOS prompt: It used to spawn an instance of MS-DOS in a window.

      In NT+, it was called the Command Prompt since there was no MS-DOS involved.

      Yeah, OS/2 made the separation clear in its naming. Had it survived, I am not sure users would have necessarily grokked the big differences though.

      1. Sorry for the serious pedantry, but up until NT 4 the shortcut was called “Command Prompt” but had the big colorful DOS 5-era “MS DOS” icon next to it. The black window icon started life in Windows 2000.

        1. Good point: All part of the process of making a brand new OS (literally, at the time), more approachable/discoverable by Windows / MS-DOS users 😉

    2. Wendy, did you also use OS/2 1.x (aka 286-based OS/2) which was incapable of virtualizing real mode DOS sessions so had a single system wide DOS prompt, but multiple windowed OS/2 prompts? There was a config.sys setting to reclaim the global 640Kb DOS session and give that memory to OS/2 instead. I can’t help but think the OS/2 team arrived where they did by a series of historical accidents more than intentional design.

      Around the same time I was using 16 bit Windows, which as mentioned here, supported (true) DOS prompts that didn’t have any interaction with Windows functionality, so launching a Windows application from a DOS prompt was impossible. That lead me to create my own 16-bit Windows command interpreter to overcome the limitations of the separation between Windows and DOS. Windows 95 really addressed this (since could launch Win32, Win16, DOS, or Win32 console processes), and I threw my interpreter away.

      There’s something very powerful about a single interpreter that can launch processes destined to any subsystem. I really wouldn’t want to go back to the OS/2 way.

  13. Simon says:

    So, are you getting rid of it or not?

    1. LOL 🙂 Only after the last remaining .bat/.cmd script have been converted to PowerShell 😛

  14. PowerShell is for sure a better shell than cmd, and the concept of passing around objects instead of nondescript encoding-less “plain text” to be parsed is genius.

    I only wish that its syntax wasn’t such a tire fire, and this is coming from someone comfortable with Perl. I guess the room to provide a sane syntax was sharply reduced thanks to the usual shell-isms that people will expect to work, pipes, greater-or-less-than and ampersands all being spoken for. In addition, the “UNIX aliases” (providing ls and wget names for roughly matching functionality without any attempt whatsoever at full or even partial compatibility with flags and options) was a meddlesome mistake from the beginning and has now rightly been revealed as such when going open source. I can only hope that in the future, Microsoft will be more attentive to its eventual users from the start.

    1. When PowerShell was first being designed – circa 2003 – I don’t think there was any real expectation that a) it’d ever be made available on *NIX platforms, and b) relatively few people were running a *NIX-based OS as their daily driver. The world has changed a lot since then.

      I think the PS team are very, VERY aware of the issues introduced by simply aliasing a command name sans argument compatibility, and I am sure that through working with the community, a decent solution will arise.

      However, I disagree that PowerShell the language is a dumpster fire: Read the first 3 chapters, esp. Ch1 of “PowerShell in Action” ( and you’ll see the extraordinary detail Bruce, Jeff & team went into to synthesize a sane, discoverable, extensible scripting language which systematizes a high degree of consistency across tools and scripts.

  15. Paul Taylor says:

    “When I first learned how to list my files on Linux, I had to type ‘ls’. I couldn’t help saying ‘whut?’. But when I moved to PowerShell I had to type ‘get-childitem’ and it felt like I was coming home to mama.” <– Said nobody at all. 😉

    1. Alas, say some who only every look at a simple PowerShell language sample, and assume that their only option is to type everything long-hand 😉

  16. Al D. says:

    If only Microsoft would embrace the Bash shell, rather than power shell. (Can’t wait for Windows 10 at work, when I can start using the Linux/Ubuntu environment!)

    1. With respect, you clearly don’t understand PowerShell.

      Bash, when combined with a broad toolset of additional helper tools, is very powerful, no question.

      However, if you look at Bash alone, it’s a relatively simple command-line shell that doesn’t “do” much.

      PowerShell on the other hand, takes many positive aspects of shells like Bash, and innovates upon them: A key to PowerShell’s unique approach is that instead of passing text from one tool to another, it passes objects & collections of objects – each of which have specific properties and methods that can be called on them. This gives one FAR more power and control over the platform, apps, systems and tools. Also, because PowerShell is a .NET language, one can create scriptlets, functions, objects, etc. using PowerShell itself should you wish, or using C# / F# / C++, etc. if you prefer, and they’ll all share the same type system with access to the richness of the objects they generate and consume.

  17. Cole S says:

    As someone who has had to write Powershell scripts, they are ridiculously, stupendously hard to get to work. Just trying to get a program to launch as a different user took me a good 10 hours. All the examples that I found online didn’t work. After who knows how many times of trial and error, I finally figured out the way that it wanted me to pass the parameters to the program. I can’t even imagine using it as an everyday command line tool! Powerful means squat if it isn’t usable.

    1. You mean like this: – it was the second link returned when I bingled “powershell launch program as a different user”.

      Further, in his book “Windows PowerShell in Action” (Manning Press), Bruce Payette (the designer of the PowerShell language) dedicates section 21.6.3 of chapter 21: “Security, security, security” to “Working with credentials” which is referenced under “runas” in the Index. There are several other sections throughout his book which cover credential usage scenarios & techniques.

      And if you didn’t want to use PowerShell itself to run an app under specific credentials, you could have used runas.exe ( which is what you’d have used if you were writing a Cmd script anyhow.

      Don’t mistake personal unfamiliarity with a tool’s power / usefulness / etc. PowerShell can do far, FAR more than Cmd ever could and usually FAR more easily (once you learn how).

  18. Richard Polichetti says:

    Oh I get it now. TY!

  19. Cass Lopez says:

    So, not being removed then?


  20. Jacob Klein says:

    I would like to be able to “Open Command Prompt From Here” in File Explorer. It seems that I’ve lost that ability. I don’t understand why both cannot be available at the same time, in File Explorer -> File.

  21. D. says:

    Guess that’ll teach you to nuance.

  22. JD says:

    I see what you did there Dr. Cox.

    1. ROFL! I had *NO* idea this was a thing … but it’s awesome! 😀

      My “No! Nope! Niet! Non! …” thing came from a blog I wrote on March 5th 2004 regarding claiming that Microsoft was removing .NET Remoting from the .NET Framework! Strange how history repeats itself due to latent human behavior 😉

  23. Beanyness says:

    I like how you quote “reporting” and “stories” lol… Because we all know these so-called “journalists” are as competent as a monkey with a keyboard. Clickbait and idiocy. The media is a joke. Even random bloggers and youtubers often have more legitimacy and accuracy. It must be SO frustrating having to deal with these people and all the false “news” they “report”. Nice to see you naming these sites too.

    I get the impression you’re fed up with them, like so many of us are, but you can’t go too far and blatantly call them out on their stupidity and lies, because you work at MS and have to act professional. If i was in your place i don’t think i could control myself.

    1. There are many online journalists/analysts who I greatly respect and very much enjoy working with and/or reading. These journalists primarily focus on reporting facts and information in an enjoyable-to-read and easier-to-understand manner. They prefer direct-access to sources to ensure accuracy, or if using 3rd party sources, check their claims, and their credibility first. Some of these journalists are spectacularly good, rapidly comprehending and communicating often poorly articulated, complex subjects in a way that even I can understand!

      Alas, there are some journalists who, while being otherwise v. competent, usually skew their content heavily towards their own biased viewpoints and opinions, and prefer clickbait titles and articles. Why is anyone’s guess, but it’s often been stated that fabricated clickbait titles draw larger audiences.

      The interesting thing here though is that it doesn’t take much to write titles and articles that may appear as clickbait, but which are backed-up by plenty of facts (not others’ opinions) and which still generate A LOT of traffic & conversation. For example, Mary-Jo Foley very kindly offered me a guest-post spot on her ZDNet blog back in May 2012 (, which at the time, before Microsoft’s explosive rate of open-source adoption & support, was seen as heresy by many (just read the comments! ;))

      With so much actual news to report upon, it pains me that there are some who insist on NOT finishing reading something before writing about it, or who simply make things up to suit their own agenda.

  24. I understand that changing the core CMD parser is a regression risk, but why the lack of new tools and utilities that are designed to be callable from CMD?

      1. Well, obviously the things most interesting to me are the ones I’m writing. You can see them on my website. I can’t describe how much of an improvement I think sdir ( is over dir. I don’t know why clip.exe was added to Windows in the Win7 timeframe only supporting plain text, and ended up writing htmlclip.exe ( for rich text. The other tool I wrote semi recently was CvtVt ( to allow VT100 escapes to be translated to HTML, so I can paste colorful command prompt text into emails etc. My Dad recently revived/rewrote one of his DOS-era tools for handling user input in batch files, which has very minimal support today.

        But I don’t mean to suggest the things of value to me must be of value to everybody. I’m sure there’s a long list of things people out there want, and not all of them need to be in CMD itself.

        On a related note, likely the next set of tools I’ll end up writing would be for basic file manipulation of paths >MAX_PATH. Which command line tools support this today, and which do not?

        1. Thinking more about this (and sorry for the double reply), here are some things I don’t know how any Windows CMD user can really live without.

          1. Zip/Unzip and similar. Maybe even tar/bzip2/gzip etc.
          2. A command line text editor. I use vim but many are available.
          3. Ssh/Scp etc.
          4. Chocolatey/apt-get/yum or some functional equivalent.

          In each case these are just standard tools that are needed for normal tasks. They’re built in to other platforms, which typically ship multiple of each (eg. the number of text editors on Linux.) Closed source platforms (eg. OS X) don’t seem to have trouble distributing open source versions of these either.

          I know Microsoft started an OpenSSH port but haven’t heard anything about when it will be finished/included with Windows. For anything that requires an explicit download, the obvious question is why a user would download the Microsoft version as opposed to any other freely downloadable tool.

        2. Great looking tools 🙂

          One reason why we can’t, for example, modify the layout of file lists returned by Dir is that if we move even one character, we break THOUSANDS of existing scripts and tools. Ask me how I know 😉

  25. Jason says:

    One more thing: I wish you guys could literally get every single setting in Windows to correspond to a Powershell cmdlet. If I could literally rebuild a computer by pasting in my Powershell script, that would be amazing. Just like with Cisco’s switches, which are also amazing in that respect.

    But it would literally have to be all settings. If anything was missing, it’d basically be undependable.

  26. Bewc says:

    Thank you for addressing this!

  27. Previously in Windows 10 [Win]+[X] contained menu option for running Command Prompt.
    In Windows 10 Insider Preview, Build 14986 it is there no longer.

    Also, previously Windows Explorer had TWO options in ribbon menu: Command Prompt and Power Shell.
    In Build 14986 there is only one option, PowerShell.
    See part of screenshot of my desktop (in Polish):

    The same is for [Shift]+[Right Mouse Buttin Click] on a folder: there was “Open Command Prompt here”, now there is “Open PowerShell window here”. That’s a mega-push of PowerShell onto users, one that seems like cmd.exe is gone (it’s not, but it looks like one).

    1. Hey Wiktor. What you describe is exactly what this article is about: In a recent Win10 build, the **default** prompt offered in Win+X & File Explorer **WAS** Cmd but is **NOW** PowerShell. You can update your settings to change the default shell back to Cmd if you want.

      Personally, I recommend everyone start using and learning PowerShell … it really lives up to its name! 🙂

  28. hypothesis says:

    Thanks everybody for the all clarifications in the comments!

    First things first, could you please correct the link to ComputerWorld’s follow-up article to
    instead of

    Now on to real question 🙂
    Are any plans to open source all DOS versions from 3.0 up to 8.0?
    I guess it’d be very educational to have such thing at hand.

    1. Thanks for the link fix 🙂

      Open source DOS? Unlikely since some (esp. later) versions of MS-DOS included code and tools from 3rd parties, from whom, securing rights to open-source will be very difficult.

  29. Now I understand why a Windows Core session opens with a CMD window instead of a Powershell window…

    Was just struggling today with netsh, which works fine in CMD but has some bugs in Powershel.
    (doesn’t accept more than one scenario)

    Similar situation in with Certutil.exe…

    1. Could you share a repro where netsh fails under PowerShell? It should work fine.

      1. PS C:\temp> Netsh trace start scenario=DirectAccess,wfp-ipsec capture=yes tracefile=c:\temp\ipsec.etl filemode=circular maxsize=2048
        Invalid value “wfp-ipsec” for command option “globalKeywords”.
        See ‘trace start help’ for detailed help.

        PS C:\temp> cmd
        Microsoft Windows [Version 6.3.9600]
        (c) 2013 Microsoft Corporation. All rights reserved.

        C:\temp>Netsh trace start scenario=DirectAccess,wfp-ipsec capture=yes tracefile=c:\temp\ipsec.etl filemode=circular maxsize=2048

        Trace configuration:
        Status: Running
        Trace File: C:\temp\ipsec.etl
        Append: Off
        Circular: On
        Max Size: 2048 MB
        Report: Off


        This was with Powershell 4.
        As soon as I upgraded to Powershell 5, it worked fine! 🙂

    2. Discovered yesterday another issue : BCDEdit works fine in CMD but not in PowerShell where you can only handle boot options from the currently running operating system.

      Certutil, netsh, bcdedit, …
      This makes me conclude that executables with parameters are better processed by CMD than by PowerShell.

      1. bcdedit, like certutil, etc., are command-line executables. PowerShell doesn’t do anything with arguments / parameters passed to command-line utils. Could you share an example of something not working?

        1. I wanted to rename my different operating systems on a multi-boot partition and tried to use examples of this document:

          When I switched from Powershell to CMD, the command-line worked fine.

          C:\Temp> bcdedit /set {current} description “W2K12”
          The set command specified is not valid.
          Run “bcdedit /?” for command line assistance.
          The parameter is incorrect.
          C:\Temp> cmd
          Microsoft Windows [Version 6.3.9600]
          (c) 2013 Microsoft Corporation. All rights reserved.
          C:\Temp>bcdedit /set {current} description “W2K12”
          The operation completed successfully.

          The behavior is the same on a Windows 2016.

          1. There’s something odd going on with your setup. bcdedit.exe lives in c:\Windows\System32:

            PS C:\> where.exe bcdedit.exe

            If you can’t run `bcdedit /?`, then you need to figure out why! Runs fine on my box!

            PS C:\> bcdedit /?

            BCDEDIT - Boot Configuration Data Store Editor...

          2. Rich,
            bcdedit /? works fine for me too.

            From a Powershell prompt, please try to rename your operating system and then name it back
            with any of the following command lines:

            bcdedit /set {current} description “WhatEverYouWant”
            bcdedit /set {default} description “WhatEverYouWant”
            bcdedit /set {ID_number} description “WhatEverYouWant”

            This works fine in a CMD prompt but returns an error message in a Powershell prompt.

          3. Wait … you did follow the instructions on the bcdedit docs page, right?

            Note  If you are using Windows PowerShell, you must use quotes around the boot entry identifier, for example: “{49916baf-0e08-11db-9af4-000bdbd316a0}” or “{current}”.

          4. Oh! Great!
            Thanks Rich!

            Anyway, I am a real fan of Powershell, and even sometimes continue to script from home outside of my office hours.
            However, you sometimes have to struggle when you want to use CMD commands in Powershell.
            I really wish I could do everything with Powershell.
            But the idea to develop a BCD Powershell module has sadly been evicted by Microsoft.
            Like you said, CMD will stay for a long time…

          5. What that response is telling you is that the PowerShell team don’t own BCDEdit. If you’d like a BCD PowerShell wrapper, then I encourage you to create one and publish via the PowerShell Community Extensions.

            While there are a few built-in Cmd commands that require invocation via cmd.exe /C ... (e.g. mklink), I don’t know of any stand-alone command-line or Win32 apps that cannot be invoked via PowerShell. If you do find any, please let me know.

  30. Anonymous says:

    Just FYI the link to the follow-up is broken – it ends in .htm when the actual page is .html

  31. my issue is, that Powershell is SlowShell. The initialization takes so long. This is why I also avoid the nuget console in VS and use the GUI to install Nuget packages.

    1. PowerShell is FAR from slow. If it starts up slowly on your PC, its likely that your $PROFILE has lots of stuff that runs each time you start a new PowerShell session.

      To test for this, open Cmd and then type `PowerShell -NoProfile` and hit enter. If PowerShell opens more quickly than ususal, check your $PROFILE and make sure it’s not running any unnecessarily long scripts etc.

      FWIW, my PowerShell starts in < 0.63s on average!

  32. imdoody says:

    This discussion seemed to turn into My CLI is better than yours… There’s always a “better” CLI if your argument is that this CLI is missing this one cool feature that this other CLI has. And powershell is an excellent tool and should replace the default command prompt in Windows. It can run (to my knowledge) every command that cmd.exe can, and so much more. Oooh, and it can be updated… How about the for a feature. Sorry I’m not usually so spiteful, but didn’t get much sleep last night… I read the first few lines of an awful article saying M$ was removing cmd… Lol jk

  33. help
    I’m a user not “technical” – My use includes my stock market portfolio – just tracking changes in value on daily basis with VBA Excel and future hope for VBA Access..

    Thus is what more do I need to know? – what is AZURE ? Do I need to master DSN (Dynamic Name System [?]), and any other three-letter acronyms. Where I find BIBLE to decipher computer GEEKS language.

    1. not “technical” – nothing for you to worry about here then 🙂
      What is AZURE – and you say you’re not technical? If you’re still interested:
      Do I need to master [DNS]: No.
      Where I find BIBLE to decipher computer GEEKS language: Bing/Google.

      Thanks for stopping-by 🙂

  34. Rich, let me quote your statements first:
    “and points out that you can revert this default setting to launch Cmd by default instead if you prefer.”
    “All that’s happening is that, in the [Win] + [X] (“Power User’s menu”), or File Explorer’s File menu, PowerShell is presented instead of Cmd. That’s all! ”

    Only half of this is true, the other half is conveniently omitted. As of the current insider build 15031, PowerShell also replaced CMD in the shell context menus (folder and folder background). The key problem is that the Settings parameter only lets you alter the Win+X menu behavior, but not Explorer “File” and context menus. So if I need to open CMD in the folder, I have to open PS and type cmd (that’s the official MSFT answer to user feedback actually).

    Haha, you can tweak the registry, you say in the comments linking to Petri. What you fail to acknowledge is that the related context menu registry keys are now placed under the Trusted Installer ownership (Administrators group owns them in Windows 7, and I don’t have Windows 8.x atm to compare). This makes it significantly harder to tweak the system according to user preferences. And how about the File menu? And anyway, why do I have to mess with the registry, change the ownership, etc, if you can simply provide a parameter in Settings that takes care of everything?

    What we have here is a typical MSFT story – forcing undesired UX upon users, taking away the UX they are accustomed to and making it hard or impossible to restore the desired behavior.

    Yes, I know this is about insider builds, that MSFT is still collecting feedback, etc. And I’m providing feedback here (in addition to the Hub), because the original post hides the inconvenient truth behind underlined capslock.


    1. Hey Vadim. Thanks for your feedback, and apologies for not replying before now, but we’re slap-bang in the middle of wrapping up Creators Update and planning our next release so have not had enough time to reply to your lengthy post.

      First, we (Console & Bash) do not own Explorer UI features like menus and context menus – that’s owned by the shell team. However, I have reached out to that team internally and have instigated a conversation about the feedback that you and others have shared/raised with me directly. No promises, but know that the issues are under discussion.

      Second, new keys can be added under “\HKEY_CLASSES_ROOT\Directory\shell\” which, if configured correctly, allows one to create custom Explorer context menus, which is how Git, VLC, PowerShell & VSCode, for example, manage to add their own Explorer context menu items.

      HOWEVER, while this will launch a Bash prompt, it won’t open at the requested folder location. This is a current limitation of Bash.exe that we aim to fix in a future release.

      Polite Note: Perhaps it gets muddled in translation, but terms like “conveniently omitted”, “What you fail to acknowledge”, “inconvenient truth”, and “typical MSFT story”, etc. can be seen as somewhat antagonistic and set a combative tone that we’re trying to discourage around here; we much prefer a more pleasant, congenial atmosphere – the world is dark enough as it is.

      Please keep the feedback coming; we appreciate your time and effort in sharing your experiences.

      1. Hi Rich! Thanks for your reply.

        1. HKEY_CLASSES_ROOT\Directory\shell is owned by SYSTEM, and HKEY_CLASSES_ROOT\Directory\shell\cmd is owned by TrustedInstaller. So if “configured correctly”, end users can’t easily make changes, like I said. We’re back where we started.

        2. I understand that you don’t own the components I have discussed, but *you* stated that one could easily configure / revert the behavior, which is not the case. You probably didn’t know about this and ended up on the spot. Well, put the Shell team on the spot next time. You may learn that they want no part of this 🙂

        3. Polite note. If you feel that my *words* are “somewhat antagonistic and set a combative tone”, then it should be easy for your to understand that I (and other customers) can feel the same about Microsoft *actions* worsening the UX and breaking our daily routine. We also “much prefer a more pleasant, congenial atmosphere” in Windows we use daily unlike your blog.


        1. 1. Users that are able to elevate (i.e. have access to local admin rights) can allow installers that create Explorer extensions (e.g. Git for Windows, VLC, etc.). Most users who cannot elevate should likely not be changing settings that might affect other users on the same machine.
          2. Some keys/values are protected by TrustedInstaller so that they cannot be hijacked even by elevated admin processes. This is a good thing: Stops malware from taking-over key functions of your PC.
          3. “Probably didn’t know this” – clearly not.
          4. “Unlike your blog” … wow! Thanks for playing.

        2. Eryk Sun says:

          HKCR is a merged view of [HKCU | HKLM]\Software\Classes. It’s intended for reading, with preference for HKCU over HKLM. When modifying a key, you should reference the user or machine hive explicitly, not the HKCR merged view. A user can easily modify his or her own Directory\shell\cmd subkey.

  35. Glenn says:

    Does PowerShell support scripts written as UTF-8 with no BOM, for full compatibility with the Unicode character set? If not, it is no better than CMD, so why convert? If it does, I’ll consider it.

    1. I believe it does, yes. Because as the UTF-8 spec states, BOM is superfluous other than to express that the file is UTF-8 encoded. Have you tried?

      “Why convert”? Because PowerShell is MASSIVELY more … well … powerful than Cmd. It has a FAR more expressive and consistent syntax and can reach into and administer practically every part of Windows and its many systems and services.

  36. Wolf1098 says:

    “On the very rare occasions where we do make a fix, or change something, we generally break someone in the real world whose scripts/tools depend on that legacy feature/behavior.” Shouldn’t it say something not someone?

Skip to main content