27

Early MS-DOS versions were designed and indeed adapted to run on machines not fully IBM PC compatible.

However, there seems to be a number of utilities bundled with later versions, that seem not to fully rely on MS-DOS interfaces for device access, most notably FDISK and later TUI editor EDIT.COM.

If a manufacturer of totally non-compatible machine would've wanted to adapt these, was there an official way of doing it, or were such utilities marked for more-or-less full rewrite for such cases, or were these not part of "core MS-DOS", or was the idea of being able to adapt MS-DOS for non-compatibles dropped at some point of history?

15
  • 2
    Wikipedia claims the last major release of MS-DOS to have OEM-specific versions is 4.x; this would agree with the offering from WinWorldPC. I think programs like EDIT and FDISK came later than that. But I’d have to verify. Oct 9, 2022 at 9:15
  • 5
    @user3840170 I don't know about fdisk, but I remember switching from edlin to edit with MS-DOS 5.0.
    – ssokolow
    Oct 9, 2022 at 12:31
  • 4
    I'll just note that, at least in the early years, of clones "PC Compatible" was a flexible term at best. Reviewers and marketers making that clam would base it on odd ad hoc criteria. For example, if a given machine would run vanilla versions of both Lotus 123 and Microsoft Flight Simulator, they would often declare it as "PC Compatible".
    – RichF
    Oct 9, 2022 at 13:36
  • 3
    @user3840170 DOS 4.01 has in fact be adapted to wildly incompatible x86 systems.
    – Raffzahn
    Oct 9, 2022 at 15:50
  • 3
    It was a very important sales parameter to be 100% PC-compatible. so those that weren't died out very quickly. Oct 9, 2022 at 16:29

2 Answers 2

22

As far as I’m aware, no, at least not for standalone versions of MS-DOS (i.e. up to 6.22).

Microsoft started selling complete versions of MS-DOS with version 3.2; prior to that, companies selling computers with MS-DOS had to license an “OEM Adaptation Kit” and provide a number of tools of their own to produce a complete version of DOS. With version 3.2, Microsoft also made available a ready-made version of DOS for resale by computer manufacturers; this included tools such as FDISK (which were also added to the OAK).

The fact that Microsoft included all the “expected” utilities with MS-DOS 3.2 (and later) didn’t preclude computer manufacturers from using the OAK to produce their own OEM version of MS-DOS, and this practice continued up until at least version 6.0; obviously these OEM versions contained ever fewer OEM-specific tools, and by version 5.0 much of the OEM adaptations were branding and the addition of computer-specific tools such as setup tools or power management tools in laptops (see Toshiba MS-DOS for example). Some manufacturers continued providing their own implementations of some of the tools even after Microsoft started providing “default” versions, even on PC-compatible systems.

MS-DOS up to version 6.22 included still had the IO.SYS/MSDOS.SYS split which was necessary to allow MS-DOS to run on not-fully-PC-compatible platforms: MSDOS.SYS is the DOS kernel itself, common to all implementations (with minor tweaks for localisation), IO.SYS provides the hardware drivers and platform-specific code, and was intended to be modified by OEMs. I’m not sure off-hand whether there were actual OEM versions of MS-DOS 6.22 (beyond re-branding the floppy disks), but in theory it would have been possible to produce a version of MS-DOS 6.22 capable of running on an x86 system that wasn’t fully PC-compatible.

Starting with version 5.0, an OEM version of MS-DOS on a non-PC-compatible platform may well have ended up being quite different from MS-DOS on PCs; as you mention, EDIT.COM might not have worked, and the various licensed tools included with MS-DOS 5.0 and later could run into problems too (as could any program using direct hardware access or anything other than DOS APIs). It wasn’t unheard of for OEMs to provide their own text editors, better than EDLIN, so the editor wouldn’t have been much of a concern. Likewise, the various memory management tools in MS-DOS 5.0 and later might not have needed equivalents on another x86 system with a better memory layout. This is all theoretical, since as far as I know, no OEM ever implemented a version of MS-DOS 5.0 or later for a non-PC-compatible system. IBM produced their own version of MS-DOS 5.0, PC DOS 5.0, based on the same source code; the first releases of PC DOS 5.0 included a version of QBASIC which relied on ROM BASIC, so PC DOS 5.0’s EDIT.COM on a non-IBM PC locks up! (This was fixed in PC DOS 5.00.1. Ironically, this is a reminder that all PC compatibles aren’t fully PC-compatible, since they don’t include ROM BASIC…)

