comp.os.msdos.4dos

Long-form reference · 1,779 words · about a 8-minute read

The group and its era

comp.os.msdos.4dos sat in the comp.os.msdos.* hierarchy alongside broader neighbours such as comp.os.msdos.apps, comp.os.msdos.programmer and comp.os.msdos.misc, and was in place by the early 1990s. The Big Eight held few groups devoted to a single commercial product — comp.os.msdos.desqview was a neighbour in the same position — and the naming says something: enough people had adopted this particular shell that a general DOS group could no longer comfortably hold them.

4DOS itself, written by Rex C. Conn and Tom Rawson and first released in 1989, spread the way shareware then spread: bulletin boards, disk vendors, the online services, and word of mouth. The newsgroup filled accordingly with the people that mode of distribution selects for — the sort who read the documentation and then push past it.

The group's active life tracked DOS's own long tail. Through the early 1990s it served users for whom the command line simply was the operating system; after Windows 95 it increasingly served those keeping serious work running in DOS sessions, batch files and all, long after the marketing had moved elsewhere.

Under DOS the command processor was not one tool among many but the working environment: it drew the prompt, ran the batch files that automated everything, and stayed resident while other programs ran. COMMAND.COM was deliberately small, and it was replaceable — the SHELL directive in CONFIG.SYS named the processor DOS should load, and nothing in the design required that processor to be Microsoft's. 4DOS took the opening, and this group existed because a replaceable component had acquired a constituency.

JP Software and the release lineage

The publisher was JP Software, and the product was distributed as shareware before being released, years later, as unsupported freeware. The first release was numbered 2.00 and dated 15 February 1989, and the shape of the thing was already settled: improved command-line editing with filename completion, a command history, aliases, improved wildcards, online help, internal variables, swapping to disk or expanded memory, and file descriptions. What followed was a decade and a half of accretion rather than reinvention.

• 3.00, March 1990 — .BTM batch files cached to memory for speed, swapping to extended memory, variable functions, bracketed variable-name syntax.
• 4.00, November 1991 — coloured directory listings, the 4DOS.INI configuration file, include lists, command groups, and support for the upper memory blocks DOS 5 had just made available.
• 5.00, November 1993 — date, time and size ranges, and compressed batch files. 5.51, August 1995, added long filename support and REXX in .BAT files, as PC DOS 7.0 had.
• 6.00, July 1997 — extended directory searches, exclusion ranges, interactive configuration through the OPTION command, and an interactive debugger for batch files.
• 7.00, June 2001 — @file lists, after the fashion of DR-DOS. 7.50, February 2003, added user-defined functions.

The family spread with the platforms. 4OS2 did the same work for OS/2 from the early 1990s; the Windows NT product began life as 4DOS for Windows NT before settling on the name 4NT, and since it was a recompilation of the OS/2 code it kept OS/2 habits its users noticed, among them REXX scripting and EXTPROC support. A graphical line called Take Command ran alongside the text-mode shells, its first releases matching 4DOS 5.5, 4OS2 2.52 and 4NT 2.5, with a Take Command/16 for Windows 3.1. JP Software's last update to 4DOS itself was version 7.50.130, in August 2004.

What it did that COMMAND.COM did not

The specifics are worth stating plainly, because the group's traffic assumed all of them. Set against the interpreter DOS supplied, 4DOS offered:

• Command-line editing with filename completion, and a command history that could be recalled and edited rather than retyped.
• Aliases, usable inside batch files as well as at the prompt.
• An extended batch language: .BTM files read into memory instead of re-read from disk a line at a time, internal variables, variable functions, and from 7.50 user-defined functions of one's own.
• Directory listings in colour.
• Enhanced wildcards, with selection by file size, by date and time stamp and by other file characteristics, and exclusion ranges for leaving files out.
• Extended syntax for redirection and piping, and context-specific help.
• A swapping mechanism that kept the shell out of conventional memory — the difference between a program running and not running, when 640 KB was the ceiling.
• Configuration held in an INI file, and an interactive batch-file debugger from version 6.00.

