Mark Williams' C Programming System
What C did for Programming Mark Williams has done for C Programming
I previously covered the history of the Mark Williams Company when I wrote about their Coherent operating system (basically a clone of UNIX). You can read about both here. Today, we’ll focus on their C programming tools.
When the Mark Williams team wrote their operating system, they created their own C compiler. That compiler was included with Coherent when it shipped. They then ported the C compiler to other systems, including Unix, DOS, and Atari. The Mark Williams company also packaged the compiler with a debugger and called the new package the C Programming System. (They also shipped a cut-down version of the C Programming System named Let’s C.)
The August 1986 issue of Dr. Dobb’s Journal looked at a bunch of C compilers, including the C Programming System. Here is their review:
Mark Williams Co. has been around for quite a while and has established a good reputation for its Unix-like operating system and its C compiler. The C Programming System compiler is in the “heavyweight” class and is priced accordingly. It includes several 8087 support options and large/ large-memory-model support. It comes with a full source-level debugger, two editors (including full source code for MicroEMACS—an EMACS subset), and several utility programs. CSD, the source-level debugger, is powerful but can be used only with the Mark Williams object format, which in turn can be used only for small/small-model programming.
C Programming System comes with a total of five disks and two IBMsize manuals in the usual D-ring binders with slipcases. The manual section on installing the compiler applies to the company’s Let’s C, which is a little disconcerting. The release notes in front of the manual cover installation of C Programming System. Although a list of files on the distribution disks is given, the list does not describe what each file is.
A large number of compiler options are available to turn on (or off) various categories of warning messages, which can prove useful. There are no options for controlling compiler optimization strategies as there are in most heavyweight compilers. There is an option that causes a different version of the start-up and exit code to be linked in that can produce smaller .exe files if you don't need the standard I/O package. The compiler also has options that cause it to generate code specifically for 80186 and 80286 processors.
The documentation is professional and includes a good table of contents and an index. The language reference material is simply a list of differences from K & R. The library reference is complete but perhaps a little too concise and does not include examples.
The manuals do have some confusing inconsistencies. The release notes, for instance, indicate that MASM (the Microsoft assembler) should be on your program disk if you want to use Microsoft object format, but it is not clear why. We did not need MASM to compile and run any of the benchmarks. The section on the assembler claims that the large model will be discussed, but it isn't. The assembler option to generate Microsoft object format is described as causing small-model object to be generated.
Mark Williams’ C Programming System has little to recommend it over its competitors and its debugger is no longer unique.
The PC Tech Journal compared C compilers in an article entitled “The State of C” by William J, Hunt. They had this to say about the C Programming System:
The star of this package is its source-level debugger, which has an excellent user interface. The manual provides a tutorial on the basic concepts and a plastic template is included, eliminating the need to memorize debugger commands. Single PC function keys are used for the commands and C source code around the current program counter location is automatically displayed. Separate copies of the screen are kept for source code display and for program output so that screen output need not interfere with normal debugger display. Using this debugger is very much like using a good screen-oriented text editor.
Yet, while the debugger’s interface is very good, it has limited capabilities. Breakpoints cannot be set on library functions and no facilities for debugging assembly language functions are provided. Its features are much less convenient for debugging programs composed of more than one source file. Finally, the debugger sometimes loses console output from C programs.
The Mark Williams assembler does not support macros, and its assembly language format is very different from MASM’s. Rewriting assembly language source files from MASM to fit the Mark Williams format is tedious; every line must be altered. This assembler’s format is similar to that of the UNIX assembler, an advantage to the user with many UNIX 8086 assembly language source files. If, however, most of a user’s source files are in the MASM format, the Mark Williams assembler may be more trouble than it is worth.
The compiler can invoke the Mark Williams linker as part of a single compile and link command; the linker is rather complicated to use directly. Because the linker supports only the small memory model and is slower than DOS LINK, it adds little value to the product.
The library contains the standard C functions and general PC-specific functions (port I/O, memory access, software interrupt gate function). Few functions for specific DOS, BIOS, or PC hardware services are included.
The manual covers the compiler itself, the Mark Williams assembler and linker, and the source level debugger. It is poorly organized and fails to cover important topics such as memory layout, setting the stack size, and console and device I/O. Neither the table of contents nor the index is much help in locating answers to practical questions. Usage of the MASM assembler and the DOS linker with the Mark Williams compiler is also poorly documented.
Its compile times are good for a production compiler. Link times with its own linker are slower than for other compilers. Its execution results for the sieve benchmark are good, but its other times (those for function calling and integer and long-integer arithmetic, for example) are worse than average.
The various parts of the Mark Williams package are not well integrated. The source level debugger works only with .EXE files created with the Mark Williams linker. But 8087 support and the large memory model require that files be linked with the DOS linker. The manual’s information on the use of MASM and the DOS linker is limited. The Mark Williams package ($495) is a potentially attractive product, but more attention should be given to detail.
Byte Magazine announced the release of the C Programming System for the Atari ST in 1986:
Mark Williams Company's C Programming System for the Atari ST features a complete implementation of Kernighan and Ritchie (plus recent extensions to the language) and UNIX-compatible libraries. Along with utilities such as make, diff, cmp, sort, wc, and egrep, the package provides an interface to GEM'S AES and VDI libraries, an assembler, a loader, and an archiver.
A shell provides a UNIX like environment and supports I/O redirection, pipes, variable substitutions, history substitutions, and path search capabilities. The full-screen editor is based on EMACS.
The C Programming System for the ST costs $179.95. It requires two double-sided floppy disk drives (or one floppy and one hard disk). Contact Mark Williams Co. 1430 West Wrightwood Ave. Chicago. IL 60614. (312) 472-6659
If you are interested, Archive.org has a couple of archived versions of the Mark Williams' C compiler for the Atari ST.
Did you ever use Mark Williams' C Programming System? Do you know anything about its history? Tell us about it in the comments below.
What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.
I used MWC a bit on the Atari ST back around 1990 or so. It was a good system, but being so command-line focused, I preferred Prospero C or the much faster Laser C from Megamax.