comp.os.msdos.4dos

Long-form reference · 7,947 words · about a 35-minute read

A Big-8 name that never went to a vote

The Big Eight hierarchies were built out of subjects. Their names describe fields, machines, languages and pastimes, and a name taken from something a company sold was not forbidden: comp.os.msdos.* alone acquired several, and each of them was voted through in the ordinary way. comp.os.msdos.desqview, for Quarterdeck's multitasker, passed 219 to 30 in April 1991; comp.os.msdos.pcgeos, for the GeoWorks graphical environment, passed 161 to 20 in March 1992; comp.os.msdos.programmer.turbovision, for Borland's text-application libraries, passed 222 to 31 in May 1993. What the newgroup process reliably produced was paperwork — a proposal, a discussion period, a Call for Votes, a tally, a result, all of it posted to news.announce.newgroups and archived. comp.os.msdos.4dos is named after one commercial command processor sold by one small firm, and for it there is none of that. The obvious question is which vote created it. The documented answer is that no vote did.

The administrative record for the Big Eight is mirrored by the Internet Systems Consortium, and for the neighbours of this group it is close to complete. The comp.* directory of the news.announce.newgroups archive holds the proposal paperwork — a Request for Discussion or Call for Discussion, a Call for Votes, a result — for comp.os.msdos.batch, comp.os.msdos.desqview, comp.os.msdos.djgpp, comp.os.msdos.mail-news, comp.os.msdos.pcgeos, comp.os.msdos.programmer.turbovision and comp.archives.msdos.announce. There is no file at all for comp.os.msdos.4dos. No RFD, no CFV, no result, no tally, no charter text. That is not an archival gap: what survives in its place, in the control-message archive, explains the absence exactly.

The earliest surviving control message for the group is dated 15 June 1992 and was issued by Michael C. Berch of IntelliGenetics. Its body reads, in part:

This is a newgroup message for the inet newsgroup comp.os.msdos.4dos. This group is peered with the mailing list [email protected], administered by John Harlan ([email protected]). The gateway site is presto.ig.com, administered by Michael C. Berch ([email protected]).

*** If you do not wish to receive inet newsgroups, you should notify your feed(s) not to send you the inet distribution. ***

The headers matter as much as the text. The message carries Distribution: inet, was approved by [email protected] rather than by the moderator of news.announce.newgroups, and was posted to the pseudo-group comp.os.msdos.4dos.ctl. It supplies, in the customary place, the one line a news administrator needed for the local newsgroups file:

comp.os.msdos.4dos    The 4DOS command processor for MS-DOS.

That single sentence is all the founding description the group ever received. Thirty-four years later it is still, word for word, the description carried in the Big Eight group list. Nothing longer was ever written, because no proposal was ever drafted that would have required one.

INET groups: the side door into comp.*

The inet distribution was not an improvisation. It was a recognised, and for a decade an awkward, category of Usenet group. The clearest surviving statement of what it was comes from the news.announce.newgroups moderation team, in an announcement dated 14 October 2002 that abolished it:

Many years ago, some newsgroups were created in the same hierarchies as some of the Big 8 hierarchies, primarily comp.*, but without following the normal Big 8 newsgroup creation procedure. These newsgroups were technically a separate set of newsgroups, called INET groups, and posts to those groups were supposed to have a different Distribution header. Some sites chose not to carry them.

The mechanism was simple and its consequences were fiddly. Two lists of Big Eight newsgroups were published for years, one including the INET groups and one omitting them, which — as the same announcement notes — made it impossible to issue a standard checkgroups control message for comp.*, since a checkgroups message has no way to express two different group lists for one hierarchy. A site could decline the inet distribution wholesale and never see these groups at all. Some administrators, presented with a newgroup message they had not been expecting, were simply baffled: the control archive preserves, in the same file as the 1992 newgroup message, a one-line query in Dutch sent from a Netherlands government research institute — Waarom missen we die newgroup? Is deze group legaal?, why are we missing that newgroup, and is this group legal? That article carries a subject line belonging to some other discussion entirely, so nothing can be said about the thread it came from; what it says is nonetheless as close as the surviving record comes to showing how the arrangement looked from a site that had not been told about it.

Some INET groups were later put through a normal RFD and promoted to full Big Eight status. comp.os.msdos.4dos was not one of them; there is no promotion paperwork for it either. Instead it was regularised in bulk. The 2002 announcement concluded that the distinction no longer served any purpose, since every site the moderation team knew of carried the INET groups anyway, and that future checkgroups messages would simply include them. The first monthly Big Eight group list in the archive, dated 16 October 2002, duly lists comp.os.msdos.4dos among the ordinary comp.* groups, and the PGP-signed list issued on 15 August 2026 still does.