However it would have been difficult for a computer manufacturer to produce a non-PC-compatible system capable of running OEM MS-DOS and OEM Windows, which was important by the time MS-DOS 5.0 became common. The NM-186 is one example of a non-PC-compatible OEM system with DOS and Windows, up to 3.0; but I’m not sure it would have been feasible (or at least, cost-effective) for a computer manufacturer to get enhanced-mode Windows running on a non-PC-compatible system.

7
  • I would think of EDIT.COM as working, as it's essentially only calling QBASIC in editor mode, and QBASIC was available for (some) non compatible machines.
    – Raffzahn
    Oct 9, 2022 at 15:41
  • @Raffzahn was it? Do you have examples? GW-BASIC was available for incompatible machines, but I’ve never heard of a non-PC QBASIC (which doesn’t mean it never happened, of course!). Oct 9, 2022 at 15:57
  • 1
    Right, I’m asking specifically about QBASIC, the cut-down version of QuickBASIC included in MS-DOS 5.0 (1991). Oct 9, 2022 at 16:33
  • 1
    Right, understood, can't pin down my memory on that, have to look.
    – Raffzahn
    Oct 9, 2022 at 16:37
  • 1
    I’m thinking the only thing that had to tie down Edit to specific (100% IBM-compat.) hardware would have been MDA and/or CGA text mode memory layout (and by that time nobody would have dared to deviate), and the Microsoft Mouse INT API (which you could live without or provide a OEM replacement driver). Maybe keyboard handlers? QBasic OTOH would have been far more fragile to hardware variances, because (e.g.) it needs i8254-compatible hardware on the correct ports for PLAY and BEEP; and who knows what else. Oct 9, 2022 at 21:09
8

TLDR:

No, the Kernel was always machine independent and manufacturers of machines with different base hardware would be supported with adaption kits. Distributions in turn, like MS-DOS, PC-DOS or OEM versions did always include machine specific parts, driver and utilities.

With the extinction of really different hardware around 1990, the PC customized version became the only one widely available one (in retail). The DOS 4.01 distribution is (to my knowledge) the last that ever got rolled out by OEM for 'lesser' compatible systems.

As already implied, it's a story of much history - or better the difference between planned future and real outcome :)


The Question

Did MS-DOS ever drop ability to support non-IBM PC compatible machines?

No.

Early MS-DOS versions were designed and indeed adapted to run on machines not fully IBM PC compatible.

This was kept until the very end.

However, there seems to be a number of utilities bundled on later versions, that seem to not fully rely on MS-DOS interfaces for device access, most notably FDISK and later TUI editor edit.com

Well, FDISK for example was manufacturer-specific right from its first appearance with DOS 2. EDIT.COM in turn is just a wrapper for QBASIC's editor mode. So this might be more a question of whether QBASIC got adapted to lesser compatible systems. Its parent product QuickBASIC was.

This seems much more a question of what your definition of MS-DOS is.

If a manufacturer of totally non compatible machine

Often overlooked, but a machine had to have at least a basic 8086-compatible CPU mode, disk-like mass storage, terminal I/O and time "counting" to host MS-DOS, as these were the services the OS expects.

would've wanted to adapt these, was there an official way of doing it,

Yes, it was done by buying an 'OEM Adaption Kit' - with DOS 4 the name (may have) changed to 'Binary Adaption Kit' as an Infoworld Article of October 3rd, 1988 shows.

or were such utilities marked for more or less full rewrite for such cases, or were these not part of "core MS-DOS",

Both: they were not core of the OS, but delivered as source templates to be adapted.

In fact, already COMMAND.COM may be counted as utility, as it differed between MS-DOS 2 and PC DOS 2 in the way programs are started, as visible in the DOS 2 sources. In MS-DOS the exec call (Int 21h ) is handed by DOS, while in PC-DOS it's hooked and done by COMMAND.COM, a behaviour similar to DOS 1.x. This got removed in later versions, making COMMAND.COM the same over PC/MS-DOS.

or was the idea of being able to adapt MS-DOS for non compatibles dropped at some point of history?

Yes and no. As usual it's all about history.

History Fully Hits With DOS 4

DOS 4(.01) is a very special beast, as originally MS intended DOS 4 to support multitasking. After DOS 3.2 fixing up minor network issues and adding 3.5" drives, MS focused on their 'Advanced DOS 1.0', what later became known as the (somewhat) infamous MS-DOS 4.0. No further work on single-tasking MS-DOS was intended.

3.2 is as well a turning point, as it's the first MS-DOS version that got sold by MS as a consumer product. Up to and including 3.1 DOS was only available as customized (OEM) Version.

