"MS-DOS Compatible" Software

[NeXT]

I'm trying to hunt down enough programs to sample how "IBM PC-Compatible" and "MS-DOS Compatible" software looked and behaved and for obvious reasons I'm having a royally hard time filtering results out. Even products from Microsoft at the time are tough to tell from the label if they were following Microsoft's own spec for making software compatible. MASM 5 goes pretty far into avoiding using "PC Compatible" on the box, but then internally makes calls to CGA for color in the editor menus which means it's a no-go for systems that don't follow IBM's CGA spec. I do know of a few programs that "install" by making you select from a text-only menu what machine or video hardware is present so it loads the correct modules but so far it's been for PC compatible systems and I'm sure the same had to exist for non-PC compatible systems but I've had no leads so far.

 

[krebizfan]

Wordstar 3 had a setup menu for all the special characteristics to tailor for non-PC compatible systems. The PC version had the internal tables filled out as did any other machine specific release.

 

[Eudimorphodon]

I think the problem you're going to run into is there just isn't that much pure "MS-DOS Compatible" software in existence.

Strictly speaking "MS-DOS Compatible" means you're limiting software solely to the INT 21h API that's a copy of the CP/M API, which has like four text I/O calls that in and of themselves are suitable for nothing more sophisticated than an endless-scrolling teleprinter. As @krebizfan describes re: Wordstar, any program that limits itself entirely to this API that wants to do sophisticated screen handling (by "sophisticated" I'm setting the bar *extremely* low, IE, simple things like cursor positioning) needs to handle it by generating control character sequences which the "terminal" interprets. (Of course on a computer with a built-in display instead of a serial attached terminal the system BIOS needs to interpret these codes. Most computers have at least rudimentary support for processing character codes/ESC sequences for forward/back cursor movements, home/clear, vertical tabs, etc.)

This... actually points to a trap that IBM built into the PC: if you don't have something like ANSI.SYS installed the PC has very little in the way of built-in terminal emulation. I think it supports little more than CR, LF, BELL, TAB, and backspace(?), you have to hit the INT 10h BIOS API directly for anything more sophisticated. If that memory is correct then it's basically impossible to do something like Wordstar on the PC *solely* through INT 21h. This might be the deepest schism you're going to run into for programs that run on some of the oldest/least compatible MS-DOS systems; typically the designers of these systems would at least give their terminal emulators as much functionality as your typical CP/M machine might have (IE, emulate something like an ADM-3A) so you at least had basic screen positioning, while on a PC I don't think you have any choice other than hit the BIOS lock-in. And this is why many of these first MS-DOS machines, along with the next round of slightly more compatible ones (Tandy 2000, Sanyo MBC-550) got memory-loadable "PC Emulation" packages that implemented chunks of the PC BIOS calls. (I've been focusing on console handling, but these PC compatibility packages would often also include hooks for things like serial port and timer calls, because these are also things the pure DOS API lacks.)

So... I guess it might help to know what kind of a machine you're trying to target here. I've ran into a few bits of software over the years that had options for configuring them to use BIOS calls instead of direct hardware writes (I think "Varsity Scripsit" for the Tandy 1000/2000 was one of these, but it's been a while, along with a version of the aforementioned Wordstar), but these will still limit you to machines that have a PC BIOS compatibility layer. I suspect you're going to find it hard to find "pure" MS-DOS INT 21H-only software beyond command-line driven programs like languages/compilers that weren't sold already customized for whatever non-PC-compatible MS-DOS computer they were intended for. (IE, they come out of the box already set up for an NEC APC/Wang/Victor 9000/whatever.)

 

[Quagmire]

I think the problem you're going to run into is there just isn't that much pure "MS-DOS Compatible" software in existence.

Strictly speaking "MS-DOS Compatible" means you're limiting software solely to the INT 21h API that's a copy of the CP/M API, which has like four text I/O calls that in and of themselves are suitable for nothing more sophisticated than an endless-scrolling teleprinter. As @krebizfan describes re: Wordstar, any program that limits itself entirely to this API that wants to do sophisticated screen handling (by "sophisticated" I'm setting the bar *extremely* low, IE, simple things like cursor positioning) needs to handle it by generating control character sequences which the "terminal" interprets. (Of course on a computer with a built-in display instead of a serial attached terminal the system BIOS needs to interpret these codes. Most computers have at least rudimentary support for processing character codes/ESC sequences for forward/back cursor movements, home/clear, vertical tabs, etc.)

This... actually points to a trap that IBM built into the PC: if you don't have something like ANSI.SYS installed the PC has very little in the way of built-in terminal emulation. I think it supports little more than CR, LF, BELL, TAB, and backspace(?), you have to hit the INT 10h BIOS API directly for anything more sophisticated. If that memory is correct then it's basically impossible to do something like Wordstar on the PC *solely* through INT 21h. This might be the deepest schism you're going to run into for programs that run on some of the oldest/least compatible MS-DOS systems; typically the designers of these systems would at least give their terminal emulators as much functionality as your typical CP/M machine might have (IE, emulate something like an ADM-3A) so you at least had basic screen positioning, while on a PC I don't think you have any choice other than hit the BIOS lock-in. And this is why many of these first MS-DOS machines, along with the next round of slightly more compatible ones (Tandy 2000, Sanyo MBC-550) got memory-loadable "PC Emulation" packages that implemented chunks of the PC BIOS calls. (I've been focusing on console handling, but these PC compatibility packages would often also include hooks for things like serial port and timer calls, because these are also things the pure DOS API lacks.)

So... I guess it might help to know what kind of a machine you're trying to target here. I've ran into a few bits of software over the years that had options for configuring them to use BIOS calls instead of direct hardware writes (I think "Varsity Scripsit" for the Tandy 1000/2000 was one of these, but it's been a while, along with a version of the aforementioned Wordstar), but these will still limit you to machines that have a PC BIOS compatibility layer. I suspect you're going to find it hard to find "pure" MS-DOS INT 21H-only software beyond command-line driven programs like languages/compilers that weren't sold already customized for whatever non-PC-compatible MS-DOS computer they were intended for. (IE, they come out of the box already set up for an NEC APC/Wang/Victor 9000/whatever.)

IIRC, some apps from back then would have you modify your CONFIG.SYS & AUTOEXEC.BAT accordingly. Some required ANSI.SYS and HIMEM.SYS and so forth.

 

[NeXT]

I think the problem you're going to run into is there just isn't that much pure "MS-DOS Compatible" software in existence.

This tracks with my observations. There was a few really early DOS titles that were mainly text-only ports from CP/M (WordStar) but once IBM became de-facto, compatibility was abandoned in favor of direct performance.

So... I guess it might help to know what kind of a machine you're trying to target here. I've ran into a few bits of software over the years that had options for configuring them to use BIOS calls instead of direct hardware writes (I think "Varsity Scripsit" for the Tandy 1000/2000 was one of these, but it's been a while, along with a version of the aforementioned Wordstar), but these will still limit you to machines that have a PC BIOS compatibility layer. I suspect you're going to find it hard to find "pure" MS-DOS INT 21H-only software beyond command-line driven programs like languages/compilers that weren't sold already customized for whatever non-PC-compatible MS-DOS computer they were intended for. (IE, they come out of the box already set up for an NEC APC/Wang/Victor 9000/whatever.)

You are very much on the same track as I'm working on. The MS-DOS compatible machines I working to demonstrate with was the Rainbow 100 (text and graphics), Wang Professional Computer (text only), Canon AS-100 (text and color, plus graphics) and the Victor 9000 (text and graphics). Each system can support graphics at the very least if the software hooks into the DOS drivers supplied by the computer vendor, but my research so far found this came about too late for anyone to bother because the PC was already high in the atmosphere in terms of popularity.

 

[Eudimorphodon]

IIRC, some apps from back then would have you modify your CONFIG.SYS & AUTOEXEC.BAT accordingly. Some required ANSI.SYS and HIMEM.SYS and so forth.

By the time HIMEM.SYS came along of course all the not-PC-compatible MS-DOS machines were dead and gone, but I do kind of wonder if the only reason ANSI.SYS exists was a (last-ditch?) attempt to salvage the idea of machine-independent MS-DOS.

DOS 1.x didn't have it (or any installable device drivers), on the PC it just passed the DOS CP/M console output to the INT 10h "teletype" call (that has that very limited set of ASCII control codes it answers to). DOS 2.0 introduced ANSI.SYS, which when installed gives a PC a terminal that's baaaaasically a VT-100, if you wrote a program targeting it then in theory at least it should run on any other MS-DOS computer that either also has a compatible ANSI.SYS or a physical ANSI-compatible terminal set up at the console. DOS 2.x was basically the last hurrah of the non-PC-compatible clones, I don't actually know if any of them (other than the Japanese ones like the APC-III/PC-98 family?) ever got DOS 3.x ported to them.

Downside of ANSI.SYS is it's slower than snot, which helps explain why there *isn't* much commercial software going that route. (It only uses the PC BIOS calls, and said calls *suck* performance-wise, which is why PC BIOS compatibility usually isn't enough either, you need to physically have hardware compatibility with CGA or MDA for soooo much PC software.)

 

[Makefile]

Would many command-line filter utilities fall into this category even if accidentally?

 

[JohnElliott]

I wrote GEM video drivers for the Wang Professional Computer and the Apricot Xi (since I couldn't find the original at the time; it's since shown up). GEM doesn't ask much from a host system; it doesn't depend on the internals of DOS (which is why it works on DOS Plus) and all the system-dependent code is in the video driver. [The Sanyo MBC-55x is an exception, because it uses INT 0EFh so that would need relocating to free it up for GEM].

 

[Eudimorphodon]

If there's a version of Windows 1.x for your non-PC MS-DOS computer I think you should also have *reasonable* luck moving well-behaved software around? But... how many machines did Windows 1.x actually exist for? Digging around... it looks like you've got the Tandy 2000, Zenith Z-100, HP-150... oooh, there's also a semi-unofficial DEC Rainbow port!

(The HP-150 version *especially* looks like fun, it has a driver for that machine's goofy low-res touchscreen.)

There is of course almost zero software for Windows 1.x (significantly less than GEM?), but I suppose if you're a glutton for punishment it might be "interesting" to try moving programs around between them.

I wrote GEM video drivers for the Wang Professional Computer and the Apricot Xi (since I couldn't find the original at the time; it's since shown up). GEM doesn't ask much from a host system; it doesn't depend on the internals of DOS (which is why it works on DOS Plus) and all the system-dependent code is in the video driver. [The Sanyo MBC-55x is an exception, because it uses INT 0EFh so that would need relocating to free it up for GEM].

Are there any other interesting oddballs that have GEM drivers? Looks like there might have been a Tandy 2000 version, but kind of striking out otherwise.

 

[Quagmire]

By the time HIMEM.SYS came along of course all the not-PC-compatible MS-DOS machines were dead and gone, but I do kind of wonder if the only reason ANSI.SYS exists was a (last-ditch?) attempt to salvage the idea of machine-independent MS-DOS.

DOS 1.x didn't have it (or any installable device drivers), on the PC it just passed the DOS CP/M console output to the INT 10h "teletype" call (that has that very limited set of ASCII control codes it answers to). DOS 2.0 introduced ANSI.SYS, which when installed gives a PC a terminal that's baaaaasically a VT-100, if you wrote a program targeting it then in theory at least it should run on any other MS-DOS computer that either also has a compatible ANSI.SYS or a physical ANSI-compatible terminal set up at the console. DOS 2.x was basically the last hurrah of the non-PC-compatible clones, I don't actually know if any of them (other than the Japanese ones like the APC-III/PC-98 family?) ever got DOS 3.x ported to them.

Downside of ANSI.SYS is it's slower than snot, which helps explain why there *isn't* much commercial software going that route. (It only uses the PC BIOS calls, and said calls *suck* performance-wise, which is why PC BIOS compatibility usually isn't enough either, you need to physically have hardware compatibility with CGA or MDA for soooo much PC software.)

True, ANSI.SYS may have been slow but it was great for the DOS users when ESC sequences came part of your text. No one really questioned speed back in those days, even gamers.

 

[vwestlife]

Excluding the Japanese NEC PC-98 series, were there any non-PC-compatible MS-DOS machines that had a version of MS-DOS 3.x or higher? All the ones I know had MS-DOS 2.11 at the latest, sometimes with incremental updates and bug fixes added even after DOS 3.0 became available for regular PCs.

 

[SomeGuy]

Off hand, The HP 150 has DOS 3.2, and there is a 3.10 for Zenith Z-100, DEC Rainbow also had 3.10.

 

[JohnElliott]

Are there any other interesting oddballs that have GEM drivers? Looks like there might have been a Tandy 2000 version, but kind of striking out otherwise.

There are also known GEM video drivers for the Apricot F-series, and the BBC Master 512. (In the 68000 world, the original builds of GEMDOS / GEM for the Apple Lisa survive. The source release also contains references to the Motorola VME/10 but I don't think it contains full source to build a driver for that).

 

[Martin Hepperle]

Most of the early programs for MS-DOS were born on CP/M. They were all text based and used escape sequences to control cursor positioning, attributes et cetera. CP/M was designed for terminals.

Besides the programs already mentioned, the Math software "Derive" detected the platform and if it did not find a known one, it presented a list of terminals/computers to select from:

1 = Other generic MS-DOS computer
2 = IBM PC compatible computer
3 = ANSI.SYS screen or VT-100 Terminal
4 = TI Professional Computer
5 = Zenith Z-100 Computer or VT-52 Terminal
6 = Hewlett-Packard HP-150 Computer
7 = Hewlett-Packard HP-110 Computer
8 = NEC Advanced PC or ADM-3A Terminal
9 = NEC PC-9801 Computer
A = Fujitsu Computer


Similar to Turbo Pascal 3.x which used a separate installer program to select a terminal or define your own escape sequences. Turbo-Pacal embeded these sequences into its runtime library, so that GotoXY() and similar functions used the defined escape sequenbces.

The Turbo-C GUI is IBM-PC compatible, but the command line compiler TCC and the linker TLINK are MS-DOS compatible. Same for Microsoft compilers, linkers and tools until today which always exist as command line versions.
MASM 5.x also was a MS-DOS compatible command line tool. The infamous "M"-editor which was supplied as an additional tool by Microsoft was a generic text editor for IBM-PC compatibles.
A faster replacement for ANSI.SYS was the widely used NANSI.SYS.

 

[JohnElliott]

Mallard BASIC was a CP/M port so the DOS version can also be configured to use escape sequences to move the cursor (default behaviour as shipped is to use INT 10h)

 

[Martin Hepperle]

... not to forget: for the Lattice "C" compiler there was also an add-on product, the TIP "Terminal Independence Package" library. This encapsulated cursor positioning commands and the like. It used external files for configuring the escape sequences for terminals. Thus, it was possible to select the terminal at runtime, very similar to the way it was done in some Unix libraries like curses.
But of, course, the speed of using INT 10h and especially direct access to screen memory could not be reached with these layers.

 

[krebizfan]

DEC's WPS and Rainbow Office Workstation* products were originally moved to the Rainbow before revised versions were available to run on PC compatibles. I think HP did something similar with the calculator emulators afforded to the HP-150 before replacing them with ones that could run on a PC compatible. Probably more software that was exclusive to a non-PC compatible before that company released its own PC clone. If search wasn't so broken, it would be easy to find press releases on Infoworld declaring when each one got a PC followup.

* This tied into VAX All-in-1 somehow. I don't know how it relates to PC All-in-1 released a few years later.

 

[araxestroy]

The readme from the OAK for MS-DOS 3.2 (I believe; it was posted by OS/2 Museum about a decade ago) mentions that the baseline terminal of sorts for non-IBM PC compatible MS-DOS was a Zenith Z-19/Heathkit H-19, which I believe is functionally a VT52 clone that can operate in either VT52 or ANSI mode, and the MS-DOS OAK assumes ANSI mode.

 

[Makefile]

Perhaps Kermit (https://www.columbia.edu/kermit/ftp/mskermit/msaaaa.txt) is the most complex piece of software designed to support various DOS-compatibles?

AP3 - NEC APC-3
APC - NEC APC
APR - ACT Apricot
DM2 - DECmate II or III with MS-DOS Option
GEN - "Generic" MS-DOS (DOS calls only)
GRI - Grid Compass II
HP1 - HP-150
HPX - HP-110 and HP Portable Plus
IBM - IBM PC and PS/2 families
MBC - Sanyo MBC-550
P98 - NEC PC 9801 (Japanese Kana/Kanji version)
RB1 - DEC Rainbow-100 series
RB2 - DEC Rainbow-100 series (special VT220 emulating version)
RMX - Intel 300 Series with iRMX-86
SEE - Seequa Chameleon
TIP - Texas Instruments Professional
V90 - Victor 9000 (Sirius 1)
V9T - Victor 9000 (Sirius 1) with Tektronix emulation
WNG - Wang PC
Z10 - Heath/Zenith 100

 

[Svenska]

I've been focusing on console handling, but these PC compatibility packages would often also include hooks for things like serial port and timer calls, because these are also things the pure DOS API lacks.

Basic serial port support is available through the COMn virtual files, and a vendor-supplied MODE program to set the communication parameters. I'm not sure about timing support, but you definitely won't get timer interrupts into your application.

DOS 2.x was basically the last hurrah of the non-PC-compatible clones, I don't actually know if any of them (other than the Japanese ones like the APC-III/PC-98 family?) ever got DOS 3.x ported to them.

The Philips :YES got both DOS Plus and MS-DOS 3.10. But it does implement a fair amount of IBM compatible interfaces in its BIOS, and provides VT52 and VT-100 terminal emulation.

By the time HIMEM.SYS came along of course all the not-PC-compatible MS-DOS machines were dead and gone, but I do kind of wonder if the only reason ANSI.SYS exists was a (last-ditch?) attempt to salvage the idea of machine-independent MS-DOS.

Later on, ANSI.SYS (and its replacements) became relevant for the BBS world. Interfacing a PC to any form of Unix system or mainframe also requires some terminal emulation, so it makes sense to provide a generic driver. Microsoft was active in Unix, so they probably had some need for it, too.