The rest of the group's control-message history is the ordinary background noise of Usenet administration: a newgroup message from a Massachusetts software firm two weeks after the first, another from a university in Texas in November 1994, another generated automatically by a Netscape Collabra server in November 1997, each one a local administrator or a piece of server software asserting the group's existence for its own site's benefit. None of them constitutes a decision. The group existed because a gateway had been built and because nobody, anywhere, objected enough to stop carrying it.

The objection the proposal never had to answer

Because there was no proposal for this group, there is no record of anyone arguing its case. What the archive does hold is the argument as it was conducted over the group next door, and it is worth setting out, because it shows precisely which objection the 4DOS group sidestepped and which one it would never have faced. The mechanics of Big-8 group creation in general — discussion period, votetakers, thresholds — belong to the comp.* hierarchy page; what follows is only the part that bore on naming a group after something you could buy.

In February 1991 Bob Kusumoto of the University of Chicago opened a call for discussion on a group for Quarterdeck Office Systems' DESQview and its associated memory managers. Canvassing possible names, he wrote:

comp.os.msdos.dv seems like a good name if people needed help with specific problems that aren't limited strictly to the desqview program (maybe comp.os.msdos.qd, but I don't like the idea of attaching a commercial company (Quarterdeck) to a newsgroup name).

The distinction being drawn is a fine one and it held: the group could be named for the product, but not for the vendor. The Call for Votes went out on 25 March 1991, voting ran to 25 April, and the result, posted on 27 April 1991, was that comp.os.msdos.desqview passed 219 to 30. Its charter, in the votetaker's own summary, covered the Quarterdeck product and related products such as the QEMM and QRAM memory managers. Named for the software, the group was uncontroversial; named for the company, by the proponent's own instinct, it would not have been.

The Big Eight also had a designated destination for vendors who wanted their own space: the biz.* hierarchy, where in the same month as the 4DOS newgroup message a computer manufacturer created biz.zeos and biz.zeos.announce — the first of them described in its own control message as carrying information about the company and its product lines — and a Unix vendor created the moderated biz.sco.binaries and biz.sco.sources. A firm that wanted a channel could have one; what it could not casually have was a comp.* group carrying its own name.

The counter-example is sharper still, and it is the fate of the obvious general-purpose alternative. On 1 May 1995 Edwin Schwartz of the German aerospace research centre DLR posted an RFD for comp.os.msdos.batch, a group for batch-file programming as such. Its charter proposed to cover general batch questions, environment problems, I/O redirection, ready-to-run solutions, batch enhancers, batch tools and DOSKEY macros — a scope that would have taken in 4DOS along with everything else. The vote, run by the Usenet Volunteer Votetakers, closed on 27 June 1995 and the result was posted on 10 July:

There were 145 valid votes. The proposed newsgroup, in order to pass, must have at least 2/3 YES votes and at least 100 more YES than NO votes. [...] 118 27 : Yes No : No : comp.os.msdos.batch

Two-thirds in favour, and ninety-one votes clear of the opposition where a hundred were required. The subject-based group failed by nine votes; the product-based group, which had never been put to anybody, had by then been carried on every full news feed for three years. That is not a paradox about what Usenet believed. It is a fact about which door a proposal came through.

A newsgroup with a mailing list underneath

The 1992 newgroup message describes an arrangement rather than a decision, and the arrangement is worth unpacking. The group was peered with a mailing list — [email protected], administered by John Harlan at Indiana University–Purdue University Indianapolis — through a gateway machine, presto.ig.com, run by Michael C. Berch at IntelliGenetics. Mail sent to the list appeared as articles in the newsgroup; articles posted to the newsgroup were delivered to the list's subscribers.

The gateway's operator was not an amateur at this. IntelliGenetics, founded in 1981, was a bioinformatics software company that managed GenBank, the public DNA sequence database, and it was from that project that BIOSCI grew — a set of biology discussion forums built, from the middle 1980s, as Usenet newsgroups with parallel electronic-mail lists, which became the bionet.* hierarchy. Peering a mailing list to a newsgroup was, in other words, the house technique of the firm whose machine carried the 4DOS gateway, applied on this occasion to a DOS shell rather than to molecular biology.

This was the normal way for a working community to acquire a Usenet address in the early 1990s, and it inverts the usual assumption about which came first. The 4DOS discussion existed before the newsgroup did; the newsgroup was a distribution mechanism bolted onto it, for the benefit of readers who had news but not the list. That is also the reason the group has no charter in the Big Eight sense. A mailing list does not need one. It has a subject and an administrator, and the newgroup message simply recorded both.

The arrangement is a direct ancestor of the one this directory documents from the other end: a mail-to-news gateway makes a newsgroup readable and answerable by people whose only reliable network service is electronic mail. In 1992 that meant a researcher whose network service was a mailbox on a university mainframe; a decade later it meant a subscriber with a mailbox and no news server. The mechanics were much the same in both directions, and so were the reasons for wanting them.