IBM in turn took their PC-DOS 3.2 and added support for their new PS/2 line to publish it as PC-DOS 3.3. Microsoft only reluctantly added MS-DOS 3.30 (!) under pressure from OEM customers, while being committed to 'Advanced DOS 1.0'.

PC-DOS 4.0 (Working title 3.4) was a solely IBM development. IBM added several utilities that were IBM-hardware only, most notably the DOS-Shell (*1) using direct screen access. Being the only user for their own software they did not see any reason to make it device independent like by using ANSI.SYS.

Again, demand by OEM customers, who wanted to offer DOS 4 to their customers, added pressure to MS, resulting in an agreement to back-licence PC-DOS 4.0. As part thereof 'Advanced DOS 1.0', or MS-DOS 4.0 as it was called by now got scrapped right after its first, limited release. Refocusing development onto OS/2, its first line, dubbed 1.x, replacing 'Advanced DOS' as the multi-tasking text-based follow up to MS-DOS, while 2.x was intended to replace Windows ... but that's another story.

This was also the point when MS-DOS turned into PC-DOS including various levels of hardware dependence.

While Microsoft adapted PC-DOS 4.0 and rewrote large parts as MS-DOS 4.01, there was no consumer version sold by MS. Only OEM versions. Including versions for 100% non-IBM-compatible computers like the 80186 based Siemens PC-D (*2). The 'OEM Adaption Kit' was now call 'Binary Adaption Kit'.

The next consumer version offered was MS-DOS 5.0 two years later. It seems to be the last where some form of OEM version has been made, beyond changing some display strings. Wikipedia names this AST Premium Exec DOS 5.0, but from the listed changes (in wiki and other sources) this looks rather restricted to drivers and utilities.

Essentially the need for custom DOS versions had ended around 1991/93, the same way really non-compatible machines have vanished. On one hand, even the last slightly-off machines like some Zenith, Amstrad or Tandy provided basic hardware compatibility at least for screen addresses and modes, while on the other hand faster CPUs and Windows as abstraction layer virtualized the last need for hardware compatibility by moving it into Windows drivers.

DOS 5 also marks the entry of IBM in the retail market with DOS 5.0.1. While IBM did adapt most MS changes from MS-DOS 6.0 into PC-DOS 6.1, development did split up again and this time for good. What happened afterwards is another story (*3).


Bottom Line

Yes, MS_DOS was, at the OS level, always machine independent, but at distribution level, with ever decreasing demand for specific distributions, it became more and more a blurry distinction with PC-specific being the last to survive.


*1 - Interestingly based on Microsoft's DOS Manager made for the less compatible Zenith EazyPC.

*2 - Although Siemens made that version available only to institutional customers with a large installed base of PC-D systems. Possibly due to the fact that they switched their PC production (mostly) to 100% compatible machines (PCD-2) based on a Tandon design in late 1986.

*3 - While MS turned it slowly into a support tool for Windows (some hacks are known to turn that back into a stand alone DOS), IBM maintained DOS until at least 2003 as such.

5
  • 1
    It might be worth mentioning that the BASIC.COM and BASICA.COM that were included on IBM-DOS disks would not run on anything other than IBM PC computers, since only IBM computers had a licensed Microsoft BASIC interpreter in ROM that those programs could path.
    – supercat
    Oct 9, 2022 at 16:23
  • @supercat which simply makes them hardware related utilities - the same way FDISK is.
    – Raffzahn
    Oct 9, 2022 at 16:25
  • 2
    BASIC is a somewhat different discussion anyway; IIRC OEMs could license MS-DOS without GW-BASIC if they wanted to, and some manufacturers highlighted “with GW-BASIC” in their adverts (but I don’t think I’ve ever seen a non-IBM MS-DOS system without GW-BASIC). Oct 9, 2022 at 16:35
  • @Raffzahn: I suppose in the days before hard drives, people may have gotten to experience the difference between an IBM PC that would launch into Cassette BASIC if the floppy drive is empty, and other machines which would display an "Insert bootable disk" message, but I doubt people would have thought of BASIC or BASICA as "hardware-related utilities" that add features to the already installed but useless Cassette BASIC. In retrospect, I find it somewhat suprising that IBM didn't display a message asking whether people wanted to launch cassette basic or retry booting, since...
    – supercat
    Oct 9, 2022 at 18:17
  • ...it would have been far more common for someone to accidentally have a drive door open when rebooting than to want to run Cassette BASIC on a floppy-based system, and the partial self-test that would happen after hitting control-alt-del from within BASIC would add significantly to the time to boot a floppy once the problem was fixed.
    – supercat
    Oct 9, 2022 at 18:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .