Welcome, stranger: Inside Microsoft's command line shell
A walk through the back office, from MS-DOS to PowerShell
PowerShell is everywhere, it seems. Not just in Windows Server, SharePoint, SQL Server, Exchange, Lync and Azure cloud, but it’s in third-party software, too. Take VMWare PowerCLI – that’s an extension of PowerShell.
With many in the Windows world chewing on this fat PowerShell server software sandwich it’s easy to take Microsoft’s command-line shell for granted.
But it wasn't until Exchange 2007 that anyone building or administering the platform needed to start using PowerShell. This was Microsoft's first really big push towards the shell and it met a lot of resistance – mainly from those used to being able to use the GUI for almost any task.
It wasn’t like the GUI had been established for terribly long, either. Before PCs had Graphical User Interfaces (GUIs) and mice, the Microsoft Disk Operating System (MS-DOS) prompt was the starting point of doing anything on that beige-boat anchor.
Back in 1981, Microsoft bought 86-DOS for the measly sum of $75,000 (roughly $193,000 by today's standards) and stuck the “MS” badge on it. 86-DOS was a port of another command line operating system known as CP/M – and that was somewhat influenced by the TOPS-10 operating system which has a history way beyond what we can cover in this article.
After making many licensing deals and publishing under a myriad of different names, MS-DOS became the de facto operating system for the 8086 Intel architecture. For many, this is how the humble PC was introduced into the home for the first time.
Other nostalgia aside (such as spending hours mucking about with CONFIG.SYS and AUTOEXEC.BAT to get the most memory available at start-up), the MS-DOS command line wasn't particularly intuitive. Starting with a simple prompt and a flashing underscore, your only option was to work out what you needed to type in to make use of the machine.
Commands and paths had to be typed in full in the MS-DOS days, there was no fancy time-saving command-line auto completion. This feature popped up much later in the picture, when the command prompt had almost become a forgotten artifact of the pre-GUI era.
There were two types of commands for MS-DOS, ones built into the shell (such as help), or command-line programs, such as diskpart, that were based on an executable.
There was little notable difference, with the biggest catch being your paths had to be set correctly to make sure MS-DOS would look in the folder that contained your executable – otherwise you’d see the commonly seen “Bad command or file name” message.
MS-DOS was lacking other features, too, that many would now consider unforgivable. After typing out an incredibly long command and realising there was an extra letter at the very beginning, all you'd end up with was an unusable chunk of text. The ability to edit text on a command prompt was something dreams were made of, so the best you could do was backspace and delete up to the mistake.
Sponsored: Becoming a Pragmatic Security Leader