back to article Welcome, stranger: Inside Microsoft's command line shell

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 …

This post has been deleted by its author

Silver badge

And then you discovered 4DOS. Which was damn amazing. And the 4DOS tools worked on any DOS you put them on, too.

But, for years, my computer's scripting - every line from booting to loading drivers to starting games - was a combination of batch files, PC Pro / PC Magazine command-line utilities, and simple freeware.

STRINGS, CHOICE, AMENU, it's all coming flooding back.

Those were the days. When the computer did what you told it to and no more. And if you wanted, you could get 638Kb of base RAM out of 640Kb with enough drivers to play game X or run app X and just stick it in a menu. And a reboot took seconds and pushed you into a nice menu that loaded up the exact configuration you needed for a program, and you never even saw the jiggery-pokery to make it all work but you could at any point.

Can''t even squeeze a webpage into 640Kb now. Still have no control over what starts up or in what order when you start Windows and half the stuff you can't turn off without breaking completely unrelated features (did you know that if you stop the Window Search service, you can't then add a new keyboard language?).

Never used a batch file compiler because - well, you never needed to. A 386 was more than capable of churning through a batch file in no time at all.

34
1
Silver badge
Thumb Up

I used to write entire application installers with the PowerBatch compiler.

2
0
(Written by Reg staff)

+1 for 4DOS. It was the first thing to install on a new box.

9
0

"+1 for 4DOS. It was the first thing to install on a new box."

I liked DR DOS, twas far superior to MS Dos.

I used to do a lot of command line stuff on an NT DEC Alpha. For various reasons I ran an 86 emulator to shut down 64 Progress databases and back the buggers up.All done through the auspices of a little batch file.

NT4 on the DEC Alpha was far superior to all the other OS's I had ranging from NT4 86 to Citrix Winframes and VAX..

7
2

I was an SDIR and Norton Utilities man myself, but yes you could do a heck of a lot back in those days. We were using QEMM and Quarterdeck for our memory manipulations. And of course every time MS released a DOS update, they broke.

3
0

4NT for the win

It still is.

It's called Take Command, now, and it's an all-singing, all-dancing command process as well as a terminal on steroids (think of xterm in terms of functions).

The command processor can run separately; it's called TCC (Take Control Console), and there's a freeware dumbed down version (still orders of magnitude above the Command Shell) called TCC/LE. You can get it at JP Software, and it's strongly recommended.

I've played with PowerShell, but I still find I can knock out a TCC/4NT/Take Command shell script in a tenth of the time, and it does a hell of a lot more, and easier, than the PowerShell script.

2
1

I liked DR DOS too, but you can't really compare it to 4DOS, they were different things. And yes, I have run 4DOS on DRDOS (4DOS v3 on DRDOS v6, I believe, around 1991).

The only real problems I had with DRDOS were that (1) it wouldn't run Windows reliably (no great shock), (2) there was some funny bug that caused the internal "xdir" command to crash the PC occasionally for a reason I could never determine, and (3) it had problems running in a DOS box under OS/2, and *really* didn't like HPFS partitions. But as a standalone DOS replacement, it was great.

1
0

"+1 for 4DOS. It was the first thing to install on a new box."

What is this 'install' thing? Do you mean put the 5andaquarter in?

Assuming you haven't sat on it and bent it...

3
0

'I was a Norton Utilities man myself'

They licensed 4DOS for NU 7 and NU 8 and called it NDOS.

0
0

Windows under DR DOS?

I didn't have problems with windows under DR DOS 6, but then the last versions of DR DOS were overshadowed by DOS (er) 5 (?) that actually had some advanced features.

I ran DESQview for a while. Worked great, but wow the strange things we did to juggle processes.

1
0
Silver badge

QEMM and Quarterdeck

Those are names that bring back somewhat fond memories :)

And the Borland C compiler

5
0
Silver badge

Re: Windows under DR DOS?

> I didn't have problems with windows under DR DOS 6, but then the last versions of DR DOS were overshadowed by DOS (er) 5 (?) that actually had some advanced features.

DR-DOS 3.4x supported large disk partitions when MS-DOS was stuck with 32Mbyte per partition (some OEMS (Wyse, Compaq,..) also had large partition support).

DR-DOS 5 offered EMS and HiMem and many utilities and was contemporaneous with MS-DOS 4.01. 20 months later MS caught up with MS-DOS 5. Then DR-DOS 6 added task switching and better memory management which took the best part of a year to almost catch up with MS-DOS 6. In the meantime MS contracted its OEMs with illegal 'per box pricing' so that users had to pay for MS-DOS even if they bought DR-DOS.

DR-DOS 7 (later Novell-DOS 7) added real multi-tasking as well as task switching.