How long the peering survived is not recorded. Gateway machines were retired, list administrators moved on, and neither presto.ig.com nor the IUPUI list left a public trail after the newgroup message. What can be said with confidence is that the group outlasted its plumbing by a very wide margin.

JP Software, and the product the group was named after

4DOS was written by Rex C. Conn and Tom Rawson and first released in 1989 by JP Software, a small publisher based in Maryland — Chestertown on the technical notes of 1989, Worton on the copyright line of the last releases. The copyright lines in the shipped files disagree slightly about the beginning: the introduction guide runs from 1988, the licence file from 1989, which places at least part of the writing a year before the selling.

The first release was numbered 2.00 and dated 15 February 1989, and its feature list is already recognisably the whole product in outline: improved command-line editing with filename completion, a command history, aliases, improved wildcards, online help, internal variables, swapping to disk or expanded memory, file descriptions, a command separator and a key stacker. Version 2.20 followed on 5 July 1989 and added executable extensions — the ability to associate a file extension with an application, so that typing the name of a document started the program that could open it, years before a graphical shell made that behaviour ordinary.

It was sold as shareware: distributed freely, used on trial, paid for by those who kept it. The consequences of that model show up throughout the group's history. Shareware travelled through bulletin boards, disk vendors, cover disks and the commercial online services, which meant its users were self-selected — people who had gone looking for a better command line rather than people who had been issued one. It also meant that the vendor's relationship with its users ran through public channels from the beginning, which is part of why a mailing list existed to be gatewayed.

The version history that followed is one of accretion rather than reinvention. Nothing in the list below replaces anything above it.

The release lineage, 1989 to 2004

• 2.00, 15 February 1989 — the original release: command-line editing and filename completion, command history, aliases, improved wildcards, online help, internal variables, swapping to disk or EMS, file descriptions, command separator, key stacker.
• 2.20, 5 July 1989 — executable extensions.
• 3.00, 7 March 1990 — .BTM batch files, cached to memory for speed; swapping to extended (XMS) memory; variable functions; bracketed variable-name syntax.
• 4.00, 1 November 1991 — coloured directory listings, the 4DOS.INI configuration file, include lists, command groups, implied CDD, and support for the upper memory blocks that DOS 5 had just made generally available.
• 5.00, 23 November 1993 — selection by date, time and size ranges; compressed batch files.
• 5.51, 22 August 1995 — long filename support, and REXX in .BAT files as PC DOS 7.0 had it.
• 6.00, 24 July 1997 — extended directory searches, exclusion ranges, interactive configuration through the OPTION command, and an interactive debugger for batch files.
• 7.00, 18 June 2001 — @file lists, after the fashion of DR-DOS.
• 7.50, 24 February 2003 — user-defined functions.

JP Software's last update to 4DOS itself was version 7.50.130, in August 2004. Fifteen years of releases had turned a command-line replacement into a small programming environment, and had done it by addition: each version's list of changes is a list of things added.

The siblings: OS/2, Windows NT and Take Command

The family spread with the platforms, and the order in which it did so left permanent marks on the products. 4OS2, the OS/2 equivalent, was released on 8 June 1992 — one week before the newsgroup's newgroup message — and early packages shipped both 16-bit and 32-bit builds, the former for OS/2 1.x. The 16-bit support was eventually dropped. JP Software's final release of 4OS2 was version 3.04a on 29 October 2002.

The Windows product began life as 4DOS for Windows NT and was renamed 4NT. It was not a port of 4DOS but a recompilation of 4OS2, and it wore its parentage openly: it carried OS/2 command-processor features such as REXX scripting and EXTPROC support, and earlier versions carried DPATH and LIBPATH as well. What prompted the port in the first place was that early 4OS2 ran under Windows NT's OS/2 emulation subsystem at all. 4NT and its graphical companion were issued in both ANSI and Unicode builds, the ANSI version being dropped at version 5; support for Windows 95, 98, ME, NT and 2000 was removed at version 12, and Windows XP support at version 16 of the successor product.

Alongside the three text-mode shells ran a graphical line called Take Command, whose first releases matched 4DOS 5.5, 4NT 2.5 and 4OS2 2.52 — Take Command/16 for Windows 3.1, Take Command/32 for 32-bit Windows, and a Presentation Manager version for OS/2. The 16-bit and OS/2 branches ended at version 2.02.

The names then shuffled. A Tabbed Command Interface, released around the time of 4NT version 7 and requiring Windows XP or later, allowed several consoles to share one window. With version 9 of the package the name Take Command was transferred to the combination of that interface and the shell, and 4NT itself was renamed Take Command Console, or TCC, with a feature-reduced TCC/LE issued as a free download. That Windows line, and not anything with DOS in its name, is what JP Software has sold since.

