Vrftsjtryk

I refer here to 'screen-based programs' that are not actually graphical, but take full advantage of the screen as a two-dimensional array of 80x25 characters, as opposed to typical 'command-line programs' whose output is essentially one dimensional.

MS-DOS provided compatibility for command-line programs. A single binary could run on many different and incompatible computers, provided they all ran MS-DOS.

MS-DOS did not provide compatibility for screen-based programs. In theory it did but in practice it didn't; the screen display routines provided by the operating system were so slow that we all wrote directly to video RAM instead, which meant our programs would only run on an IBM PC or clone.

CP/M was in a sense the precursor of MS-DOS. Did it provide practical compatibility for screen-based programs? Could CP/M versions of programs like VisiCalc and WordStar provide a single binary that would run on any Z80 machine with CP/M, or did they have to be reassembled or modified for each incompatible computer?

Two-dimensional positioning was not provided by basic CP/M; the BIOS provides only a single-character console output call, and does not define any control characters. Furthermore, unlike MS-DOS there was never a dominant hardware configuration behind CP/M so going straight to hardware wasn't an option.

In practice programs tended to ship with support for a variety of popular terminals — the Hazeltine, the ADM3a, the VT52, etc — and a setup utility to pick your display type. In implementation terms, that usually didn't require much more complexity than substituting the proper control codes. Programs were supplied as a single binary and small amounts of data were modified by the setup utility.

The problem is essentially the same as that solved by the termcap database in UNIX, but with each program providing its own solution.

A later CP/M extension, GSX, provided hardware-independent graphics display and developed into the virtual device interface underlying GEM, but was far too late to make a substantial impact.

Sample setup, from Turbo Pascal; upon launch TINST the user may configure either the screen or commands (i.e. keyboard control codes):

Output support is pretty wide:

All supported by the single binary in a single distribution, of less than 132kb in size (including sample programs).

Input selection is no more complicated than asking the user to press the keys they want:

It goes on a while — that's just the first screen.

This was the key concept of an Operating System

Could CP/M versions of programs like VisiCalc and WordStar provide a single binary that would run on any Z80 machine with CP/M, or did they have to be reassembled or modified for each incompatible computer?

In the Linux (and previously Unix) world, it is quite common to distribute libraries, languages, applications, etc. as source code. That works well because on the one hand, it helps to handle differences in system architecture (32-bit vs. 64-bit, x86 vs. Arm, etc.) and on the other hand, the systems are big enough to easily include compilers, the compilers are (for all practical purposes) open-source and included (or easily added) and the systems are fast enough (at least these days) to compile and link almost anything in a matter of minutes, often just seconds.

That wasn't the way things worked back in CP/M days. If you wanted to compile something, you needed to buy the right compiler, on the right disk format, and swap a bunch of floppies to get things done. Not practical for mass market software.

On the other hand, as with MS-DOS, Unix/Linux and other newer operating systems, CP/M did provide a full layer of abstraction to hide all the details of access to standard devices - this includes disks, terminals, printers, etc. The actual codes to be sent to terminals and printers would vary, of course, as did floppy disk formats (# and size of sectors, etc.), but the CP/M function calls were the same on any system, from Altair to Zenith. This was, arguably, the biggest advance of CP/M for the microcomputer world, as it avoided the need to load source code (whether by typing or on paper tape or eventually floppy disk) and then (hopefully) compile it on/for the target system. Instead, the most you had to do was convert a physical disk format - and there were service bureaus that could do that if the software manufacturer couldn't provide your preferred format.

As far as text display speed on MS-DOS, it was often much worse with CP/M. Typical terminal speed was 19,200 bps or even 9,600 bps. But compared to the common alternative of a 300bps modem connecting to a minicomputer, it was super fast.