While researching the history of DOS extenders, I came across an article written in 1991 and explaining why OS/2 2.0 was going to be horribly incompatible with Windows 3.x. To support the argument, the following statement was used: “When IBM releases a complex product that has undergone only a relatively brief beta-testing period, what you get is DOS 4.0 — the first version of DOS written primarily by IBM rather than Microsoft, which didn’t work well with most non-IBM memory boards. (Microsoft corrected the problem later with MS-DOS 4.01.)” This quote is interesting on many levels and illustrative of the low quality of PC press at the time — though whether it has gotten any better is an open question.
For reference, the quote appeared in the Window Manager column by Brian Livingston titled “BigWin is the best road to 32-bit Windows development”, published in the September 2, 1991 issue of InfoWorld on page 20.
Fairy Tales vs. Reality
What’s wrong with the quote? Almost everything. There is no reason to suspect that DOS 4.0 underwent testing significantly different from previous versions. And the first version of DOS written primarily by IBM was DOS 3.3, not 4.0, which the author could have established by reading past issues of InfoWorld.
It’s true that IBM DOS 4.0 did not work with many non-IBM EMS memory boards when the BUFFERS /X switch was present in CONFIG.SYS, i.e. expanded memory was used for DOS buffers. The reason for the problem was that DOS expected the memory board to provide at least six EMS pages, two of which would be reserved for DOS and the rest available for applications. The EMS management in DOS could thus be simple and fast. Unfortunately, many non-IBM memory boards provided fewer than six pages. That led to conflicts and potential data corruption.
It’s unclear whether it was IBM or Microsoft who fixed the problem; at any rate, IBM did issue a fix in June 1989.
The real question is why people expected that IBM DOS 4.0 should work with non-IBM hardware? IBM never claimed or promised any such thing. IBM’s DOS was specified to work with IBM hardware. It worked with many clone systems, as long as those were sufficiently IBM compatible. Somehow there were no complaints in the press that Compaq’s or Zenith’s or AST’s DOS didn’t work with other OEMs’ hardware.
Wikipedia Doesn’t Help
While looking up information about DOS 4.0, I came across the IBM PC DOS entry on Wikipedia. The section about IBM DOS 4.0 (as of April 15, 2012) was so appalling that I’ll quote it here in its entirety:
PC DOS 4.0, shipped July 1988, was an unsuccessful DOS which arose from IBM testing ideas for its in-development DOS 5, which later became OS/2. DOS 4.0’s kernel was heavily rewritten, and the efforts of IBM’s development team were nothing short of slipshod. The OS proved to have numerous glitches in it in addition to taking more than twice as much memory as DOS 3.30. Newly-added EMS drivers were only compatible with IBM’s EMS boards and not the more common Intel and AST ones. IBM also stripped out support for the obsolete DOS 1.x file control blocks, but this caused numerous complaints from people running older applications (especially WordStar). DOS 4.0 is also notable for including the first version of the DOS Shell, a full screen utility designed to make the command-line OS more user friendly. Like the rest of the OS, the DOS Shell was poorly designed and irksome to use. Thoroughly displeased with DOS 4.0, Microsoft took back control of development and released a bug-fixed DOS 4.1.
This really gives Wikipedia a bad name. The section is completely unsourced, and uses language which is inappropriate for an encyclopedia. It is a mix of half-truths, myths, and utter nonsense. Let’s pick it apart.
Was DOS 4.0 unsuccessful? Probably. But without listing some sales figures, it is difficult to judge that. It’s even less clear how DOS 4.0 could have been a testbed for OS/2 ideas when it was released in July 1988, while OS/2 1.0 came out in November 1987. What those ideas might have been is likewise a mystery. Perhaps the author mixed up Microsoft’s “European OEM” multitasking DOS 4.0 from 1986 (which indeed was a precursor to OS/2) with IBM’s DOS 4.0 from 1988.
Was the DOS 4.0 kernel really heavily rewritten? No evidence is provided. At any rate, terms like “slipshod” have no place in an encyclopedia, except when quoting external sources. Talking about “numerous glitches” without providing at least a short list of the top issues, that is slipshod.
Did DOS 4.0 really take up twice as much memory as DOS 3.3? In some configurations perhaps, in general no. Maybe the Wikipedia entry was referring to the minimum system memory requirements (256K for DOS 4.0 vs. 128K for DOS 3.3), which is unrelated to the amount of free memory in the system, but that’s just a supposition. The fact is that DOS 4.0 booted without CONFIG.SYS and AUTOEXEC.BAT on a 640K system leaves 570.7KB free, i.e. consumes just shy of 70KB; DOS 3.3 leaves 586.2KB free, i.e. uses almost 54KB or memory. Why anyone would say that 70KB is twice as much as 54KB is a mystery. Unless they were really bad at math. Note that the comparison is still not quite apples to apples since the DOS 4.0 figure includes SHARE.EXE, which is loaded by default for large disks.
Newly added EMS drivers in DOS 4.0 only only supported IBM hardware, not Intel or AST. That’s like stating that Intel’s or AST’s EMS drivers don’t support IBM memory boards… well, duh!
The statement about FCB support being dropped in DOS 4.0 is very interesting because it’s blatantly false. Even a brief glance into any DOS programming reference will show that DOS 4.0 most certainly did support FCBs. The fact that DOS 4.0 documentation mentions the FCBS statement in CONFIG.SYS should have been a big hint that FCBS support was not, in fact, removed. Again with no sourcing, compatibility issues with older applications are alluded to. The book Developing Applications Using DOS by Christopher, Feigenbaum, and Saliga (Wiley, 1990) describes in detail how FCBs were implemented in DOS 4.0. For large disks (that is, DOS partitions greater than 32MB), FCB support was partially implemented in SHARE.EXE and would not work without it. If the FCBS statement was inappropriately configured, that could cause trouble too. Perhaps that’s what Wikipedia is referring to, but then again perhaps not — the reader can only guess. Not exactly what encyclopedias are supposed to be for.
Statements like “DOS Shell was poorly designed and irksome to use” (what does “irksome to use” even mean?) once again have no place in an encyclopedia. Why was the design so bad? What made the DOS Shell troublesome to use? It’s true that the DOS Shell in its default configuration was incompatible with TSRs which assumed that the “foreground application” ran in text mode. Any graphical application would have had the same issue, and short of fixing the TSRs, the only solution was not running the DOS Shell at all or force it to run in text mode. It’s not clear why the DOS Shell was blamed for the situation. And it would have been fair to say that the DOS Shell was entirely optional and users weren’t forced to use it.
It’s true that Microsoft was not pleased with the poor reception of DOS 4.0. That much is clear from reading internal Microsoft memos. How much of it was Microsoft’s fault for not catering to the OEM market is an open question. It was Microsoft’s (and OEMs’) job to support non-IBM hardware, not IBM’s. Yet somehow IBM got all the blame for problems with non-IBM hardware and Microsoft was the hero for belatedly fixing the problems. That does imply that Microsoft’s PR department was very effective, but it does not speak well for the computer press which failed to question the implied assumptions.
Killed by a Meme
In modern days, one might say that DOS 4.0 was the victim of a meme. It’s hard to blame IBM for not making sure that DOS 4.0 worked better with non-IBM hardware; that simply wasn’t their job. On the other hand, IBM clearly failed to explain that. This is where the mismatched expectations come in: IBM expected that users would be running IBM DOS 4.0 on IBM hardware, while users expected that IBM DOS 4.0 would flawlessly work on every piece of non-IBM hardware. It’s also true that IBM did not widely test DOS 4.0 with third-party software.
Some of the problems with DOS 4.0 were really no one’s fault. Existing disk utilities not being able to handle larger than 32MB partition were simply a fact of life. The only way to avoid that would have been to stick with the 32MB limit forever — clearly not a workable solution. It wasn’t DOS 4.0’s fault that the disk support had to be changed, and it wasn’t the fault of disk utility developers that they didn’t support large partitions until after DOS. Yet DOS 4.0 got the blame for it. Similarly the problems with DOS Shell in graphics mode being incompatible with TSRs assuming text mode were more or less inevitable.
Once the “DOS 4.0 is bad” meme set in, it was all over. The press just kept repeating that “DOS 4.0 is buggy” without explaining the impact of the bugs and incompatibilities and informing readers how to avoid the issues (for example, not using buffers in EMS avoided incompatibilities with non-IBM memory boards). IBM and Microsoft fixed most of the bugs, but that did not help. The DOS 4.0 name was so damaged that Digital Research skipped it altogether and went from DR-DOS 3.x straight to 5.0. In the end, many PC users skipped DOS 4.0 because it had such a bad name.
DOS 5.0 Saves the Day?
When DOS 5.0 was released, it was hailed as a brilliant masterpiece with none of the problems of DOS 4.0. Somehow it didn’t seem to occur to computer journalists that maybe DOS 5.0 was not incompatible with 3rd party disk utilities because utility writers had three years to adapt to large partition support, and perhaps the DOS Shell didn’t cause problems with TSRs because TSR authors had three years to add support for graphics modes.
The one significant advance that DOS 5.0 brought was high memory support (HIMEM.SYS) which alleviated the conventional memory pressure. For comparison, DOS 5.0 in default configuration (i.e. no high memory) leaves 578.3KB free, i.e. DOS takes up about 62K. When SHARE.EXE is loaded, 572.3KB is free, which means DOS uses about 68KB. Compared to 70KB for similarly configured DOS 4.0, the difference is nothing to write home about.
That said, by mid-1991 when DOS 5.0 was released, 8088/8086 based machines were very much on the way out; 286+ systems were able to take advantage of high memory and DOS itself would take less than 20KB of conventional memory (i.e. more than 620KB could be free). Again, the fact that compared to DOS 4.0, DOS 5.0 did very little for 8088 based machines was rarely mentioned.
DOS 5.0 initially contained data-destroying bugs too, but that was never widely publicized. Somehow DOS 5.0 was the opposite of DOS 4.0; whereas DOS 4.0 did everything wrong, DOS 5.0 couldn’t be faulted at all.
Is there anything to be learned from the DOS 4.0 debacle? One of the few clear messages is that the computer press should not be taken too seriously. Their job is to make money, not accurately report the facts. And horrible bugs and evil corporations make a much better story than “not much to see here, move along”.
One of the most interesting features in DOS 4 was the IFS support, a standardized way to access the DOS kernel redirector, and add new filesystems to the OS without the need to do hack tricks.
Not so much info in the internet. i would like that you can talk about this lost DOS feature in a future issues.
Greetings.
There’s not a whole lot of information on IFSFUNC.EXE out there. According to Undocumented DOS (both 1st and 2nd edition), it was an extra layer on top of the DOS redirector interface, but because it’s specific to DOS 4.0, it’s not worth writing about. About the (DOS 3.1+) redirector interface itself, Undocumented DOS (1st ed., page 217) says that it was not properly documented even inside Microsoft. In the 2nd edition (page 495), the authors add that Microsoft did provide sample code and ‘expertise’ to selected third parties, which was not very nice of MS.
According to Developing Applications Using DOS (by far the best source of information on DOS 4.0 I’m aware of), IFSFUNC provided an ‘architected interface’ between redirectors and DOS. The book says (page 47) that information on IFSFUNC interfaces is/was provided by IBM; I’ve not seen any references to that information, although that doesn’t mean it doesn’t/didn’t exist. PC LAN Program (REDIRFS.EXE) reportedly used it, perhaps some other networking programs as well. Based on the strings within IFSFUNC.EXE, it appears there was some network redirector functionality in it.
Looking at the information in Undocumented DOS (and RBIL), it does not appear that IFSFUNC provided any fundamentally new functionality; it was apparently meant to create a stable interface. Unfortunately IBM/MS made that kind of pointless by not publicly documenting the interface.
At any rate, IFSFUNC was gone again in DOS 5.0. However, the actual INT 2Fh/11h interface was probably a superset of what IFSFUNC had offered, so redirectors didn’t care. There is a note in the DOS 5.0 documentation that if network clients try to load IFSFUNC.EXE in CONFIG.SYS, it should be simply commented out.
From Larry Osterman’s blog:
“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). One of the first things that I did while working on the project was to clean this up so that the redirector would cleanly link without relying on the MS-DOS objects.”
DOS 4 took the lumps so that the applications could catch up when DOS 5 rolled out. Sound’s similar to Windows 3.1 Apps blowing up under OS/2 Warp amd getting cleaned for Windows NT and to some extent Windows 95, and then again Windows Vista cleared the way for Windows 7. History repeats.
Yes, the parallels between DOS4/5 and Windows Vista/7 are especially striking. Such as DOS 3.3 being sold alongside DOS 4 (and outselling it) until DOS 5 came out.
“PC LAN Program (REDIRFS.EXE) reportedly used it,”
Yea, IBM PCLP had to be updated to 1.34 to be compatible with DOS 5.0.
Tend to agree that most of this is likely due to a mix up with MSDOS 4.0.
One of the very few OEMS that shipped it was ICL, I seem to recall to talking to one of the MS UK folks about it at the time (I worked for Borland in tech support and was trying to get a freebie copy for the UK office but it was very tied to the hardware) and wikipedia has some stuff here http://en.wikipedia.org/wiki/ICL_DRS
The multi-tasking element was really TSRs on steroids and I would guess that killing FCBs and forcing handles would make a lot of sense in that case.
You could be onto something there. Though how the circa 1986 multitasking MS-DOS 4.0 turned into the completely different 1988 PC DOS 4.0 in someone’s mind is still a mystery.
Did you actually get to see the multitasking MS-DOS running on an ICL?
“About the (DOS 3.1+) redirector interface itself, Undocumented DOS (1st ed., page 217) says that it was not properly documented even inside Microsoft. In the 2nd edition (page 495), the authors add that Microsoft did provide sample code and ‘expertise’ to selected third parties, which was not very nice of MS.”
I am not surprised. When do you think did the DOJ anti-trust investigations against MS began?
“the difference is nothing to write home about.”
Though DOS 5.0 was the first DOS release that took *less* memory than the previous release.
Makes me wonder how much conventional memory MS-DOS 7.1 takes when loaded low.
“which means DOS uses about 68KB. Compared to 70KB for similarly configured DOS 4.0,”
BTW, I think differences that small should be measured in bytes.
Why don’t you measure the difference in bytes and post your own numbers?