The other feature that DR-DOS had is that it would _run_ from ROM and not just load. This made embedded systems much faster and more secure.

I don't know what you thought that MS-DOS had that was 'advanced', it was always behind.

3
2
Anonymous Coward

"PowerShell was also unofficially touted as "the Linux version of the command line"

Nope - it's far more powerful than Bash, etc.

2
8

Oh yes.... CMD.EXE /C

For many years, I did almost everything I needed with DOS (2.0 to NTDos) from building and maintaining uniform directory and permission structures for file systems to piloting remote desktop installations and operations with other CLI tools like psexec. I loved and hated it, really.

DOS had many flaws, shortcomings and weaknesses (still does). It is not even comparable to the power of mature *nix command shells, like BASH. However, it was very often good enough for the job, particularly when used in conjunction with other command line programs.

Today's IT youngsters (most of whom are morbidly ignorant of the CLI) don't know what joys and frustation they have missed. I'm not sure that is altogether a good thing.

As a colleague of my generation once said, "they don't remember how easy it was to completely f*k up a system with a few keystrokes" and the discipline that encouraged.

1
1
Silver badge

Re: Windows under DR DOS?

"I ran DESQview for a while. Worked great, but wow the strange things we did to juggle processes."

I used DESQview/X to run a multiline BBS. Multitasking on a 286, etc. Those were the days (no I don't want to relive 'em)

1
0
Anonymous Coward

Re: Oh yes.... CMD.EXE /C

Be assured, it is still plenty easy to fuck up a system with a few keystrokes....

0
0
Silver badge
Happy

Re: 4NT for the win

Just think about how much better the world would be if IBM based the PC on the Motorola 68000 instead of the Intel x86.

1
1

I remember setting up many machines with a basic toolbox of programs like 4DOS (and later 4NT), grep, PKZIP etc before I moved on to just using cygwin.

I think everybody in IT from the 80s and 90s who used DOS/Windows would have a collection of tools to extend and make MSDOS/CMD actually useful.

Thing I never understood about MS, was the apparent 'not invented here' approach to releasing better tools. They could surely have brought the rights to bundle tools like 4DOS into Windows and quickly improved the rudimentary command line.

Some bundled Windows utilities like Notepad don't seem to have changed much since Windows 3.11 days, despite Microsoft having better free editors available in-house.

0
0
Silver badge
Boffin

Piping is the next powerful ability of PowerShell. Piping uses the pipe symbol | to split commands and feed the latter to the former. So get-childitem | where name -notlike Windows would show you the directory listing, but excluding anything that matches the name Windows. You can't do that with a single command prompt line.

Yes you can. The MSDOS command shell supported piping. Try this:

dir c:\*.* /s | more

That's not what the example asks about but it does demonstrating that piping commands was available in MSDOS and had been since 3.x - maybe earlier for all I know. I don't think there there was a built-in command you could pipe to that excluded by name but it wouldn't have been difficult to write one.

14
4
Silver badge

"piping commands was available in MSDOS and had been since 3.x"

Except you could only pipe into certain commands and IIRC you could only pipe once - you couldn't daisy chain them. MS never really "got" the purpose of stdin, stdout & stderr. They still don't as far as I can see.

13
11
Silver badge
Happy

Except you could only pipe into certain commands

Well..yes. Piping only worked with programs that had been written to use stdin/stdout. It's unfortunate that for performance reasons a lot of command line programs chose to perform direct I/O rather than going that route but I'm not sure you can call that a limitation of MSDOS. MSDOS piping works with any application that sticks to the MDSOS API.

IIRC you could only pipe once - you couldn't daisy chain them

dir | sort | more

:)

21
1
Silver badge

PowerShell commands output structured data, not text. In the absence of a consumer, the data is converted to text, but if you pipe it, then the consumer receives objects. In the example in the article, the "where" command filters its input objects by examining their "name" attribute.

If you've ever had to write a lot of shell-script on Linux, I'm sure you'll appreciate how useful this could be.. especially as many really useful Linux tools provide such machine-unfriendly output.

14
2
Anonymous Coward

MSDOS piping would just write the entire output to a temporary file, the same as:

dir c:\*.* /s >tmpfile

more <tmpfile

The second command wouldn't start processing until the first had finished.

Microsoft didn't really "get" the idea of pipes or concurrency.

11
6
Silver badge

Actually, that isn't a pipe.

What it did was create a tmp file with the output of the first command, which was then read by the second command.

4
1
Silver badge

"dir c:\*.* /s | more

That's not what the example asks about"

But

dir | find /V "Windows"

would do pretty much the same at the DOS prompt as get-childitem | where name -notlike Windows (abeit with the output formatted slightly differently).

