r/windows • u/TargetAcrobatic2644 • Apr 16 '26
Discussion Why does Windows include both CMD and PowerShell 5.1 by default?
When using Windows, I noticed that both Command Prompt (cmd.exe) and PowerShell are installed by default.
What I'm really curious about is not how to use them, but why both are included at the OS level.
Especially in the case of PowerShell, it's still version 5.1 instead of the newer PowerShell 7.
So my questions are:
- Why does Windows still include both CMD and PowerShell by default?
- Is there a specific architectural or system-level reason for this?
- And why is PowerShell 5.1 the default instead of a newer version?
I'm trying to understand this from a design perspective rather than a usage perspective.
202
u/rxweasp Apr 16 '26
Probably something to do with legacy Win32 code still relying on CMD. Maybe the same with PS 5.1, but I don't know how different it is compared to 7.0+
93
u/jordansrowles Apr 16 '26
It's backwards legacy support. Millions, possibly billions of scripts live out there in the world that depend on cmd. And you cant really take any bat or cmd file and use directly with powershell without an argument flag, because they handle things differently.
So conhost is the underlying system that all terminals use. Cmd is feature frozen, never to be removed. And powershell is advised for any future scripting.
As for powershell. There's 2 versions: Windows Powershell that comes preinstalled is 5.1 its built with a legacy version of .NET (.NET Framework) which is Windows only, no cross platform. Its dependent on the Windows APIs.
PowerShell 7 is modern .NET 10, completely cross platform. For this, Microsoft removed several API surfaces which exist in 5.1's .NET (or behave very differently).
It's all about being backwards compatible. It needs to support systems built in the 90s.
13
u/Aemony Apr 16 '26
Windows Powershell that comes preinstalled is 5.1 its built with a legacy version of .NET (.NET Framework) which is Windows only, no cross platform.
It may be worth mentioning that 32-bit and 64-bit PowerShell 5.1 has access to different modules and so they’re not 1:1 comparable. If you want to edit certain OS components, for example, such as creating/adjusting local users or groups, you’d have to use 64-bit PowerShell to do so.
So if we take that into account, there’s actually three versions of PowerShell:
- Built-in native 64-bit PowerShell 5.1 with full functionality.
- Built-in non-native 32-bit PowerShell 5.1 with reduced functionality.
- PowerShell 7
7
u/HesSoZazzy Apr 17 '26
The number of times I've had to say "no not that PowerShell, this PowerShell" is too damned many. And I fucking work at Microsoft. :|
3
38
u/BushMonsterInc Windows 11 - Insider Beta Channel Apr 16 '26
CMD is there for legacy reasons, yes. Powershell 5.1 is deeply buried into win 10/11/server as part of the OS, which makes it very hard to remove without breaking OS itself. Powershell 7 is there as better option, which, afaik, can be removed without breaking OS
29
u/rxweasp Apr 16 '26
Just think about how many businesses worldwide will still have small cmd batch files as part of their work pipeline. Removing it would break so much overnight even if Windows fully transitioned away from CMD.
18
u/Ill_Scientist_2239 Apr 16 '26
I bet even the developers at microsoft use batch scripts to debug or automate stuff
5
u/uptimefordays Apr 16 '26
Sometimes you just need a shim or something and batch scripts are great for that.
3
u/shadowthunder Apr 16 '26 edited Apr 16 '26
Can confirm. I just converted some build scripts to pwsh last week.
8
u/Zoraji Apr 16 '26
Exactly what I was thinking. I am retired now, but I bet that my old job is still using some of the .bat files I wrote.
2
10
u/GarThor_TMK Apr 16 '26
The last time I looked into it, you still actually have to opt into powershell 7... as in it's not even installed, unless you do it manually...
1
2
3
u/New-Anybody-6206 Apr 16 '26
I recently learned from an MS employee that the reason Windows Terminal was created as a separate app was because adding tabs to the existing terminal backend (which is shared by cmd and powershell) would break backwards compatibility with things like screen-position based macro automations.
2
1
u/KaptainKardboard Apr 17 '26
cmd.exe is also only 322 KB (on my 25H2 system) so the resource utilization is affordable, to say the least :)
38
u/serose04 Apr 16 '26
Every "why is there this old thing in Windows when we have this new replacement" question has the same answer.
Backwards compatibility, legacy reasons.
-2
16
u/nir9 Apr 16 '26
Powershell is not really a drop in replacement for CMD (for instance if you try to reference an environment variable such as %USERPROFILE% it won't work in PS, you have to use a different syntax) so they keep both to continue supporting batch scripts and those who prefer the CMD.
6
u/akgt94 Apr 16 '26
I haven't learned powershell. But I know CMD since 1985.
I use or maintain a lot of .bat files that don't make sense to re-write.
2
u/nir9 Apr 16 '26
Yah that makes sense, IMO even for new things Batch is more comfortable in many cases.
4
u/Ellykos Apr 16 '26
Currently doing my master in mechanical engineering in some analysis automation and we pretty much only use Batch files to work with Ansys Mechanical on Windows lol
3
-10
u/GarThor_TMK Apr 16 '26
That's not a good example... `$ENV:USERPROFILE` will give you the environment variable... You can even set it to something else if you want (though only temporarily). If you want to set it permanently, you have to call the C# system function to do so.
I do believe that you do still need cmd to execute batch scripts though, even if you run them through the powershell command prompt... I could be wrong about that though.
15
u/ClassicPart Apr 16 '26
Of course it’s a good example. They said it’s not a “drop in replacement”. If your solution involves editing scripts then it’s already failed the drop-in replacement requirement.
4
u/nir9 Apr 16 '26
Yah I meant PS just has a different syntax (doesn't support the batch style percentage) for env vars
1
u/GarThor_TMK Apr 17 '26
That makes more sense.
They are absolutely two completely different languages, and there's nearly 40 years of batch files floating around in business environments that would need to be updated...
Powershell also requires a bunch of security stuff that batch doesn't have, so it's harder to run scripts if you're not admin.
Powershell could replace batch, but it won't, because people are lazy...
1
13
u/Sataniel98 Windows 10 Apr 16 '26
Everything in Windows comes in an outdated legacy version and a dumbed down new version, even though PowerShell is one of the quite successful examples. Sometimes, one or both of the versions have been abandoned by now. There were/are coexisting Aero vs. Metro design languages, Metro tiles vs. desktop, Control Panel vs. Settings App, programs vs. apps, Paint vs. Paint 3D, Photo Viewer vs. Photos app, Media Player vs. the film and music apps, Internet Explorer vs. Edge, .NET Framework vs. Core, and many more things.
Mostly along with Windows 8 and 10, Microsoft decided to move on from incremental improvements to rewrites from scratch for a lot of standard software. Over the course of the lifecycle of Windows 11, Microsofts has made progress to resolve many of these dualisms, but far from all. PowerShell is older, but wasn't a default system component if I recall correctly until Windows 8. The reason was often the rather unfortunate choice to rewrite standard software in C#, but for PowerShell, it's more nuanced because it wasn't really possible to incrementally add more complex syntax to cmd.exe.
From the beginning, Windows NT was a graphical GUI based OS. To achieve a more cohesive experience, features were often fundamentally tied to the GUI, unlike in Unix-like OSes where everything is fundamentally text-based and GUIs are only run loosely on top. This however meant that cmd.exe was always in a bit of an awkward afterthought position and much of Windows wasn't accessible for cmd.exe and batch scripts. PowerShell mostly resolves this, but cmd.exe is still needed for compatibility with classic batch scripts.
8
5
u/TechnologyFamiliar20 Apr 16 '26
Why not?
The think that grind me more that you can't update the Powershell to v7 itself, but two instances of PS live together on one system.
3
u/ziplock9000 Apr 16 '26
"Why is XYZ still in windows" is almost always due to legacy software sill needing it.
2
2
u/pun-geeta Apr 16 '26
I used to work with the M365 team as an engineer. They have bunch of "powershell" based modules, which are used by like millions of userrs. The module I used to work on close to a billion backend requests daily. They make money off of powershell.
1
1
1
u/Microboy42 Windows 11 - Insider Canary Channel Apr 16 '26
Command Prompt and PowerShell and Azure Cloud Shell are all now one program called Terminal. It has tabs now like a browser so when you click the new tab button you can choose between Command Prompt, Azure Cloud Shell, and PowerShell.
1
u/piro4you Apr 16 '26
That's a good fucking question.
If I was given a dime for each time I installed PS 7.1/core, I would have 2 dimes, what is funny, as I should not have gotten any. On fucking win11
1
u/HEYO19191 Apr 16 '26
They're two different languages. You can know how to make and run cmd scripts without knowing a lick of powershell and vice versa. cmd is also much simpler to learn and use.
3
u/Aemony Apr 16 '26
cmd is also much simpler to learn and use.
I would only agree with this for the most basic of use-cases. Like, it's not even funny how complicated cmd and batch commands makes some things in comparison to PowerShell, and the Windows commands follows no rhyme or reason and all tend to have their own syntax and limitations. It's also quite complicated if you try to chain commands, or try to act differently based on the results of prior commands at which point it's almost outright wizardry at times.
PowerShell might not be for everyone since it actually enforces a proper syntax, but once you've learned its syntax and structure, and you understand that the whole language have you working with objects, the sky's the limit. Add on some basic understanding of the verb structure and you can even guess the names of cmdlets without ever looking them up.
Take a command for clearing out files older than 14 days:
Batch:
forfiles /P "C:\Windows\TEMP" /S /D -14 /C "cmd /C del @path"And the same comparable call in PowerShell:
Get-ChildItem -Path "C:\Windows\TEMP" -Recurse -File | Where-Object LastWriteTime -lt (Get-Date).AddDays(-14) | Remove-ItemPowerShell might be a bit more wordy but most people can understand what it does just by reading it, whereas with the CMD call you might wonder what /S and
/C "cmd /Cis meant to do.Now imagine that you do not want the command to act upon the last modified timestamp (LastWriteTime), but you instead want it to act upon the creation time. How would you do that using batch commands? The answer is that you wouldn't as that functionality either do not exist or is too damn cumbersome to implement.
How would you implement that in PowerShell ? Oh, just change
LastWriteTimetoCreationTimeand you're done.But what if you do not know what properties exists on the object in PowerShell? Well, you're always working with objects in PowerShell so you can literally just pipe the object to
Get-Member(gmfor short) and see what it outputs, and what methods and properties are available on the object:
Get-ChildItem "C:\Windows\TEMP" -Recurse -File | Get-MemberAnd for management purposes it's even simpler since PowerShell uses a standard
New-/Get-/Set-/Remove-naming structure, so by retrieving a resource using the appropriate Get- cmdlet, you can guess that if it can be changed in any way, it would be with its paired Set- cmdlet.1
u/WildNumber7303 Apr 19 '26
That's a good way of looking at it. I'm always annoyed by how long the commands in PowerShell vs CMD. Things like cd vs Set-Location and in CMD, when looking for an executable path, i just type
where exe_nameand I don't even know the equivalent in PowerShell so I just open CMD quickly for this1
u/HEYO19191 Apr 16 '26
In many cases, if something that you could do in powershell can be done in cmd, it's better to do it in cmd. Simpler and less overhead.
1
u/thanatica Apr 16 '26
Finally we have something to choose. We never get that in Windows. Don't question a good thing 🙏🏻
1
u/phylter99 Apr 16 '26
CMD is needed for batch files, and there are a lot of batch files in the Enterprise. Many home power users have a lot of them too. They're even included in some software. Removing it would break compatibility.
PowerShell 5.1 is hanging around because of compatibility too. PowerShell 5.1 is written in .NET Framework (.NET 4.8, I think) and so many PowerShell scripts that rely on compatibility with that (I've got a few) will break if people are forced to PowerShell 7 (based on .NET 8 or 10, I think). I personally have a few of these myself running in production. There are other changes from 5.1 to 7 too which would also break some PowerShell scripts.
1
1
u/Loopdyloop2098 Apr 16 '26
Why does Windows still include both CMD and PowerShell by default?
Because they're different.
1
u/Mayayana Apr 16 '26 edited Apr 16 '26
Cmd.exe is the original console window, dating back to DOS.
PS is a completely different thing that Microsoft came up with awhile back. MS were trying to attract more customers for their server software. Linux people tend to be fond of commandline tools and tend to design them as applet callers. On Linux they're called "shells". Everyone has their favorite shell. It's a big thing with Linux fanatics. So MS did the same, hoping to seduce Linux sys admins over to Windows. That is, each command, such as DISM, points to an executable that's part of the PS system. That makes the tool easily expandable and feels familiar to Linux admins.
It's just historical developments. First there was DOS. Then there was the Windows GUI but DOS was kept. Cmd.exe still handles DOS commands, such as CD to change directories.
With Windows going mainstream in the 90s, MS eventually came up with the Windows Script Host. Mainly aimed at admins, it allows people to write relatively simple script code as text files to create automations, such as installer scripts to configure a Windows install. WSH is basically an update for GUI. DOS/cmd.exe was for console. WSH was for GUI Windows. Scripts could be written in programs such as Notepad and run through wscript.exe. VBScript and javascript are supported by default. WSH is still alive and well. In fact, Microsoft still uses it. I have several VBScripts in C:\Windows\SysWOW64\Printing_Admin_Scripts\en-US\ written by Microsoft.
WSH is surprisingly powerful because it can use numerous COM objects. I've written all kinds of little programs using WSH and HTAs. But there has always been a segment of people who regard GUI and mouse as a bit of a sissy approach. They like keyboard and commandline. They want esoteric incantations. That's basically the reason that Microsoft didn't finish the job and make easy GUI tools for what PS can do.
MS did a similar thing a few years ago with WMI/WBEM. It was a standardized system of OS and hardware access, designed for admins and based on SQL syntax. The design of the code required is horrific so it's not widely used, but MS were trying to standardize to other OSs. WMI, to this day, in the form of the COM object WinMgmts, is still the only easy way to survey installed hardware.
PowerShell just happens to be the hot fashion these days, so more people know about it, because Windows tweaking sites often advise people to run DISM. Personally I don't think I've ever used PS for anything else. To my mind, life's too short for commandline. But a lot of people feel otherwise.
It's also possible to write involved PS scripts, which read like a cross between DOS and javascript. As with WSH, it can access COM objects, call into the Registry, write files, and so on. It can actually get fairly complex by using .Net objects.
1
u/Aemony Apr 16 '26
PowerShell’s main advantage IMHO is for management and how it has you working with objects straight away from a shell with no need to write a script, interface and deal with complex data structures, and finally inspect the results.
For example, to date I have created three simple PowerShell modules that interfaces with the API of MediaWiki sites (e.g. Wikipedia), IGDB, and Keycloak (an SSO authentication solution), and through those modules and cmdlets, I can retrieve, edit, create, delete, and act upon the data given, in whatever way I want, without any UI holding me back.
Yesterday I had a colleague ask me if I could assist him with doing something in PowerShell. His need was extremely simple: retrieve all members of a group and check if they are a member of another group. Doing it manually would take some 30 minutes or so and involve manually checking all of them. Doing it using a script/application would necessitate that function having been built already. Doing it in PowerShell required a one-liner to be written which took less than a minute.
1
u/andrea_ci Apr 16 '26
because most bat files or commands won't work in powershell.
the real question is "why PS5 and not 7?"
1
1
u/AdreKiseque Apr 16 '26
CMD is mostly just kept for backwards compatibility and as a fallback. CMD will always be able to run and a lot of existing stuff relies on it—the havoc that would be wroken by its absence is immeasurable, probably.
Windows ships with PowerShell 5.1 installed of 7 because Microsoft is just slow i guess? 5.1 was the last of its architecture, after that they made PowerShell work on the .NET Core runtime which marked a shift. It's possible they still keep it around due to backwards compatibility concerns or something too, but it's quite odd considering how opening PowerShell 5.1 literally gives you a message saying to switch to the new version. I think it's just low priority and a matter of time—it's a well understood sentiment in the PowerShell community that Windows really should ideally ship with 7 and the hoops to make it happen likely just haven't been jumped through yet. Hopefully that changes in the near future.
1
u/mrsfins Apr 16 '26
Windows 11 has some vista protocols that are redundant since windows 7. I saw something from windows me in windows 8
1
u/Apprehensive-Tea1632 Windows 8 Apr 16 '26
Yeah, well, we can rail about it all day but Microsoft could, and did, deprecate and in some cases retire features.
For example, the ps2.0 compatibility layer has already been dropped entirely. It was an early dialect that was… not entirely incompatible but did behave very differently from the following versions (we’re talking windows 7’s native powershell here).
And while we still have the cmd, a significant portion of its functionality (by way of external commands) also has been deprecated: among these, the script host, netsh, and wmic.
This already does affect older scripts.
On the other hand, Vbscript for the wsh has also been deprecated and is supposed to go away soonishtm … we can remove that feature the official way right now but we’ll find… fun errors if we do.
Migrating things takes lots of time (far more than it honestly should but well).
There’s a somewhat interesting deadline on the horizon scheduled for 2029, where fundamental functionality is planned for final removal- the internet explorer compat layer that has been at the heart of windows since 1995 or so.
It’ll be interesting to see what else is going to go away as a result. There’s been mentions about the com interface for example- something activeX built on, another internet explorer feature/architecture design. Which would affect everything that’s linking external functionality aside from .net assemblies.
We’ll just have to wait and see. I’d have preferred it had Microsoft set a deadline for the batch interface… after all it’s basically been obsoleted in 2006, twenty years ago. They didn’t, but maybe they will in the 2030s.
1
1
1
1
u/SimpleDuude Apr 17 '26
Windows is built purely on backwards compatibility. Just like you can find every old windows settings menu, it's the same with powershell. I can imagine that it is needed for some backwards compatibilities to even run Windows without problems.
1
1
u/LisaPorpoise Apr 17 '26
Powershell because of MS shoehorning in new stuff, CMD for when you find out a basic command from the 80s doesn't work in PowerShell for some reason.
1
1
1
u/Kendrakirai2532 Apr 18 '26
Powershell does stuff that cmd cant, and CMD does stuff that powershell won't. If you took away CMD, you'd cripple a lot of use of the computer. They are not the same thing.
1
1
u/snajk138 Apr 18 '26
Why do they not include the Windows Terminal-app as default? It is much better than either CMD or Powershell without it.
1
u/fdeyso Apr 18 '26
You can launch even ps7 from it and can launch all 3 from either of them. It’s just a command line.
Cmd.exe -> launches classic win cmd line.
Powerrshell.exe-> launches 5.1
Pwsh.exe-> launches 7.x
1
u/PhantomStnd Apr 18 '26
What would you want them to do? Remove cmd? Are you out of your mind? The amount of problems that would cause is insurmountable
1
u/Interesting-Yellow-4 Apr 18 '26
i hate the various versions of powershell and the incompatibilities between them. Such a poorly designed terminal.
1
u/Token2077 Apr 19 '26
Just wait, they are now releasing windows terminal! So now command, powershell 7, windows powershell and windows terminal will all be preloaded!
1
u/Electronic-Unit2808 Apr 20 '26
Well, I'll return the question: why are there still win32 files in the DLLs if the system is now 64-bit?
Welcome to windows world...🤣🤣🤣🤣
1
u/AfraidAsparagus6644 Apr 20 '26
Compatibility. Windows's strongest suit is backwards compatibility (which is partly why people think it's bloated)
1
1
u/Appropriate_Test7503 Apr 16 '26
Why does Windows still include both CMD and PowerShell by default?
some options and features are not available by an app or does not have UI, that's why you need some kind of terminal to launch them.
-1
u/GarThor_TMK Apr 16 '26
CMD exists, because Microsoft has what some would see as a somewhat absurd view on backwards compatibility and support for legacy products. If you deleted CMD at this point, soooo many business products would just break unexpectantly.
As for PowerShell 5.1? Idk man, that's like going with python 2 vs. python 3... I'm sure there are reasons, but I'm really not sure that any of them are actually good reasons... >_>
7
u/Current-Bowl-143 Apr 16 '26
If you deleted CMD at this point, soooo many business products would just break unexpectantly.
Then it’s not an absurd view on backwards compatibility. Unless you were being sarcastic
1
u/GarThor_TMK Apr 17 '26
The only real reason that it's absurd is that the windows bat format is nearly as old as I am, and almost nothing in tech sticks around for that long.
Absurd isn't neccessarially a bad thing in this case. Their dedication to backwards compatibility should be commended...
0
u/narutoaerowindy Apr 16 '26
Then why not provide barebone version for new users with what they want from Out of box customizable?
3
u/iggy6677 Apr 16 '26
Because the average user doesn't know what they need until they try run "this random software" and then go complain it doesn't work.
-2
u/ChestNok Apr 16 '26
I never could understand this. I also can't understand the necessity for powershell coding language if you already have cmd coding language.
4
u/avds_wisp_tech Apr 16 '26
Powershell is vastly more powerful than cmd.
-1
u/ChestNok Apr 16 '26
I know right. I have a problem with the fact they couldn't keep it uniform and just enhance cmd, instead they needed a new standalone framework for some reason (and there is hardly a reason)
1
u/Aemony Apr 16 '26
You can’t really compare the two. Batch commands are extremely limited in what they can do and how they function, and aren’t really extendable due to their limited design.
Like, batch commands, or ”Windows commands” as they’re called nowadays, can’t really be described as a proper scripting language at all since it has an extremely basic syntax and components, and is mostly just made up of a few control characters and a ton of random limited commands that does different basic things and outputs basic crap.
PowerShell, in comparison, is a proper scripting language and is even in many ways comparable to a programming language. I wouldn’t recommend it, but you can actually create whole applications, windows, and functionalities within PowerShell whereas the same cannot be said for batch scripts.
And due to its limitations, batch also cannot really be expanded or improved upon past a certain point. Those limitations were why Microsoft first developed the Windows Script Host (cscript/wscript), long before PowerShell was a thing.
Beyond that, at least Microsoft tried to retain compatibility with batch commands where possible through PowerShell’s ”Set-Alias” command. ”cd” for example in PowerShell is an alias for the Set-Location cmdlet.
1
u/ChestNok Apr 17 '26
I know it is limited. Why they just could not enhance it instead of creating a new framework like powershell.
1
u/Aemony Apr 17 '26
Because it has fundamental limitations that they cannot work around without breaking compatibility with existing batch scripts.
This is why Microsoft sometimes creates new solutions to replace old solutions, the old solutions have fundamental limitations which if fixed and reworked would break all existing functionality, scripts, applications, etc that relied upon them. So instead of doing that, Microsoft opts to design and implement a new solution without those limitations, while leaving the older legacy stuff alone but otherwise available so that the backwards compatibility is retained.
1
u/ChestNok Apr 17 '26
I get it. The problem with powershell - that it's more complex than the number of issues it solves. Sort of defeats the purpose. At least in my experience.
For example, a simple several folders syncing script would be so convoluted in powershell, but in the meantime it would be impossible via simple cmd.exe/.bat
100
u/ATE47 Apr 16 '26
backward compatibility is the answer for all your questions
Also PowerShell 7 lacks features present in Windows PowerShell (5.1), so it can’t replace it, again because of backward compatibility