What COMMAND.COM was, and why it could be replaced

To see what 4DOS was for, it helps to be precise about the thing it displaced, because COMMAND.COM was not merely a modest shell — it was deliberately, structurally minimal. Under DOS it was also the operating system's user interface, the first program run after boot, and the program that stayed loaded while everything else ran.

It was built in two pieces. A small resident portion stayed permanently in memory; a much larger transient portion sat at the top of the transient program area and could be overwritten by an application that needed the space, to be reloaded afterwards from the path recorded in the COMSPEC environment variable. Its internal commands — the ones built into the binary rather than shipped as separate executables — came to about two dozen: BREAK, CHCP, CD, CLS, COPY, CTTY, DATE, DEL, DIR, ECHO, EXIT, MD, PATH, PROMPT, REN, RD, SET, TIME, TRUENAME, TYPE, VER, VERIFY and VOL, with LOADHIGH added in DOS 5 and a handful more, such as LOCK and UNLOCK, appearing only in the Windows 9x versions. Everything else was a program on disk, found by searching PATH and loaded afresh for each invocation.

Its batch language was thinner still. A batch file could set a label, CALL another batch file, iterate with FOR, jump with GOTO, branch with IF, wait with PAUSE, comment with REM and rotate its arguments with SHIFT. Parameters arrived as %0 through %9, and SHIFT existed precisely because there was no way to address the tenth. Conditions could test file existence, string equality and the ERRORLEVEL returned by the last external program. There was no arithmetic, no string manipulation, no loop other than FOR over a list of items, no subroutine, no way to read a keypress, and no facility for putting anything on the screen except a line of text.

Crucially, it was also replaceable, and by design. The SHELL= directive in CONFIG.SYS named the program DOS should load as its command processor, and nothing in the operating system required that program to be Microsoft's. Installing 4DOS as the primary shell meant one line, of the form SHELL=d:\path\4DOS.COM d:\path /P, with the repeated path used to set COMSPEC. A whole small industry lived in that directive, and this newsgroup existed because one of its products had acquired a constituency large enough to need an address.

640 kilobytes, and why the size of a shell was a question

For a reader who has never used DOS, the constraint that shaped all of this needs stating plainly. On an IBM PC and its compatibles the processor could address one megabyte, of which the design reserved the top 384 kilobytes for video memory, option ROMs, the BIOS and memory-mapped devices. That left 640 kilobytes — conventional memory — for the operating system, its drivers, any resident utilities, and the application the user actually wanted to run. The ceiling survived every processor upgrade because DOS itself ran in real mode, and it was still there, unmoved, on machines whose processors could have addressed sixteen megabytes.

Everything competed for that space. A mouse driver, a CD-ROM extension, a network stack, a disk cache and a keyboard-history utility could between them consume a substantial fraction of it before an application started, and users frequently had to choose between the utilities they wanted and the program they needed. From 1990 in DR DOS 5.0 and 1991 in MS-DOS 5.0 — and earlier via third-party memory managers, of which Quarterdeck's QEMM was the best known — drivers and resident programs could be relocated into unused gaps in the upper memory area, which is why so much support traffic of the period, in this group and its neighbours, consisted of people rearranging their CONFIG.SYS to recover a few kilobytes.

A command processor was a resident program like any other, and a bigger command processor was a worse one unless it could get out of the way. 4DOS's answer, set out in its own installation guide, was a version of COMMAND.COM's trick executed much more aggressively. Its resident portion was about four kilobytes by default and could be relocated into upper memory blocks by an INI directive; its transient portion, some 250 kilobytes, occupied low memory only while the system sat at the prompt or ran an internal command or batch file, and was moved out to EMS, XMS or the hard disk the moment an external application started. Configured for minimum footprint, the manual claimed, the shell could sit in as little as 256 bytes of conventional memory. It would run, the same guide said, on any PC-compatible machine with about 256 kilobytes of memory, regardless of processor, disk arrangement or video hardware.

That is the unglamorous reason a replacement shell was viable at all. A shell that offered twenty new commands but cost forty kilobytes of low memory would have been uninstallable on the machines whose users most wanted it.

The command line

The first thing 4DOS changed was the experience of typing. The command line behaved, in the manual's phrase, like a single-line word processor: any part of the line could be edited before Enter was pressed, with movement by character or word, jumps to either end, and insert or overtype editing. Every command executed was remembered, and past commands could be recalled onto the line with the arrow keys or picked from a pop-up window with PgUp, then edited before re-execution.

Filename completion was bound to Tab: type part of a name, press Tab for the first match, press it again for the next, or press F7 or Ctrl-Tab to choose from all matches in a pop-up list. Once long filenames arrived in version 5.51, completion also supplied the quotation marks they required. Directories were remembered as well as commands: Ctrl-PgUp raised a pop-up of previously visited directories, and selecting one changed to it even across drives. Version 6.00 added an extended directory search database that would move to any directory on any hard disk from a fragment of its name.

