Welcome, stranger: Inside Microsoft's command line shell

"+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..

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.

"+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...

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.

'I was a Norton Utilities man myself'

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

QEMM and Quarterdeck

Those are names that bring back somewhat fond memories :)

And the Borland C compiler

"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.

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.

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)

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

> 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.