Scott Ladd is a full-time freelance computer journalist. You can reach him at 302 N 12th, Gunnison, CO 81230.
Turbo C -- Borland International 1800 Green Hills Rd. Scotts Valley, CA 95066-0001 408-438-8400
Quick C -- Microsoft Corp. Box 97017 Redmond, WA 98073-9717 206-882-8080
In the world of software, the war for market share goes on and on. At the forefront of this conflict are two titans, Microsoft and Borland. It is inarguable that these two industry giants influence the type and quality of products available both now and in the future. In particular, their language products are among the first in line when companies and individuals consider which products to buy.
This article reviews and compares Borland's Turbo C and Microsoft's QuickC compilers. Due to their low prices and the name recognition of their vendors, Turbo C and QuickC (or TC and QC) are often the C compilers chosen by people who are just learning the C language. One of the most popular questions raised in user groups and electronic forums is, "Which one is best?" That's not an easy question to answer.
Part of the problem is that, although similar in many ways, TC and QC are aimed at different programmer audiences. Microsoft targets QC chiefly at newcomers and casual users. Experience with Version 1.0 apparently convinced Microsoft that these are the buyers for QC, and so Version 2.0 is tailored to their needs, with Microsoft C 5.1 for professionals. Meanwhile, Borland's TC competes with both Microsoft C offerings, thus aiming higher. This introduces some subtle, but telling differences.
And precisely because TC goes after the spectrum of Microsoft C products, we're going to compare it with both in a two-part review: this month with QC, in August with Microsoft C. That month's installment will include benchmark results for all three.
TC and QC are very similar in scope and appearance. TC costs $150, while QC costs $99. In the basic package, each product has an integrated environment that includes an editor, a compiler, a linker, a debugger, and Make facilities. Command-line utilities are also provided for programmers who dislike environments. TC and QC are fast products -- both compile tens of thousands of lines of source code per minute on an 80286-based PC. Documentation for both products consists of paperback manuals. With all of these similarities, it might appear difficult to find true qualitative differences between the two products. Appearances, however, can be deceiving....
Both TC and QC offer automated installation programs. TC's automated installation program is a bit "prettier," with fancy pop-up windows and background shading. QC's installation is more austere, but equally adequate.
It is possible to make TC and QC work in a diskette-only environment -- but I strongly recommend against doing so. The installation programs set the compilers up on multiple diskettes, and your arm will quickly become tired swapping disks. The situation improves if you have high-capacity diskettes, such as the 3 1/2-inch drives found in many newer machines. I had no problems using both QC and TC on my dual-720K microfloppy laptop. A hard disk is best for both.
The installation programs leave little room for complaint. The user is given complete control over which components are installed and which directories the components are installed into. Each installation program reminds the user to set the proper environment variables. In keeping with QC's less experienced target audience, Microsoft's more detailed (but also more verbose) description of the installation process is a bonus for those unfamiliar with memory models and compiler installation.
While it's not a "bug" per se QC's installation program does have the annoying habit of placing the font files into the same directory as the sample programs. I always think of sample code as something to be deleted (sooner or later). I would prefer the fonts to be copied into the directory where library files are stored.
If you use a hard disk drive, you'll need more than 2 Mbytes of free space on the drive when you install these products. After cleaning up example files and read-me files, you can easily fit either product into about one and one-half Mbytes.
TC's documentation consists of a 425-page user's guide, and a 612-page reference guide. The user's guide contains tutorials on the environment, the debugger, and the C language. The reference guide includes a library function dictionary and detailed information about the command-line utilities.
Borland has created a good set of tutorials that cover all of the necessary subjects and include well-designed examples. I especially like the "helpful hints," such as a section on common C programming pitfalls. These "dos and don'ts" are valuable to the beginning programmer who has little experience with C.
Documentation of the TC command-line compiler and utilities is terse but complete. By placing this information in appendices, Borland seems to indicate that they expect most programmers to use the environment. Examples that show how to use the command-line compiler and the linker are virtually nonexistent.
QC's documentation also consists of three manuals --a 64-page Up and Running booklet, the 336-page toolkit manual, and the 376-page C for Yourself. Up and Running covers installation and includes some basic details about how to run the environment. The toolkit manual covers the command-line utilities in detail. C for Yourself is a C-language tutorial and reference.
Despite the number of its pages, I consider this set of documentation largely inadequate. Microsoft assumes that the user will run through the interactive tutorial. While the tutorial is well-designed and informative, it does not touch on all of the subjects that a complete manual would cover. At least half of the editor functions are not documented anywhere. Many menu items are ignored or glossed over. The user must explore the environment in order to completely learn it. While the tutorial is a general introduction to the product, it is not comprehensive enough to replace thorough paper documentation.
C for Yourself is a superb C tutorial that leads the programmer through all of the fundamentals of the language and into implementation-specific facets of QC. Unfortunately, this manual falls short of perfection by omitting any mention of many important library functions. For instance, there is no mention about the MS-DOS interface functions, such as intdos( ) and int86( ). Several keywords, including far, near, and interrupt, are also ignored. Information about these subjects is available in the on-line help (described later), but that is not a viable solution --a beginning C programmer will not know which questions to ask in order to be able to look up this missing information on-line. The solution is to purchase a $25 supplemental manual.
Microsoft's documentation of the command-line utilities is first-class. The toolkit manual begins with a short section discussing the utilities in general, and then moves on to chapters that describe each tool in detail. Liberal examples illustrate the use of the different utilities.
Microsoft has put a great deal of effort into QC's on-line help system, which it considers an essential part of the documentation. The help system is context-sensitive and uses some of the concepts of hypertext. You point to an item with the cursor and then press F1 to get help; this method works even on help information. All of the library functions, error messages, and C keywords are documented. "Hotlinks" in each description block can be used to move to other areas, including an alphabetical index and a table of contents. You can set "bookmarks" in the help system that let you quickly return to a specific piece of information. As an added bonus, you can cut and paste information in the help system (including example programs) into a file that you are editing.
Despite its many strong points, QC's help system has a few holes. The Huge keyword can be found in the list of C keywords, but not in the alphabetical index. Also, the help system requires a great deal of hard disk space -- more than half a megabyte! Because the system is built into the QC environment, it is impossible to access the help information if you use your own editor. On the other hand, the QC help has more than 200 working code samples that the user can copy directly into a program.
TC's help system is less sophisticated but adequate. A general index and/or table of contents is missing from the help system. To retrieve help information on the current window, you press F1. To obtain details about the item that the cursor is currently pointing to, such as a standard library function or keyword, you press Ctrl-F1. By pointing to a header file name (such as stdio.h) with the cursor and pressing Ctrl-F1, you can access a list of the function prototypes and definitions that the file contains. In the long run, though, TC's help system is less extensive than the help system in QC.
However, TC provides a TSR to make the help information available in an external editor. This is very handy for those who prefer to use their favorite editor and the command-line utilities.
Thus we have a trade-off: more and better paper documentation but less on-line help in TC, more help and less detailed manuals with QC.
QC and TC follow the ANSI standard as well as, or better than, most other MS-DOS C compilers on the market. Both products include all of the common MS-DOS language extensions, such as the near and far keywords. Programmers will not be disappointed with the languages supported by either of the products.
While both compilers support inline assembly, QC's implementation is by far the better. With TC, each line of inline assembly language must be prefaced with the keyword _asm. TC also requires that you have a command-line assembler, such as Borland's TASM or Microsoft's MASM, in order to use the inline assembler. On the other hand, QC includes a complete built-in assembler. Multiline blocks of inline assembly code can be created within curly braces following a single instance of the _asm keyword.
Competing vendors are always looking for ways to spice up their products. With C compilers, an excellent way to do this is by adding functions to the library. TC and QC sport some of the largest libraries in existence.
With the exception of multicharacter and international support functions, the libraries are very complete from an ANSI standpoint. QC and TC provide additional functions for direct access to the underlying hardware and MS-DOS. Most of the function names and parameters are similar between the two products.
Borland added an excellent graphics library with TC, Version 1.5, that was not significantly changed for Version 2.0. When QC was first introduced, it included a modest graphics library, which has been dramatically improved in the most recent version of QC.
QC and TC support all of the basic graphics primitives, along with stroked and bit-mapped fonts. TC "autodetects" the type of graphics adapter installed; QC does not, but listings in the manuals provide a "trial and error" loop for finding and entering the best graphics mode. Borland allows fonts and graphics device drivers to be loaded at run time or to be made into linkable object modules. Microsoft's graphics drivers are linkable, but the fonts must be loaded from disk files at run time.
If you work with charts and tables, QC has as a real treat in store. Its graphics library includes a set of presentation graphics functions. A special structure is loaded with information that can be used to draw pie, bar, stacked-bar, line, or scatter charts. Hatching, borders, legends, and headings are all handled very nicely. By contrast, TC provides a full complement of lower-level functions to help you build charts, but Microsoft's package is more automated and convenient.
QC and TC are both chiefly integrated environments combining an editor, a compiler, and a linker into a single, all-in-one program. A menu bar across the top of the screen provides pull-down menus for various operations, such as loading and saving files, compiling, and debugging. Program options can be set through these menus and then saved to disk. Both programs permit such configurations to be stored in files in different directories, offering you the flexibility to specify options for different projects. When you start the environment from a given project directory, the configuration stored there becomes the default.
In keeping with its target audience of less experienced users, QC offers a unique two-level menuing system. The lower (default) level provides a "bare bones" set of menus, presumably intended to keep the novice user from being intimidated by the environment. As the QC user becomes more confident, he or she can set an option that activates the more complete menuing system.
The QC and TC editors are not going to excite programmers accustomed to sophisticated editing programs such as Brief and QEdit. Both editors use an extended subset of the WordStar command set. By "extended subset," I mean that they use many of the WordStar commands, and also add several of their own. QC has a menu option to install an alternate editor. In addition, QC's "notepad" window allows you to edit more than one file at a time. QC and TC both include utilities for redefining/adding command keys and otherwise adjusting the editor to personal preferences.
Neither product supports editor macros or context-sensitive editing. QC accommodates -- in fact, almost demands -- a mouse, which makes many operations easier. (Why Borland products lack mouse support is a matter of ongoing curiosity and annoyance.) The undo facilities of both editors are virtually nonexistent.
Both products' compilers and linkers are very fast and support a full line of memory models. TC supports a Tiny model (unavailable from Microsoft) that can be made into .COM files. Otherwise, the basic code-generation capabilities of the two products are similar. Errors are tracked and displayed in their own window.
In QC's favor is its "incremental" compile and link. In effect, the compiler only recompiles and relinks those parts of a program that have changed. On a large source program, QC's ability to perform incremental compiles gives this compiler an amazing speed advantage. This is particularly important during debugging, when compiles often take place after only a few changes are made to a program.
Make facilities are built into both environments. TC calls the control entities "Project Files," while QC names them "Program Lists." Each lists the files belonging to a multimodule program, and the compiler/linker is intelligent enough to process only those modules that have changed since the last program build. I like QC's built-in Make-better, because it creates a true Make-file on disk for use with the stand-alone Make program. On the other hand, TC needs differently-formatted project and Make files for the environment and command-line utilities, even when the same source modules are involved. There are conversion utilities, but the different formats are a hassle.
Here's an interesting statistic about memory usage: When no files are loaded TC uses 318K of memory. By contrast, QC uses only 185K, an amazing improvement over the previous version that barely fit into 640K. Note, however, that TC takes advantage of EMS when present, whereas QC does not.
The debuggers included in integrated environments are not as capable as their stand-alone brethren. This does not mean they're useless; it merely means that these debuggers are designed to detect the most common kinds of run-time problems. The debuggers for QC and TC can step through programs line-by-line, set breakpoints, watch variables while the program runs, and change the values of variables while the program runs. They can also follow pointers, display structures, examine the stack and registers, and provide output in several forms (hex, decimal, and so on).
The TC debugger is an easy-to-use product that is solid and useful for finding common bugs. Borland devotes a great deal of space in the TC manuals to the discussion of debugging techniques and strategies. Unfortunately, TC does not support conditional breakpoints or the "animation" (execution in slow motion) of programs.
QC's debugger, a subset of Codeview, has several pluses and one surprising minus. I like the "locals" window, which shows the values of all local variables for whatever function is currently being traced. The "registers" window shows the processor registers as if they were variables, and makes the debugging of inline assembler much easier. The ability to store "history" information permits you to retrace steps previously executed. User input can also be recorded and replayed, saving a great deal of time when bugs are located deep within a program's logic.
The omission in QC's debugger is almost unbelievable --it is not possible to simply check a variable; instead you have to put the variable into the watch window! This process involves several keystrokes, where one would be sufficient. And having seen the value, it takes several more keystrokes to get rid of it.
In contrast, TC's debugger allows you to see the value of any variable instantaneously by pressing Ctrl-F4. The variable name under the cursor is automatically displayed. You can "rip out" further text from the source --for example, a structure field name --by pressing the right arrow key until the complete name of the variable you want to see is in the window. If the cursor location selects the wrong variable name, you simply type the one you want. Similarly, you can type C expressions and see the result, and also change a value "on the fly," as for example in finding out how the program deals with an unexpected data value. You press Esc to make the examination window go away. TC's integrated debugger also includes a watch window similar to QC's for more permanently displaying selected variables and their dynamically updated values.
For those who dislike environments, QC and TC supply utilities for use at the MS-DOS prompt. Each product includes a command-line compiler, linker, Make facility, and object-module librarian. Each also furnishes some unique utilities. For example, TC adds a preprocessor, a grep, an object-module cross-reference utility, and a program to convert graphics drivers and fonts to object modules. As for QC, it furnishes a utility to create customized help files.
TC has few blemishes. For example, documentation of the command-line utilities could be expanded, and real inline assembly would eliminate the need for an external assembler. On the plus side, the integrated debugger is more powerful, documentation is more complete, and the set of command-line utilities is more extensive than that of QC. All in all, TC is a quality product with features aimed at a more demanding, competent C programmer than QC.
Probably the most important area where QC needs improvement is the paper documentation --more information is needed for beginners who are moving toward the realm of experts. In spite of this, QC has a slight edge over TC in a couple of areas. QC cleanly supports inline assembler, has a superior graphics library, and incorporates some impressive new technology with its incremental compilation and linking capabilities. One dramatic improvement over the earlier version is that QC is no longer a "toy" compiler with no selection of memory models. It now supports all models except Tiny.
I truly like both products --each has good and bad points, and there is no loser. The winners are the programmers who benefit from the competition that generates better products. No matter which product you buy, be assured that you're not wasting your money.
So much for TC versus QC. In the August issue we'll pit TC against QC's "big brother" and wrap up with a benchmark report that compares the performance of all three.
Copyright © 1989, Dr. Dobb's Journal