Help was context-sensitive and bound to F1, which displayed help on the first word of a partly typed line; Ctrl-F1 displayed help on the word under the cursor; and an incorrectly used command produced its own help rather than a bare error. Aliases were held in memory and could stand for a command, a command with switches, an application not on the PATH, or a whole sequence of commands grouped between back-quotes — the manual's own example being an alias that pushed a directory, ran a program and popped back. Aliases could be saved to a file and reloaded at startup, assigned to keystrokes, defined in terms of other aliases, and used inside batch files. Several commands could be typed on one line separated by a command separator character, and the executable-extension mechanism introduced in 1989 let a bare document name start the right application.

Two startup files completed the arrangement: 4DOS.INI, holding configuration that could be edited by hand or set through the interactive OPTION command added in version 6.00, and an optional 4START batch file executed each time the shell started, for loading aliases and environment variables. A matching 4EXIT ran on the way out.

The batch language

The batch language is where the product stopped being a convenience and became the reason people argued about it in public. Its first structural change was to the file format: from version 3.00 a batch file could carry the extension .BTM and be read into memory in one operation rather than being re-opened and re-read from disk a line at a time, which is how COMMAND.COM executed batch files and why they were slow. Version 5.00 added a compression utility, BATCOMP, that produced a compact tokenised form of the same files.

On top of that sat an actual language. The shipped documentation counts more than 140 built-in variables, which report system configuration, device status, free memory and free disk space, and more than 150 built-in functions for reading files, handling dates, performing calculations and manipulating strings. The variables are the ones a batch file would want and DOS could not supply: %_date, %_time, %_cpu, %_rows, %_columns, %_boot, %_dosver, %_4ver, %_country. Arithmetic and expression evaluation arrived through variable functions, of which @EVAL is the representative case.

Control flow was similarly conventional by the standards of any other language and startling by the standards of DOS. The command set includes IFF for a full if-then-else construction, DO for loops, GOSUB and RETURN for subroutines, SWITCH for multi-way branching, and SETLOCAL and ENDLOCAL for scoping changes to the environment. The documentation summarises the result without much modesty: batch files could include subroutines, loops, IF/THEN/ELSE logic and exception handling, and could be run in single-step mode to watch each line execute and each environment variable change. That single-step facility became a proper interactive debugger in version 6.00. User-defined functions of one's own — FUNCTION and UNFUNCTION — arrived last, in version 7.50 in 2003.

The language also took the screen seriously, which mattered when a batch file was frequently the only user interface a DOS machine had. TEXT and ENDTEXT displayed a block of literal text; SCREEN positioned the cursor absolutely; SCRPUT and VSCRPUT wrote at a position in a chosen colour, horizontally or vertically; DRAWBOX drew a box; INKEY read a single keystroke and INPUT read a line; KEYSTACK, with its small resident helper KSTACK.COM, pushed keystrokes into the keyboard buffer to drive programs that could not be scripted any other way. The manual's own worked example is ten lines long: clear the screen, position the cursor, put a three-item menu on it with TEXT, take a keystroke with INKEY, and report the choice — which is exactly the sort of thing users of the group wrote, and exactly the sort of thing that plain batch files could not do at all.

DIR, and the rest of the file handling

The other half of the product was the file commands, and the manual's own illustration is the directory listing. The DIR supplied with DOS had about a dozen options; 4DOS's had those and about twenty more. It could list in one, two, four or five columns, colour entries by file type, sort by several criteria, pause at the end of each page, and print each file's description beside its name. Wildcards were extended so that a bare fragment matched anywhere in a name.

Selection by file attributes ran through the whole command set rather than being bolted onto one command. A range in square brackets restricted any file-handling command by date, time, size or attribute: copy /[d-7] . a:\ copied everything changed in the last week; del /[s1M] *.bak deleted backup files over a megabyte; adding /s did it across an entire drive. Version 6.00 added exclusion ranges for the opposite case, and the EXCEPT command generalised it: except (*.bak;*.bk!) copy . a: copies everything but.

Around that sat a set of commands DOS did not have. SELECT put up a point-and-shoot list from which files could be tagged and then handed to any command. FFIND searched for files by name or by content, with a switch for the string to look for. LIST displayed a file in text or hexadecimal, searched it, and printed a page or the whole thing. HEAD, TAIL and TEE were straight imports of Unix filters. There were also MOVE, TOUCH, ATTRIB, TREE, WHICH, FREE and MEMORY, DIRS with PUSHD and POPD, HISTORY and DIRHISTORY, GLOBAL for running a command across a directory tree, ESET for editing an environment variable in place, and TIMER for measuring how long something took. The introduction guide claims more than 110 commands in all.