The most durable of the additions was the file description. From 1989 the shell could attach a line of free text to any file, held not in the directory entry — DOS had nowhere to put it — but in a plain-text DESCRIPT.ION file in the same directory, created, maintained and displayed by the shell's own commands. It was file metadata for a filesystem that had none, and it outlived its origin: later file managers, Total Commander among them, read and wrote the same file, and third-party utilities used reserved leading bytes inside its entries to carry structured key-value attributes of their own.

What was discussed

The staple was batch programming. The extended language — .BTM batch-to-memory files, internal variable functions, expression evaluation, aliases layered on aliases — invited a characteristic kind of thread: someone states a task that plain COMMAND.COM batch files handle badly or not at all, and the replies converge on progressively tighter solutions. Regulars traded techniques for parsing, arithmetic, screen handling and conditional logic that stretched a batch language considerably further than its ancestors were ever meant to go.

Configuration and coexistence questions supplied much of the remaining steady traffic: tuning 4DOS.INI, keeping the shell's memory footprint down through swapping and upper-memory loading, installing it as the primary shell from CONFIG.SYS, and persuading it to live peaceably in Windows DOS boxes or under DESQview. A perennial sub-genre concerned software that assumed COMMAND.COM was the only command processor in the world, and what to do when that assumption failed.

New releases and public betas were announced and picked over in the group, and questions about the sibling products — 4OS2 for OS/2, later 4NT — landed there too, since the family shared a design and, largely, a user base. Users of NDOS, the Symantec-licensed variant, likewise turned up with questions their Norton manuals did not answer.

Context

That NDOS licensing is the era's clearest measure of 4DOS's standing: Symantec shipped a lightly reworked 4DOS inside Norton Utilities for DOS under its own name, putting a niche shareware shell in front of a mainstream audience. The last NDOS shipped with Norton Utilities 8 in 1994, and its users often found their way to this group when the bundled version fell behind the original.

4DOS belonged to a market that has since disappeared with its premise: the business of selling improvements to an operating system that shipped without them. Quarterdeck Office Systems, founded in 1981, sold both QEMM, the most widely used third-party memory manager for DOS, and DESQview, which multitasked DOS programs; Central Point Software had been selling the PC Tools suite since 1985; Norton Utilities was the other suite everybody had heard of. All of them competed for the same scarce resources — the memory below 640 KB, and the user's willingness to load one more resident program at boot — which is why so much support traffic of the period, in this group and its neighbours, was about persuading such products to coexist.

JP Software ran support channels of its own throughout — on the commercial online services in the shareware years, later on forums hosted on its own servers — and these came and went as platforms do. The newsgroup was the venue that belonged to nobody: carried by every full news feed, readable in any newsreader, archived independently of the vendor, and reachable through news-to-mail gateways such as the one this site operated. When later company-run forums adopted software that could not usefully be read or answered by mail, that difference stopped being academic.

JP Software issued its last 4DOS update in 2004 and released the program as freeware, with source code subsequently made available, on which enthusiasts built a community-maintained continuation. The group's traffic thinned as DOS receded and support migrated to the company's own venues, but the archive remains a working manual for a shell that is still, thanks to that release, perfectly runnable.

After DOS

The company's attention followed the platform. 4NT was renamed Take Command Console, or TCC, with version 9 of the Take Command package, and it is that Windows line, rather than anything with DOS in its name, that JP Software still sells and maintains; a feature-reduced TCC/LE was issued as a free download. The OS/2 side was handed on instead of retired: the 4OS2 code was released, maintained afterwards first by SciTech and then by NetLabs, and it ships with ArcaOS.

4DOS's own source appeared in November 2006, as version 7.50.1, under a modified MIT licence carrying two conditions that keep it outside open source as the Open Source Initiative and the Free Software Foundation define the term: it may not be used in a commercial product without written permission from Rex C. Conn, and it may not be compiled for any operating system other than FreeDOS. Development nevertheless continued in other hands — Luchezar Georgiev and Jaelani Utomo took up the code, version 8.00 followed in February 2009, and an unofficial support site at 4dos.info remains in place.

That is roughly why an address like this one still turns up as a citation on technical reference sites. The manuals and the help files record what the shell was meant to do; the newsgroup is where its users established what it actually did — how it behaved with particular DOS versions, memory managers and multitaskers, where the batch language's edges were, what to do about programs that would only speak to COMMAND.COM. That account was written by the people who hit the problems, was never edited back into a manual, and is not reproduced anywhere else.