# The Early Days The very first C compiler ever released for the Macintosh was **Consulair Mac C**, developed by Bill Duvall. Considering that Duvall also developed the [Macintosh 68000 Development System](http://macgui.com/downloads/?cat_id=305) (an assembler, known as MDS) for Apple, it is no real surprise that his C development system used the same editor and tools, being nearly drop-in compatible with MDS. All of the source code for the C libraries was supplied with the compiler, so programmers could modify it if they wanted, or even use it as a learning guide. This was pretty important, because examples of Mac code were not readily available at this time! (Only the `Str2Dec` and `Dec2Str` functions lacked source code, since these were licensed from Apple, not written by Duvall, and therefore shipped in binary form only.) Consulair Mac C was released in 1984, but I can't find an exact launch date. [This review](http://www.network172.com/files/2015/12/MacDev3.pdf) by Léo Laporte in Issue #3 of *MacDeveloper* magazine says that the author has "been using it full-time since November, '84", so it was *at least* commercially available by then. I'm not sure how long it took after the January 24, 1984 release of the original Mac for it to become available, though. As you said, the most important languages on the Mac in its early days were Microsoft's BASIC, Pascal, and, of course, 68000 assembly. The Macintosh's operating system and ROM were themselves programmed in a mix of assembler and Pascal. C was merely a niche language in 1984, and I doubt that Consulair Corp. sold very many copies early on. Laporte's review (linked above) provides a number of interesting details about Consulair's Mac C, including what libraries it shipped with, what aspects of the language it supported, what else you needed to get started, and how much it cost. I won't quote all of this here, so go and read the article! Thre's also a March 1991 interview with Bill Duvall, conducted by Michael Swaine, available on [this site](http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/1991/9103/9103h/9103h.htm). It looks like this was originally published in *Dr. Dobb's Journal*. Although most of it is focused on Duvall's thoughts about HyperCard and later ventures, it does contain some interesting and relevant information about his C development system; in particular: > **DDJ**: When did you first get involved with the Macintosh? > > **Duvall**: I became involved with the Mac some years before it was > released when Apple asked me to write an assembly language development > system for the Macintosh: an editor, a debugger, an assembler, and a > linker. Which I did. > > **DDJ**: Why did Apple come to you? > > **Duvall**: The fellow that Apple hired to head up the Mac as an > engineering manager was Bob Belleville, a person with whom I had done > a lot of work at PARC. He had a need for a development system, knew > that I had some expertise in that area, and asked me to come and do > it. > > **DDJ**: Early Macintosh developers may know you as the author of that > development system, and more Mac developers should remember your > company, Consulair, for its C compiler. But Consulair was around > before the Mac. > > **Duvall**: Consulair was first formed in the mid-'70s. Most of our work > was in the area of word processing; in particular, we did a lot of > work in one of the early Japanese word processors. There was a fair > amount of systems work, writing operating systems. There was some > language development; we did some debugging systems, things like that. > In general, [it was] what you would classify as advanced development > or systems programming. > > **DDJ**: You were doing tools for programmers, then? > > **Duvall**: We always worked on development systems, but primarily up > until the early to mid-'80s we had done development systems as > internal tools. In fact, we first wrote what later became the > Consulair C compiler in the late '70s as a tool for programming our > own projects. This was just after the publication of Kernighan and > Richie's original book, and I looked around to see what was the best > system programming language around, one that was going to be around > for the next few years, and came to the conclusion that C was probably > the best candidate. So I wrote a C compiler. > > **DDJ**: Where did the commercial Consulair C compiler come into the > picture? > > **Duvall**: After the Mac was released to the world it became apparent > that there was a need for a C language development system. Since we > had a C compiler that we had been using internally for five years, it > was -- I won't say it was a short step, but it was a logical step -- > to put that in a form that could be used commercially on the > Macintosh. > > **DDJ**: It was well received. Didn't you get the first MacUser Editor's > Choice Award for a development language? > > **Duvall**: It's difficult to answer something like that. I, like many > people, suffer from the programmer's dilemma. > > **DDJ**: The programmer's dilemma? > > **Duvall**: Any time you've worked on a program, you realize all of the > faults in it. It's difficult to go back and look at it and say, yes, > that was really important. Rather, you look at it and say, "Oh my > God." But, yeah, I think it played an important role in the early > development of the Mac, although clearly it was superceded by MPW and > Lightspeed. Andy Hertzfeld also recalls the development of Consulair C, as part of [a larger recollection](http://www.folklore.org/StoryView.py?story=RMaker.txt) in which he describes how he developed a resource compiler that ran natively on the Mac, allowing him to ditch the Lisa when writing Mac programs: > I went on leave of absence from Apple in March 1984 (see Leave Of Absence), but I still was excited about writing software for Macintosh as an independent developer, and was full of ideas about different programs to write. But I wasn't happy about the fact that you still needed a Lisa to write software for the Mac; among other things, the recent linker problem had left a bad taste in my mouth regarding the Lisa development system. I had a Lisa at my house, but it really belonged to Apple, and I didn't want to have to buy one. I decided to try to cobble together an entirely Mac-based development system. > Bill Duvall was an old friend of Bob Belleville's from Xerox who we seeded with a Mac prototype in the spring of 1983 so he could port his development system to it, including an assembler and a C compiler, to be sold by his own tiny company named Consulair. His linker even generated Macintosh code resources, but there was no equivalent of RMaker for building the other resources required by a Mac application - you still had to do that on a Lisa. I decided to rewrite RMaker for the Mac, so I could finally abandon the Lisa. I used assembly language, since the assembler was much further along than Consulair C was at the time. In a week or so, I had a new RMaker that was integrated with the Consulair tools, so you finally could write a complete application with just a Macintosh. > In the summer of 1984, I got a call from Dan Cochran, who was the marketing person at Apple in charge of developer tools. He had heard about my new version of RMaker, and wanted to bundle it with the Consulair package. After a bit of negotiation, I sold it to Apple in exchange for a brand new LaserWriter prototype. I drove up to Bill Duvall's house in the Berkeley hills to help him incorporate RMaker into his system. When my reward arrived in October, I thought it was pretty cool to be the first on my block to have a LaserWriter, three months before it was officially announced. This tells us a couple of neat things. First, Bill Duvall was given a Mac prototype in the spring of 1983 by Apple, which is what allowed him to have his development system available so soon. Also, the resource maker that eventually shipped with Consulair C was written (in assembler) by Hertzfeld himself—one of the original members of the Macintosh software development team. One significant limitation of Consulair Mac C—at least to our modern eyes—was that it did not include a source-level debugger. You had to use something like [MacsBug](https://en.wikipedia.org/wiki/MacsBug) or TMON (by [ICOM Simultations](https://en.wikipedia.org/wiki/ICOM_Simulations), which was *way* better than MacsBug, but not free). Although you can find *later* versions of Consulair Mac C for download online (for example, [Macintosh Garden](http://macintoshgarden.org/apps/consulair-mac-c-development-system) and [Mac GUI](http://macgui.com/downloads/?file_id=24076) both offer version 5, which includes updates that make it HFS-compatible), I don't see anywhere that version 1 is hosted. Nor, unfortunately, do I have a copy. # The Halcyon Days Moving forward in time a bit, by 1986, C had joined Pascal as one of the premier and popular development languages for Macintosh software. Although Consulair's Mac C was still around, the two principal players by 1986 were **LightSpeed C** and Apple's own [**Macintosh Programmer's Workshop (MPW)**](https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop). ### Macintosh Programmer's Workshop Although version 1.0 of MPW was released on September 24, 1986 (according to Wikipedia), with development having begun in late 1985 by Rick Meyers, Jeff Parrish, and Dan Keller (née Smith), this early version did not include a C compiler. Originally, MPW only supported Pascal, which was the language that Apple initially pushed for Macintosh software development. MPW was the official replacement for the Lisa Workshop, and what finally freed Mac programmers from having to cross-develop on Lisas. (Although, I believe you needed at least 1 MB of RAM to run MPW, which naturally limited you to developing on the newly-released [in 1986!] Macintosh Plus.) C support did not come to MPW until version 2.0, released on July 20, 1987. The C compiler that was included in this version was written by Green Hills' Software, under contract with Apple, with Mike Shannon serving as liaison at Apple. Interestingly, Green Hills wrote their C compiler in C—I'm not sure which compiler they used to bootstrap it, though! Green Hills Software has been around since 1982, and [is still around today](http://www.greenhillssoftware.com), still developing compilers and other development tools, mainly for embedded systems. In version 3.0, MPW finally shipped with a C compiler developed in-house by Apple. Unlike the Green Hills compiler that it replaced, Apple's compiler was written in Apple Pascal and shared its code generator with MPW's Pascal compiler (the one that had been there since v1.0). It was this compiler that became famous for its [quirky and comical error messages](http://www.netfunny.com/rhf/jokes/91q3/cerrors.html). What was unique about MPW was that it offered what was essentially a Unix-style shell (based on csh), running natively on the Macintosh. You could run shell scripts, there were command-line tools, and decidedly un-Mac-like behaviors (such as output redirection) were possible. MPW was really quite an odd duck, since it was not at all Mac-like, but it was also not fully Unix-compatible, either. It was also expensive in these early days (before Apple started giving it away for free, which didn't happen until after the PowerPC transition), so it was really only used by professional programmers. Again, later versions of MPW are readily available online (although no longer from Apple themselves, who would prefer to forget that the "classic" Mac OS ever existed), but I don't know where you can download any of the early versions. ### LightSpeed C LightSpeed C was really the definitive and most widespread C development environment on the Macintosh. (It was also an extremely popular development environment on the 8-bit Atari machines of similar vintage.) It was developed by Michael Kahl, of THINK Technologies, and released in mid-1986. THINK Technologies was later [gobbled up by Symantec Corporation](http://www.cbronline.com/news/symantec_acquires_think_technologies/) (like so many other independent vendors), who continued to develop and release the tool under the name THINK C (having dropped "LightSpeed" from the name starting with version 4.0, circa 1988). No matter what it was called, LightSpeed/THINK C was powerful, fast, and (relatively) cheap—a winning combination. *BYTE* magazine awarded it "Distinction" in the 1989 BYTE Awards, [citing its "powerful features and low price"](https://archive.org/stream/byte-magazine-1989-01/1989_01_BYTE_14-01_PC_Communications_and_Annual_Awards_and_Digitizing_Tablets#page/n379/mode/2up). [A July, 1986 article in *MacTech* magazine](http://www.mactech.com/articles/mactech/Vol.02/02.08/Menus,Windows/index.html), by Bob Gordon, recommends LightSpeed C as an excellent way to learn how to program C on the Macintosh, noting: > Its major advantages from our point of view is that it is very fast at compiling and linking and that it places you at the correct position in your source file if the compiler detects an error. The result is that you can edit, compile, link, and run your program very rapidly, make small variations in the code and determine their effect, and generally have the opportunity to make more mistakes in a shorter period of time. If we learn from our mistakes, Lightspeed C is a useful tool for learning C on the Macintosh. > LightspeedC is different from the other available C compilers as it does not use a Unix-like setting *[Yea! -Ed.]* -nor does it use separate programs in the Macintosh window environment. Instead it creates its own enviornment (that follows the Macintosh User Interface) from which all editing, compiling, linking, and running take place. The integrated editor is roughly similar to the Edit application. Menus available from inside the editor allow you to run, compile, or just check the syntax. As soon as the compiler detects an error, you are returned to the editor with the cursor at the location the compiler found the error. In other words, you get one error at a time. > The link operation is extremely fast. However, Gordon does go on to disclaim a few problems in LightSpeed C, although most of these do not appear to be *actual* problems with the development environment, but rather behaviors that he found confusing. A significant criticism, leveled often by reviewers and columnists, was that early versions did not include an assembler. Of course, I'm not sure how much that would have actually mattered to the average Mac programmer. The low-level gurus were probably already using MPW, which *did* come with an assembler, and everyone else was writing in C because they *didn't want to* use assembly. If they really needed one, assemblers were available from other vendors. And, THINK C eventually did ship with an assembler; in fact, it even supported inline assembly with the C compiler, in [a very easy-to-use implementation](https://groups.google.com/d/msg/comp.dsp/fHGFX9XcIMk/ya4NfTn2P-sJ). Although slightly less famous and less renowned than THINK Pascal, LightSpeed/THINK C was really the primary C development environment for Macintosh programmers through the late 1980s and early 1990s, until it was replaced by **Metrowerks' CodeWarrior** circa 1994 (in part because Symantec had ruined it, but probably more so because of turmoil from the PowerPC transition, but that's getting far outside the scope of this answer). Interestingly, though, much of the development on CodeWarrior was done by folks who had worked on the original THINK C team, and CodeWarrior retained one of the most important features of THINK C: fast compile times. [LightningPaint](https://www.macintoshrepository.org/1803-lightningpaint-1-1) was famously written in LightSpeed C, from which it borrows its name. This app was essentially a clone of MacPaint, but continued to be distributed as shareware long after Apple dropped MacPaint. Version 3.01 of LightSpeed C is also available on [Macintosh Garden](http://macintoshgarden.org/apps/thinks-lightspeed-c-301) and [Mac GUI](http://macgui.com/downloads/?file_id=24077), along with later versions of THINK C. Alas, older versions are missing-in-action.