DESCRIPT.ION: file metadata for a filesystem that had none

The most durable of 4DOS's inventions was also one of its earliest. From 1989 the shell could attach a line of free text to any file or directory — a description, to remind you what the file was, at a time when the filesystem allowed eight characters and an extension and nothing else. There was nowhere in a FAT directory entry to put such a thing, so JP Software did not try. The text went into a plain-text file named DESCRIPT.ION in the same directory, created and maintained by the DESCRIBE command and displayed by DIR alongside the filenames themselves.

It was, in effect, a user-space metadata layer for a filesystem that had none, and it outlived its origin comprehensively. Other file managers adopted the format — Total Commander among them, using a reserved leading byte for multi-line descriptions — and third-party utilities colonised further reserved bytes at the start of an entry to carry structured data of their own: one for general metadata in XMP form, one used by a family of DOS utilities for space-separated key-value pairs recording code pages, language codes, page geometry, copyright and source URLs, another for pseudo-environment variables, with further values reserved for Digital Research and its successors and for FreeDOS. A convention invented to let one shareware shell print a comment next to a filename ended up as a miniature extended-attribute standard for DOS, maintained by people who had never bought the product.

The comparisons the group made

Two comparisons ran continuously through this kind of group, and both are best reported as the opinions they were. The first was against COMMAND.COM, and it was not really a contest: the question in the group was rarely whether 4DOS did more, but what it cost and what it broke. The honest counter-case, which its own users made, was that anything you wrote in the 4DOS batch language ran only where 4DOS was installed, and that a script portable to a colleague's machine had to be written in the poorer language. That tension — expressiveness against portability — is the standing argument of every shell-extension product ever sold, and it was argued here in the specific terms of .BTM files and machines that only had COMMAND.COM.

Microsoft's own answers were partial and late. DOSKEY, a resident utility providing command history and macros, arrived with MS-DOS and PC DOS 5.0 in the summer of 1991, two and a half years after 4DOS 2.00 shipped a history as part of the shell. Digital Research had got there earlier still by another route: DR DOS 3.40, in early 1989, provided a user-configurable input history and recall at the console-driver level, transparent to running applications. Influence also ran the other way: the system-information variables that 4DOS introduced in version 3.00 in 1990 turn up three years later in the COMMAND.COM of Novell DOS 7 and its DR-DOS successors, with the same idea and mostly different names.

The second comparison was against the Unix shells, which a substantial number of the group's readers used daily at work: many of them reached Usenet in the first place through a university or corporate Unix system. 4DOS invited the comparison by shipping HEAD, TAIL and TEE and by extending redirection and piping syntax, and it lost parts of it for reasons that were not JP Software's fault: DOS ran one program at a time, so a pipeline had to be implemented by running the stages in sequence and passing a temporary file between them, and no amount of shell design could change that. Whether a batch language with 140 variables and 150 functions was a reasonable substitute for the Bourne shell, or an elaborate consolation prize, was a matter on which the group's regulars held views. This page records that the argument was had; it does not adjudicate it.

How it reached machines: shareware, bundles and NDOS

Shareware in 1989 was a distribution system, not a licence philosophy, and the system had physical infrastructure: bulletin boards, disk vendors selling floppies by mail from catalogue listings, cover disks, user-group libraries and the file areas of the commercial online services. A program travelled by being copied, and the paying customer was the one who liked it enough to send a cheque. That is how most of the group's early readers came by the product, and it is why the bulletin-board world and the DOS shareware world overlap so heavily in the surviving record.

The bundle that put 4DOS in front of a mass audience, however, was somebody else's. Symantec licensed the shell and shipped a lightly reworked version of it inside Norton Utilities for DOS under the name NDOS. It first appeared in Norton Utilities 5.0 and was still on the tools list in versions 6.0, 7.0 and 8.0; the last NDOS shipped with Norton Utilities 8 — the final DOS and Windows 3.x edition of the suite, reviewed in the August 1994 issue of Compute! — and corresponded to 4DOS 4.03. A shareware shell from a firm in Maryland thus arrived, pre-installed, on a great many machines whose owners had bought a disk-repair package and had no idea what a command processor was. Some of them worked out what they had, discovered that the bundled version lagged the original, and turned up in this group.

NDOS also locates 4DOS commercially. It belonged to the market for selling improvements to an operating system that shipped without them, and that market had recognisable majors: Quarterdeck Office Systems, founded in 1981, with QEMM and with DESQview from July 1985; Central Point Software, selling the PC Tools suite from 1985; and Peter Norton Computing, bought by Symantec in 1990. All of them competed for the same two scarce resources — the memory below 640 kilobytes and the user's willingness to load one more resident program at boot — which is why coexistence questions form such a large share of the period's support traffic everywhere, not only here.

