When attempting to determine when exactly the network redirector interface was introduced in DOS, the situation seems to be quite clear. Available literature agrees that DOS 3.1 (released in April 1985 by IBM, possibly earlier by Microsoft OEMs) was when redirector support was introduced. Advanced MS-DOS Programming says: “MS-DOS version 3.1, which was released in November 1984, added support for the sharing of files and printers across the network.” The Wikipedia article on PC DOS (as of May 30, 2012) claims that “Planned networking capabilities in DOS 3.00 were judged too buggy to be usable and Microsoft disabled them prior to the OS’s release.” The famous Ralf Brown’s Interrupt List (RBIL) documents redirector hooks (INT 2Fh/11h) as being called by the “DOS 3.1+ kernel”. Undocumented DOS (2nd Edition, page 494) mentions that “Microsoft has used the redirector interface since DOS 3.1”. Microsoft’s documentation for the MS-DOS CD-ROM Extensions 2.1 (MSCDEX) says that the “product uses the Microsoft Networks interface to MS-DOS so it requires MS-DOS version 3.1 or higher”.
It all seems very clear… except the above statements are either misleading or just plain untrue. The redirector interface was fully present in DOS 3.0, released in August 1984. Also included was the internal DOS services interface (INT 2Fh/12h), support for querying the SDA (Swappable Data Area), and minor other functionality related to networking.
Why do most references get it wrong? Most likely because when IBM released DOS 3.0, the IBM PC Network was announced but not yet available. There simply was no redirector software. By the time the IBM PC Network Program was released, DOS 3.1 was also released and required. There is no known redirector supporting PC DOS 3.0, but that doesn’t mean it can’t be done.
DOS 3.0 differences
There is at least one reason why redirectors don’t support DOS 3.0. Aside from possible bugs and rough edges, many of the DOS internals that redirectors rely on changed between DOS 3.0 and 3.1 (and then remained quite stable until DOS 4.0).
The SDA in DOS 3.0 was significantly different. Just about everything moved around between 3.0 and 3.1; the general structure was quite similar, but most SDA items were at different offsets. For some reason which may never be known, PC DOS 3.0 included a large country information table in the SDA; as the country table doesn’t change and doesn’t need to be swapped, it was moved out of the SDA in DOS 3.1. Worse yet, OEMs were free (and even encouraged) to modify the list of supported countries, which changed offsets of critical items in the SDA. The DOS 3.0 SDA layout does not appear to be documented.
There were other, subtler differences as well. The List of Lists was laid out differently and the CDS (Current Directory Structure) pointer and LASTDRIVE value were at different offsets.
The SFT (System File Table) format was almost identical, except DOS 3.0 used a word offset into the directory sector instead of a byte index. That shifted the file name storage area in the SFT by one byte.
Due to these differences, any redirector which does not explicitly support DOS 3.0 will almost immediately fail, even if the usual version checks were defeated.
The PC DOS 3.0 kernel (IBMDOS.COM) calls the following redirector (INT 2Fh/11h) sub-functions: 00h, 01h, 03h, 05h-0Ch, 0Eh, 0Fh, 11h, 13h, 16h-19h, 1Ch-22h. This is trivial to verify by disassembling the module. The semantics of the redirector calls appear to be the same as in the later DOS 3.x releases, although that is merely a supposition since no official documentation is available.
Phantom 3.0
Given the internal differences between DOS 3.0 and DOS 3.1+, is it possible to use the redirector interface under DOS 3.0 at all? Yes, it is; the OS/2 Museum adapted the Phantom redirector from Undocumented DOS (2nd Edition) to account for the DOS version differences.
Unfortunately, the Phantom redirector as delivered with Undocumented DOS is somewhat buggy, for reasons that have nothing to do with DOS version differences. For example, the directory search function fails to search directory sectors other than the first; as a consequence, Phantom will never find more than 32 entries in a directory (DOS directory entries are 32 bytes in size and Phantom uses 1K sectors). Another bug causes Phantom to lock up at start-up on many systems because it uses not yet initialized variables when calling an internal DOS function. There are other issues as well.
Due to these problems, the modified Phantom redirector is not currently available as it might destroy data. However, what’s there is sufficient to demonstrate that the redirector interface was, in fact, present in DOS 3.0.
The modifications to the Phantom source code were fairly minor and account for changes in DOS data segment layout and changes in SFT structure. And of course changing the DOS version check. The core redirector logic did not need to be adapted.
Since Phantom is a TSR, it can be installed and removed at will. It does require a XMS driver, which wasn’t supplied as part of DOS 3.0, but for example HIMEM.SYS version 3.07 (shipped with Windows 3.1) works well.
Once Phantom is installed, a new drive letter “magically” appears. Files can be copied to it, listed, executed, and deleted. Directories can be created and removed.
In other words, the redirected drive behaves very much like a local disk, except it can be added and removed at run-time. There are other, subtler differences as well: For example, CHKDSK (predictably) refuses to check the redirected drive, with a “Cannot CHKDSK a Network drive” message.
As is now obvious, DOS 3.0 did in fact support very significant drive redirection functionality.
DOS redirectors
Redirectors in DOS were used primarily for networking, but not exclusively so. A well know redirector implementation is MSCDEX.EXE, the MS-DOS CD-ROM Extensions providing CD-ROM support for DOS. Various drivers for “foreign” filesystems (such as HPFS or NTFS) were also implemented in the form of redirectors.
A major advantage of redirectors is that they can add and remove drive letters at run-time. A redirector can therefore be implemented as a removable TSR.
It should be pointed out that although MS-DOS was rarely viewed as a hotbed of innovation, the redirector interface in DOS 3.0 was state-of-the-art when it first appeared. The first well known VFS (Virtual File System) implementation in the UNIX world was SunOS 2.0, released in May 1985 (shortly after PC DOS 3.1). But the DOS redirector interface had been around, entirely unadvertised, since August 1984.
Further references
Interestingly, not everyone claimed that the redirector interface was first implemented in DOS 3.1. The MS-DOS Encyclopedia contains perhaps the clearest explanation: “Both the redirector and the sharer interfaces for IBM’s Network Adapter card were in place in version 3.0 when it was delivered to IBM, but the redirector itself wasn’t ready.” Here it should be understood that the “redirector itself” was the component delivered as part of networking software rather than DOS itself.
It is unclear how many other publications clearly recognized that the redirector interface was fully implemented in DOS 3.0. The conventional wisdom clearly was that redirectors required DOS 3.1.
It is also unclear whether there were any redirectors (other than perhaps test code at Microsoft and/or IBM) supporting DOS 3.0. It is presumed that by the time the redirector interface became somewhat known, DOS 3.0 was obsolete and did not merit support.
The oldest known surviving binary of a DOS redirector is REDIR.EXE from November 1984, designed to work with MS-DOS 3.05/3.06. A quick analysis shows that—as the version number suggests—MS-DOS 3.06 is somewhere between PC DOS 3.0 and 3.1 in terms of networking support.
It would be more precise to say that DOS 3.1 was the first version where the redirector interface was stable enough to use in released programs.
“For some reason which may never be known”
From http://blogs.msdn.com/b/larryosterman/archive/2004/11/08/254108.aspx :
“The MS-DOS redirector was actually originally written as a part of the MSDOS.SYS (IBMDOS.COM) binary. For obvious reasons (not every user in the world had a network card, especially in 1984), the redirector was split out from the DOS binary after the product shipped. In fact, when I took over the redirector project, the binary used to link with hundreds of unresolved external symbol errors (because the redirector linked with some, but not all of the MS-DOS binaries). “
Wrong. That explains why the redirector interface is so messy (a redirector needs to poke around DOS internal data areas a lot), but it does not explain why the internationalization table would be in the middle of the DOS SDA. The SDA is a concept orthogonal to redirectors and would exist (and be useful) regardless of whether the redirector were part of the DOS kernel or a separate module.
No, it wouldn’t — unless you have some real evidence that the redirector interface in DOS 3.0 was unstable. In my testing it worked quite well. Note that I am not talking about general networking support, only redirectors.
I am talking in the context of why the redirector interface was unstable and DOS 3.1 was the first version for which redirectors were actually available.
Unstable in the sense of an interface which changed too often, not that it was actually unusable.
It’s more likely that it was the other way around. Once redirectors were widespread, it became much, much harder to change the DOS internals which redirectors relied upon. I’m sure that in retrospect, Microsoft wished that the redirector interface had been better architected; but it was what it was, and introducing a whole new redirector interface with better abstraction was probably much harder than keeping the old ugly interface going.
That said, the differences between DOS 3.0 and 3.1 are not unlike the differences between DOS 3.3 and DOS 4.0+. A few offsets changed here and there, but on the whole the redirector logic remained exactly the same.
Remember that REDIR was supplied as a binary by Microsoft and the OEM should not need to change it. The DOS data structures had to be stable enough that common OEM adaptations would not require changes to REDIR.
Although I note your comment about the modified phantom redirector not being published, perhaps you can share the differences in the SDA layout between DOS 3.0 and 3.1? There seems to be no other source for this on the web, though please correct me if I’m wrong!
It is likely that no one ever examined the DOS 3.0 SDA because it was replaced by DOS 3.1 in less than a year so it became irrelevant. Also the DOS 3.0 SYSVARS table is different from that of DOS 3.1 and later and that is definitely a factor for redirectors. See here for the SYSVARS differences in various versions of DOS – https://sites.google.com/site/pcdosretro/sysvars
Thanks for the link for SYSVARS, I will check this against the data I already have. You are quite correct in that the SDA format will affect redirector compatibility, that’s the problem I’m trying to solve. As a hobby I like making various bits of Dosemu2 https://github.com/stsp/dosemu2 work across as many DOSes as I have access to. The task I’ve set myself here is to fix the ‘mfs’ redirector that gives Linux filesystem access to work with DOS 3.0, hence the need for the SDA differences. In the article it mentions that Phantom 3.0, an as yet unreleased modification of the redirector source that came with the ‘Undocumented DOS’ book, has been made to work with DOS 3.0. To do this they must have worked out the SDA differences I’m looking for. I found this other thread http://www.os2museum.com/wp/phantom-3-0/ which has a link to an image file, but no source, and some hints to the other differences. I’m wondering if the v3.0 source was released and I’ve not been lucky enough to stumble across it.
Actually, I mounted the image I just found and it does contain the source code and SDA differences. Thanks for your help.
For reference here are the two difference structures:
/* Swappable DOS Area – DOS VERSION 3.0 */
typedef struct
{
uchar f0[16];
uchar far * current_dta; /* DMAADD */
uint end_mem; /* ENDMEM */
uchar no_set_dir; /* NOSETDIR */
uchar f1[2];
uchar dd; /* DAY */
uchar mm; /* MONTH */
uint yy_1980; /* YEAR */
uchar f2[0x342];
char file_name[128]; /* OPENBUF */
char file_name_2[128]; /* RENBUF */
SRCHREC srchrec; /* SEARCHBUF */
DIRREC dirrec;
uchar f3[81];
char fcb_name[11]; /* NAME1 */
uchar f4[2];
char fcb_name_2[11]; /* NAME2 */
uchar f5[33];
uchar srch_attr; /* SATTRIB */
uchar open_mode; /* CREATING??? */
uchar f6[40];
uchar far * cdsptr; /* THISCDS */
uchar f7[79];
SRCHREC rename_srchrec;
DIRREC rename_dirrec;
} V30_SDA, far* V30_SDA_PTR;
/* Swappable DOS Area – DOS VERSION 3.1+ */
typedef struct
{
uchar f0[12];
uchar far * current_dta;
uchar f1[30];
uchar dd;
uchar mm;
uint yy_1980;
uchar f2[96];
char file_name[128];
char file_name_2[128];
SRCHREC srchrec;
DIRREC dirrec;
uchar f3[81];
char fcb_name[11];
uchar f4;
char fcb_name_2[11];
uchar f5[11];
uchar srch_attr;
uchar open_mode;
uchar f6[48];
uchar far * cdsptr;
uchar f7[72];
SRCHREC rename_srchrec;
DIRREC rename_dirrec;
} V3_SDA, far* V3_SDA_PTR;
You can try phantom30.zip at your own risk. It has been tried on PC DOS 3.0 and it does work at least to some extent. Unfortunately the original code from the book was not exactly bug-free and I wouldn’t say it was extensively tested. There might be problems caused by the original Phantom code, by the way it was adapted for DOS 3.0, and by bugs in DOS 3.0 itself.
It does prove that the redirector interface existed in Summer 1984.
That SDA structure is far from complete but truly no program should need to directly access DOS internal data. The only reason redirectors do is because the redirector originally stared out as part of the DOS kernel and was separated out to save memory since most users didn’t need it. Some info here – https://blogs.msdn.microsoft.com/larryosterman/2004/11/08/how-did-we-make-the-dos-redirector-take-up-only-256-bytes-of-memory/