Programming tools did not come bundled with the Macintosh.  This was a break from tradition, because even as late as 1984, microcomputer purchasers were largely amateur or professional programmers, and a computer was not a complete product without some kind of programming capability.  Apple promotional materials were clear on this matter, and did not try to market the Macintosh to programmers. Luckily for Apple, this did not work, and there was an outpouring of interest in programming the Mac. The absence of bundled programming tools provided an opportunity for third parties.   Over the first 3 years after its introduction, the market for programming tools for the Macintosh blossomed.  The unique user interface of the Macintosh caused an explosion of creativity in the design of software of all kinds, and programming software was no exception.  Even Apple turned to third party developers to create developing tools sold under their name.  The first ones were an assembly language system, the 68000 Macintosh Development System, and MacPascal. I’ll talk about MacPascal and its offspring another day. 

The 68000 Macintosh Development System

    The first programming system for the Mac that I know of was Apple's 68000 Macintosh Development System (called MDS).  This product was created for Apple by Bill Duvall and his company, Consulair.  Duvall had worked with Doug Engelbart on the revolutionary NLS, the original networked information system, had been at PARC and contributed to Smalltalk.  He had been a participant in the first ARPAnet network communication, that led to the internet.  Duvall was a pioneer in many aspects of the computer revolution, including user interface issues, and so understood the philosophy and the practical application of the Macintosh.  He also had experience with creating programming tools for the motorola 68000 processor, used in both the Lisa and the Mac.  Duvall's company, Consulair, created the MDS for Apple, who marketed the system of programs late in 1984. 

It consisted of 4 separate programs, an editor (Edit), an assembler (Asm), a linker (Link), and a batch file processor (Exec).  The system was intended to work in concert with Andy Herzfeld's resource creation program (RMaker), which was an Apple product and was shipped as part of the suite.  Exec was a much simpler version of a program of the same name that was part of the Lisa Workshop.  It allowed a programmer to specify the files that should be assembled, libraries and resource files to be linked, and it would evoke Asm, Link, and RMaker to do a complete build of the program. An essential part of this process was the definition of a file format for object files, and MDS introduced the .Rel file format, which became the first standard for the Mac.  One peculiarity of the Macintosh was the fact that executable code in a finished application was stored in the form of a set of resources in the resource fork.  Resources were designated by a four character type designator, and by an id number.  The executable code for a program was packaged by the linker into 32KB (or smaller) segments, each of which was put in its own CODE resource.  Branches within a segment were done using the short branch instruction.  If code in one segment (resource) needed to branch to an entry point in another one, it did it by way of a jump table that was created by the linker and was stored in the first CODE resource.  The intermediate object code created by the Assembler was stored in the data fork of the .Rel file.  Resources could be created in assembly language using a syntax created for that purpose, or could be created using RMaker.  RMaker was best suited for the last step in the build process, in which the code resources were added to the file containing all the other resources that make up a program, including specifications for windows, cursors, icons, and all the rest.  But the MDS link program could do this task as well.

Mac C

    It was a natural next step to make compilers that could generate assembly language that could be read by the MDS assembler, or could create object files in the .Rel format. 

Who was in a better position to do this than Consulair, who announced a C programming environment of this kind in early 1985.  The Consulair Mac C programming system included the same Edit, Asm, Link and Exec programs included in Apple's MDS, but added a C compiler (called C).  In addition, the system included a small C runtime, and a set of the most often used parts of the standard C library.  The standard C library consisted largely of functions used to interact with a terminal (like getc and printf), and so Consulair C included an optional terminal window that was opened by the C runtime code.  The source code for all the Consulair libraries was supplied with the system, so programmers could modify it or use it as a tutorial on how to do things in C on the Macintosh.  There was also some some very useful example code.  Example programs were important because programming for the Macintosh included some very new ideas for most programmers, and example code in C was not otherwise available.  I'm sure that many early Macintosh programs started out as modified versions of the Consulair C example programs.  The only functions in the standard library supplied with Consulair Mac C without source code were  and Str2Dec, and Dec2Str, which were the property of Apple Computer, and were distributed with their permission, but without sources.

