Series Note: This is Part 1 of a two-part series on Windows command-line architecture. Read Part 2: Python vs. Native Shells: Is the Overhead Worth It?
Is CMD still valid in 2026?
In our daily interactions with Windows, we have all faced the need to install a specific software package or figure out why our network connection is suddenly lost. Since the 1990s, Microsoft has offered a reliable tool to help us troubleshoot these exact issues: the Command Prompt, or simply CMD.
For generations of users, this core list of commands has become the standard troubleshooting routine:
cd: To change your current folder scope.dir: To list the files inside a specific directory.ping: To test server reachability.ipconfig: To verify local network configurations.netstat: To inspect active network connections.
For basic tasks, CMD offers enough power to get straight to the point, but beneath this familiar interface lies a critical architectural limitation.
Don’t forget the “Run as Administrator” Barrier
Before looking at what CMD can do, remember that right-clicking CMD and choosing “Run as Administrator” opens a prompt that looks identical, but holds a completely different power.
It bypasses standard file protections allowing the program to modify critical system files, install software, or change hardware settings that regular users cannot touch.
The Text Wall Limitation: Where CMD Breaks Down
CMD is an older, text-based environment, so, natively, it cannot interact with modern document structures. It can open Excel, for example, but it can’t open it to further scan, filter and process the data inside based on certain parameters. Well, unless it calls another program to achieve this. Alternatively, the excel file would first have to be manually exported to a .csv format, and then write a multi-line loop to scrape the words. Anyway, CMD has reached its limits.
Let’s say you have a list with user names and passwords and need to add them as Windows users.
Obviously, I could go into Computer Management > Local Users and Groups > Users, right-click and Add User. But if the list is long, the process is tedious. With CMD and having the users list is in users.txt, an automation is possible
user01,passwordx01
user02,passwordx02
user03,passwordx03
C:\>FOR /F "tokens=1,2 delims=," %A IN (C:\YourPathToFile\users.txt) DO net user %A %B /add
where YourPathToFile is the path to the folder that contains your file.
*FOR /F* : Tells CMD to loop through the contents of a file line by line.
*”tokens=1,2 delims=,”* : Tells the CMD shell to split each line when it sees a comme (,). It treats the first part as token 1 and the second part as token 2.
*%A* : This is the variable assigned to the first token. So, first username is assigned to %A and the password is assigned to the next letter in the alphabet, %B. If the CSV file had three columns, say username, password and email, the third token would be assigned to %C.
*IN (C:\YourPathToFile\users.txt)* : It is the source date file
*DO net user %A %B /add* : This is the actual command to add one user and its password.
This works well as long as your user list is in txt or csv type. But if you receive data in excel or JSON format, a frequent real-world scenario, What options do you have?
This is where Powershell comes to help.
PowerShell to the Rescue: Thinking in Objects
For this reason, starting in 2006, Microsoft presented PowerShell. It is basically CMD on steroids. The limitation presented before can be easily solved with just a few short command lines:
$users = Import-Csv "users.csv"
foreach ($user in $users) {
# Convert the plain text password into a secure string object first
$SecurePassword = ConvertTo-SecureString $user.Password -AsPlainText -Force
# Then, pass the secure string variable cleanly to the parameter
New-LocalUser -Name $user.Username -Password $SecurePassword
}
You can argue that Powershell looks more complex but it is doing much more than the CMD line of code. The simplicity is just an illusion. It actually does much less.
PowerShell considers elements as Objects rather than flat text strings. Here is what is actually happening line-by-line under the hood:
Import-Csv: Instead of parsing text line-by-line with cryptic delimiters, PowerShell reads the file and instantly maps the column headers (Username, Password) as data properties you can call by name.
foreach ($user in $users): This reads like plain English: “For every individual user inside my users collection, execute the following steps.” There are no confusing %A or %B tokens to track.
ConvertTo-SecureString: This is the critical security difference. CMD passes your corporate passwords completely naked across system memory. PowerShell refuses to allow this vulnerability. It mandates that passwords must be heavily encrypted in your system memory ($SecurePassword) before they can ever be passed to an account creation command.
New-LocalUser: This invokes the native Windows engine to cleanly build the account, assigning the right data property to the right flag safely.
The Final Verdict: Choosing the Right Tool for the Job
CMD is simpler to type for a basic task. But PowerShell is built for the real world. Its structured complexity isn’t a disadvantage; it provides the guardrails that keep enterprise automation secure, readable, and error-proof.
PowerShell is undeniably the most powerful automation tool living inside Windows. But what happens when your automation needs to cross over to Linux environments, or leverage heavy data science libraries? In our next article, we will solve these exact same challenges using Python—exploring its massive cross-platform power alongside the dependencies it introduces.