7
0

Actually, that one would fail, as all directory listings were uppercased, so you wouldn't get any files listed.

One very hand piped command I used to use a lot:

CHKDSK /V | FIND "textstring"

CHKDSK /V all by itself would give you a scrolling list of every file on the disk. Piping that output to the FIND command would result in a list of only the files where textstring matched. A 'file find' program built in to DOS, and it was free.

4
0
Silver badge
Happy

Microsoft didn't really "get" the idea of pipes or concurrency.

Ah now, that I agree with. Sorta. Except that MSDOS was never claimed to be a multi-tasking operating system so it's a bit harsh to criticise it for the workaround of using a temporary file. Clearly Microsoft were aware of the importance of piping and went to some lengths in order to fake it.

As for not supporting objects - well yes that's true but the article didn't use objects for that example. It quite specifically mentioned directory listings. As another commentard with more time on his hands (or a better memory) has pointed out that there was such a filtering program available so the specific example given in the article is entirely possible under MSDOS.

And a note to the downvoters - I'm not attacking PS here. I know it's better and I love it - have interfaced to it from C# on several occasions. The only reason I've posted these comments is to point out a factual inaccuracy in the article.

6
0
Anonymous Coward

DOS was a single process, single thread operating system...

4
0
Anonymous Coward

From the article:> get-childitem | where name -notlike Windows

I've not used powershell a lot but the article's command "get-childitem | where name -notlike Windows" didn't work on this Windows 7 'box'.

dir | find /v "Windows" which is case sensitive does work, and is one command.

dir | find /v /i "Windows" is the case insensitive version.

3
0
Silver badge

PowerShell commands output structured data, not text. In the absence of a consumer, the data is converted to text, but if you pipe it, then the consumer receives objects. In the example in the article, the "where" command filters its input objects by examining their "name" attribute
Ah, I was wondering when this would start appearing. I could smell XML inter-proc pipes a while back. I remeber an XML 'ls' somewhere, with the output terminal taking cues. Next up, p2p negotiation, maybe ending up with JIT compilation... mm.. evil..

1
3
Silver badge
Childcatcher

Microsoft didn't really "get" the idea

The only reason I've posted these comments is to point out a factual inaccuracy in the article.

And there are others... I get the impression the author doesn't use Windows command line much except for PowerShell, if that. Too, there were other MS scripting possibilities not mentioned in the article (e.g. cscript/wscript, VBScript, JScript). I've had the... joy? of working with one incarnation of MS-DOS AKA CMD or another for 30 years now. While I think that it PowerShell is interesting in the way it does things and am pleased with the return to using command line as the default in MS OS administration, I find the change from CMD to PS as jarring as moving from anything else to Windows 8. I've written scripts to be run on a variety of *NIXes and am having a harder time shifting to PS than learning any of these from scratch. Maybe I have just gone from getting to being old.

PS has a few neat tricks like being able to specify output types that are native to MS Office formats, but I have been able to do that more generically using CSV and RTF for years. Except for things that were designed and created with PS as the default scripting language, I haven't run into anything that I couldn't do previously with CMD.

Essentially, MS has done to admins what they have been doing to all their other users: changing everything, telling us it is for our own good, and forcing us to relearn things that we have been able to do just fine for years. Not much of a production boost as far as I can see, but it is the Microsoft way.

16
3

Re: From the article:> get-childitem | where name -notlike Windows

This is true.

get-childitem | where {$_.name -NotLike "Windows"}

is what you want here.

3
0
Anonymous Coward

Easier than ever nowadays

Oy intern,

sort this out will ya

0
1

This post has been deleted by its author

Pipes

After MS-DOS 1, Microsoft promised proper pipes and multitasking, then delivered MS-DOS 2 with the 'make the first program finish before letting the second one see the results' bodge that lasted for the rest of MS-DOS.

2
0
Silver badge

Re: Microsoft didn't really "get" the idea

> changing everything, telling us it is for our own good,

If MS didn't change stuff then there would be no reason to buy the next version.

1
1
Vic
Silver badge

Except you could only pipe into certain commands and IIRC you could only pipe once - you couldn't daisy chain them

In days of yore, piping worked perfectly. You could pipe anything into anything, and use as many pipes as you wanted to. It worked.

Then they brought in long filename support, including spaces in filenames. This inherently broke the pipe system, leading to the situation you describe.

But prior to that, it was all good...

Vic.

3
0
Vic
Silver badge

Except that MSDOS was never claimed to be a multi-tasking operating system

But it *nearly* was.

The original design had all task-context data in a swappable chunk - the SDA. By changing the SDA pointer, you changed the context. There was some grief with changing that whilst certain non-thread-safe DOS operations wre ongoing - hence the InDOS flag - but it had clearly been built with multi-tasking in mind.