400K was barely enough disk

    The MDS and the early versions of Consulair Mac C were products of the 64K ROM era.  That was the version of the ROM supplied with the 128K and 512K Macintosh.  Much of the operating system was embedded in the ROM.  This was very important because that part of the operating system did not have to be read into memory from the slow-moving 400K 3.5" diskette that was the only disk storage of the early Macintosh.  Storing big parts of the operating system in ROM also saved precious space in RAM.  The version of the file system in the 64K ROM was not hierarchical.  That is, there were just volumes (corresponding to diskettes) and files.  No directories.  There were folders that you could see in the Finder, but they did not figure into the specification necessary to open, close, read or write to a file on diskette.  File paths were therefore simple, consisting of something like "diskName:fileName".  Even if you had only one disk drive, you could have a couple of disks mounted, and if a program tried to access a mounted disk that was not inserted in the drive, it would eject the current disk (without dismounting it) and prompt the operator to insert the disk that was needed.  It was tricky to compile a program, because at a minimum you needed a system file, C, Asm, Link, RMaker and Exec, the libraries you were going to link in, and your source code.  All this had to fit one diskette, or you were going to develop a serious case of Macintosh elbow swapping diskettes to get you through the build.  A copy of the Finder was not really essential, because of the transfer menu.  Consulair programs had a transfer menu that allowed the user to launch any program.  As a result, you could in practice dispense with the Finder.  The Mac OS insisted that some program be named Finder, and it would launch that program by default after booting and whenever the user quit a program.  But you could name any program Finder and use it as the default.  So you could change the name of Edit to Finder, and use it as the default program, employing its transfer menu as a launcher. 

    Mac C came with a ram disk program (created by George A. Nelson), called RamStart, that could be used to put some files a virtual disk in RAM, and so minimize disk-swapping.  Even with these adaptations, development with Mac C on a 128K Macintosh was a real challenge, because there wasn't much room in RAM to do the compilation after some of it was taken for a ram disk.  In some configurations, Mac C would use some of the video ram for compilation, so that during the compile the bottom half of the screen would fill with noise ("snow").  Mac programmers were familiar with this happening because of errors in programs that caused them to erroneously access the screen buffer.  In those cases, the sound buffer was often also overwritten, resulting in some crazy noisy sound accompanied by noise on the screen.  This was called a "Snow Crash".  But Mac C was the only program I know of that did this kind of thing under normal operation.  On a 512K Macintosh, it was possible to allocate more than 300 Kbytes of RAM as a virtual disk, and compile programs from a single diskette.

Dude, where's my file?

    The introduction of the 128K ROM in the Macintosh 512KE and the Mac Plus gave us 800KB diskettes, and a new file system (HFS) that included a hierarchy of directories.  File paths now had to look like myFile:outerDir:nextDir:...:myFile.  Directories could be nested arbitrarily. It was possible to use diskettes that were formatted in the old file system (MFS), and so MDS and Mac C did not automatically quit working with the new machines and the new versions of the System File that they used (System File version 3).  But most programmers were yearning to use the relatively fast and large SCSI hard disks that became available after the addition of the SCSI port on the new machines.  These required the new file system.  Unless all the files of all kinds used in the build were at the root of the file system, they would not be found and the build would fail. 

  The main problem for with HDF for a programming system is knowing where programs should to look for includes, libraries, and other programs, and knowing where to write its output files.  There are basically two strategies available.  One is to insist that the user employ a standard directory tree.  The other is to maintain environment variables that allow users to tell the system where they want these things to go.  Unix has employed both methods, but generally include files are kept in just a couple of places (/usr/include and /usr/local/include) and likewise for libraries (/usr/lib and /usr/local/lib).  This was anathema to the Macintosh approach, which had no standard directories other than the System Folder.  The Consulair system allowed (required) programmers to define a set of search paths, for libraries, for includes, for the linker to look for .Rel files generated by the compiler, for temporary files, etc.  All paths were defined relative to a few known places, the boot directory (the active System Folder), the Desktop, the directory containing the running program, and the directory containing the source file being edited, compiled or linked.  A sequence of paths to be searched for each thing (libraries, programs, include files, etc) was specified in a special text file, which was then compiled into a resource by a program called Path Manager, and the resulting resource (Paths.rsrc) was placed in the System Folder.  All Consulair programs opened this resource file and used it to find everything.

Automated Builds

    The MDS linker expected to read a batch file that included a list of object files that should be included in the built program.  The Exec program could read a similar file that consisted of just a series of lines starting with the name of a program, a source file to pass to that program, and a program to run after that ran successfully (usually Exec again), and another program to run if there was an error (usually Edit, so you could read the file with the error messages in it).  While this could automate a build, it built the entire program whenever it was run.  For small programs, this was fine, but for larger projects it was a waste of time to recompile every file whenever anything changed.  In the later versions, Consulair offered some optional utilities, one of which (SuperMake) was a sophisticated dependency analyzer and make utility that only recompiled changed files.  This made building a program on the Mac comparable to that on unix, except that there was still no command line, so errors were written to files that could be read only in the editor.

    Two very useful command line programs that unix programmers were accustomed to have available, diff, and grep, were also turned into graphical Macintosh programs by Consulair.  Diff allowed a comparison between files and made a complete list of differences, while grep could search a set of files for a text string and print a list of matches by file name and line number.

Debugging

   Consulair C had no source level debugger.  I remember not being surprised by this.  Source level debuggers were not always a part of development systems at that time.  The Macintosh had very good object level debuggers, one free one provided by Apple (Macsbug) and a commercial one (TMON).  The Consulair documentation gave extensive information on its code-generation rules, so that the object code it created could be readily understood in the disassembled view in the debugger.  It also generated a symbols file that could be imported in Macsbug and TMON to facilitate debugging.  At the time, debugging in TMON seemed great, and maybe I had never even seen a working source level debugger.  Within a year or two, all development systems would come with mind-bendingly great source level debuggers.  In the Mac world, this capability was delivered primarily by one company, Think Technologies.

What happened to Mac C?

   Consulair Mac C was upgraded several times, and supported the HFS explicitly starting with v4.  The last version I have is version 5.02, and I don’t think I ever failed to get an update that I knew about.  I occasionally see references to an update of MDS created by Consulair that supported the Mac II, with its 68020 processor and 68881 floating point processor, but I don’t remember ever seeing it. Mac C, so far as I know, did not make the transition to the Mac II. 

-- BG (basalgangster@macGUI.com)