Later, and by a quite different route, 4DOS acquired one more bundler: the FreeDOS project distributes it as part of its package collection, on the explicit footing that it is not free software but is worth preserving. That is a consequence of the licence discussed below rather than a commercial arrangement. Bundles other than these two are sometimes attributed to 4DOS in secondary accounts; none of them could be confirmed against a source of record, and none is listed here.

What the group carried

Nothing in this article should be taken as a description of individual threads. No message counts, subscriber figures or readership estimates survive for comp.os.msdos.4dos; no thread titles or posters are named here beyond the handful preserved in the administrative record. What can be described honestly is the shape of the traffic, which follows from what the product was and who used it.

The staple was batch programming. A group whose subject includes a batch language with a hundred and fifty functions attracts a characteristic thread: someone states a task that plain batch files handle badly or not at all, and the replies converge on progressively tighter solutions. Parsing, arithmetic, string handling, screen layout, conditional logic and the exact behaviour of variable expansion are the recurring material, and the group functioned in that mode as a working extension of the manual — the manual records what the commands were meant to do, the group established what they did.

The second staple was configuration and coexistence: tuning 4DOS.INI, keeping the footprint down through swapping and upper-memory loading, installing the shell from CONFIG.SYS without breaking the boot, and persuading it to live peaceably inside a Windows DOS box, under DESQview, or in an OS/2 session. A perennial sub-genre concerned applications that assumed COMMAND.COM was the only command processor in the world, and what to do when that assumption failed. Version-compatibility reports — this DOS version, that memory manager, this multitasker — are the natural output of a user base spread across MS-DOS, PC DOS, DR DOS, Novell DOS, OpenDOS, ROM-DOS, PTS-DOS and the DOS layer of Windows 95 and 98, all of which the shell's own documentation claimed support for.

Around those sat the traffic any single-product group carries: release and beta announcements, questions about the sibling products, and questions from NDOS users whose Norton manuals did not answer them. And around all of it sat the standing tension of a group named after something a company sells. JP Software ran channels of its own throughout — on the commercial online services during the shareware years, later on forums hosted on its own servers, which 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 company, and reachable by mail through gateways of the kind that created it in the first place.

That difference was eventually acknowledged from an unexpected direction. When JP Software stopped supporting 4DOS, the shipped documentation of the last community release pointed users not at the company but at the group:

This version of 4DOS is free and unsupported by JP Software.

At the Usenet group comp.os.msdos.4dos, the maintainer and experienced users will try to help with any questions.

A product's own installation guide naming a Usenet group as its support channel is not a common thing to find, and it is the clearest surviving statement of what the group had become by the time that text was written in November 2008: not a supplement to the vendor's support, but its successor.

Freeware, source, and other hands

The end state of the licensing is unusually well documented, because the documents shipped with the software. After the final commercial update in August 2004, 4DOS was released as unsupported freeware under a permissive but non-standard licence: permission to use, copy, modify and distribute without fee or royalty, subject to reproducing the full notice, recording any changes and their dates, and not copying, sublicensing, distributing or transferring the program except as the agreement allowed.

The source code followed on 13 November 2006, as version 7.50.1. The licence text carried in each source file is a modified MIT licence, and the two modifications are the interesting part. They are quoted here as they stand in the release's own README, save that Rex Conn's e-mail address, which follows his name in each clause, is elided:

(2) The Software, or any portion of it, may not be compiled for use on any operating system OTHER than FreeDOS without written permission from Rex Conn

(3) The Software, or any portion of it, may not be used in any commercial product without written permission from Rex Conn

Either condition on its own is enough to disqualify the licence as open source under the Open Source Initiative's definition and as free software under the Free Software Foundation's, both of which forbid discrimination against fields of endeavour and restrictions on where the software may run. It is accurate to say that 4DOS's source was released; it is not accurate to call it open source, and the distinction has been noted consistently since 2006.

The release was also, at first, not quite buildable. A note distributed with it twelve days later explains that a patch had to be applied before the source would compile, that the build still needed a library from the original source distribution, that the shareware registration routines had been removed and their call sites compiled out, and that the result was only minimally tested. The build itself wanted Microsoft C 7 or later and MASM 6.x — the toolchain of the early 1990s, still required in 2006.

Development then continued in other hands. Luchezar Georgiev and Jaelani Utomo took up the code; a run of interim builds appeared through 2007 and 2008, numbered 7.59, 7.63, 7.86 to 7.89, 7.95 and 7.96, and version 8.00 was released on 27 February 2009. Klaus Meinhard's unofficial support and documentation site at 4dos.info remained the reference point, and the revived 4DOS carried its own distribution address. The 8.00 introduction guide, revised by Meinhard and Georgiev on 7 November 2008, is the source of several of the technical details in this article — a vendor manual maintained by volunteers four years after the vendor stopped.