Sadly, this doesn't ever seem to have been completed (hence the single-tasking nature of what shipped), and each new version seemed to have more and more static data that wasn't in the SDA, leading to lots of work-arounds and side-effects :-(

Vic.

1
0
Silver badge

If I recall correctly, Unix specifications at the time did not require that pipes be implemented in any particular way, and the Microsoft way would have been suitable, although less than ideal. What really counted, though, was that the operating system provided for such things, and pretty much the entire set of standard utilities used stdin and stdout and allowed the shell to connect them fairly arbitrarily using pipes.

2
0
Bronze badge

Re: Pipes

For those too young to remember, I'd just like to clarify that you could "see the results before the first one finished". That was not the problem.

The problem was that MS-DOS would only run one program at a time. The "second one" wouldn't start until the 'first one' finished, even though "the results" were ready and available.

And yes, it was possible to work around this limitation of programs run by DOS, but it was a work-around, not a natural part of the system.

Just like (while I'm here), DOS 3.x did support "partitions larger than 32 MB", through resident driver chaining, and from DOS 2.x supported large disks through installable block devices drivers.

Unlike the native support for command line editing and recall, using the Fn keys, which was a natural part of the system, not some little-remembered work-around

3
0

Re: From the article:> get-childitem | where name -notlike Windows

Just tested again on a Windows 7 box from the standard Windows PowerShell window, and it works for me:

get-childitem | where name -notlike Windows

What error are you seeing when trying? PowerShell is pretty good at telling you what's wrong.

2
0
Silver badge

Re: Pipes

> Just like (while I'm here), DOS 3.x did support "partitions larger than 32 MB", through resident driver chaining, and from DOS 2.x supported large disks through installable block devices drivers.

Not from Microsoft it didn't. There were 3rd party add-ons. Some OEMs modified the system, in different ways, to support larger partitions, for example I used 'Wyse-DOS' 3.31 with this. IBM was annoyed that other OEMs had features that were not in PC-DOS (or standard MS-DOS) so they wrote code to create PC-DOS 4.0 and gave it back to MS for MS-DOS 4.0x

http://www.os2museum.com/wp/dos/dos-4-0/

"""Perhaps the most significant change in DOS 4.0 was the introduction of 32-bit logical sector numbers and the consequent breaking of the 32MB partition size barrier. That change wasn’t strictly speaking new, having been first introduced in Compaq’s DOS 3.31 in late 1987. However, beginning with DOS 4.0, every OEM version (starting with IBM’s) supported large partitions."""

0
1
Silver badge

> Unix specifications at the time did not require that pipes be implemented in any particular way, and the Microsoft way would have been suitable, although less than ideal.

Named pipes are a feature of the Unix (and Unix like) operating systems. They provide arbitrary data connections between programs. It happens that various shells can use pipes to connect stdout of one program to stdin of another. MS-DOS doesn't have pipes but the shell can provide an emulation in some cases.

0
1

How is "dir c:\*.* /s | more" the same as "So get-childitem | where name -notlike Windows" - yours will stop at each page waiting for a keypress, mine lists everything excluding the directory name 'Windows' ?

0
2

You're right - well done!

0
0
Silver badge
Thumb Up

hence the InDOS flag

Wow, I just got that lovely 'plink' from my brain as you unlocked another chunk of memory. Thank you, sir for reviving an old memory. Have an upvote :)

0
0
Silver badge

DOS

Um, no. DOS was an interrupt-driven bootstrap loader.

As soon as any program ended, the system had to reload command.com (and if it wasn't there, things would break)

0
0
Silver badge

"Then they brought in long filename support, including spaces in filenames. This inherently broke the pipe system"

As with *nix, enclosing the filename in speechmarks solves that issue.

1
0
Silver badge

Re: Pipes

"IBM was annoyed that other OEMs had features that were not in PC-DOS (or standard MS-DOS) so they wrote code to create PC-DOS 4.0 and gave it back to MS for MS-DOS 4.0x "

The legend is that MS said "DOS is done", fully baked, no more work needed, etc.

IBM added the extra stuff as proof of concept and MS immediately took it(*) to sell as DOS 4.0 - which was unfortunate, as it was bug-riddled. A lot of early adopters lost the entire content of their systems.

(*) The licensing conditions for DOS included a clause that any modifications were the property of Microsoft. This wasn't unusual - Rockwell included the same clauses in its modem chip licensing,

Thankfully at least one machine I owned (Sanyo MBC550) wouldn't run anything newer than DOS 2.11, so I was spared that carnage until well after the event.

0
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2018