One coincidence of dates is worth recording without comment. The 4DOS source was published on 13 November 2006. Windows PowerShell 1.0 was released to the web on 14 November 2006.

Afterlives

What replaced this class of tool on Windows did so in two stages. cmd.exe, the Windows NT command processor, inherited COMMAND.COM's syntax and improved its batch language moderately — enough to remove some of the more absurd gaps, not enough to make it a programming language. The real successor was PowerShell, released in November 2006, which abandoned text-stream shell conventions in favour of passing structured objects between commands and which was made cross-platform and open-source on 18 August 2016. Between the two, and outliving both as a commercial proposition, sits JP Software's own line: TCC and the Take Command package, still sold and still maintained, with a free feature-reduced edition, and still recognisably descended from a shareware program written for MS-DOS at the end of the 1980s.

The OS/2 branch was handed on rather than retired. The 4OS2 code was released and has been maintained since first by SciTech and then by NetLabs, appeared in eComStation, and ships with ArcaOS, the current commercial OS/2 distribution. The DOS branch runs where DOS runs: on real hardware still in service, in emulators and virtual machines, and on FreeDOS, the operating system the source licence singles out by name. FreeDOS was begun by Jim Hall on 29 June 1994, days after Microsoft announced it would stop selling and supporting MS-DOS, and reached its 1.0 release on 3 September 2006 — ten weeks before the 4DOS source appeared, which is presumably why it was in a position to be named.

The newsgroup itself outlasted most of its neighbours. In February 2011 the Big-8 Management Board opened a Request for Discussion to remove 198 unmoderated groups, on the stated criterion that each had carried zero on-topic, non-crossposted threads in the previous eighteen months. comp.os.msdos.mail-news, which had passed its own vote 140 to 21 in June 1993, was on that list and was removed by a board vote of seven to nothing. comp.os.msdos.4dos was not on it. Neither was comp.os.msdos.desqview. Whatever else the group was by 2011, it was not silent.

It remains in the namespace today. The Big Eight group list of 15 August 2026, PGP-signed by the news.announce.newgroups moderation team, carries comp.os.msdos.4dos alongside comp.os.msdos.apps, comp.os.msdos.desqview, comp.os.msdos.djgpp, comp.os.msdos.misc, comp.os.msdos.programmer and comp.os.msdos.programmer.turbovision — seven survivors of a branch that once held more. The full directory snapshot this site preserves is listed on the all-groups page.

What the record does not show

The gaps are as worth stating as the findings, and several of them are unusual.

• No proposal, and therefore no argument. There is no RFD, no CFV, no result and no vote tally for comp.os.msdos.4dos, because the group was created outside the Big Eight process as an INET group. Anyone citing a vote for this group is citing something that does not exist.
• No charter. The one-line newsgroups entry quoted above is the entirety of the group's formal description. Nothing longer was written at creation or afterwards.
• No promotion. Some INET groups were later put through a normal RFD and promoted to full Big Eight status. There is no promotion paperwork for this one either. It became an ordinary Big Eight group in October 2002, in bulk, along with all the rest, and without a discussion of its own.
• No usage figures. No subscriber count, readership estimate, message total or traffic curve survives for this group. Brian Reid's Usenet readership report, which sampled volunteer news readers and extrapolated monthly to news.lists, is the usual source for such numbers, and figures for this group are not reproduced here because they have not been verified.
• No thread record beyond the archives. Individual discussions are not summarised, quoted or counted in this article. The only postings quoted are those preserved in the administrative archives, which are cited as such.
• The peering. How long the newsgroup and the IUPUI mailing list remained gatewayed, and when the gateway at presto.ig.com stopped running, is not recorded in any source located for this article.

Scope and limits

This page is about a newsgroup, and about the software and the constraints that gave it a reason to exist. It is not a manual for 4DOS, which has a perfectly good one of its own, still distributed with the program; it is not a history of DOS memory management, of which it uses only as much as the group's traffic requires; and it is not an account of how Big-8 group creation worked in general, which belongs with the comp.* hierarchy page linked earlier.

Dates, version numbers and quotations here come from three kinds of source: the Usenet administrative archives mirrored by the Internet Systems Consortium, which supply the control messages, the group lists and the paperwork of the neighbouring groups; the software's own shipped documentation and licence files, which supply the technical and licensing detail; and standard reference works for the surrounding chronology. Where a claim rests on a single source and could not be corroborated, it is attributed rather than asserted; where the group's own traffic is described, it is described in general terms, because that is all the evidence supports.

The reason an address like this one still appears as a citation is not that the archive contains anything sensational. It is that the manuals record what the shell was designed to do, and the group is where its users established what it actually did — on which DOS version, with which memory manager, under which multitasker, at which edge of the batch language, and with which program that would only ever speak to COMMAND.COM. That account was written by the people who hit the problems, was never edited back into the documentation, and is not reproduced anywhere else.