kathy@wrcola.UUCP (K.M.Vincent) (08/22/87)
In article <820@wrcola.UUCP> I wrote: >My friend, who owns a Tandy 1000, is looking for recommendations >for a good C compiler for MS-DOS machines. He's especially interested >in portability - probably because he spends time on my UNIX pc and >would like to be able to move code between machines. I've received far more requests for my accumulated stash of MS-DOS C compiler information than I thought I would, along with one comment that one should never hesitate to post something useful to the net. So I have changed my mind about posting the summary. [ See below. ] Because I'm posting, I'm not mailing the list out to individuals. If that's a problem for anyone who wrote me, let me know. Thanks again to everyone for their help. Kathy Vincent AT&T, Winston-Salem, NC :<*>:<*>:<*>:<*>:<*>:<*>:<*>:<*>:<*>:<*>:<*>:<*>:<*>:<*>:<*>: AT&T: {ihnp4|mtune|burl}!wrcola!kathy Home: {ihnp4|mtune|ptsfa|codas}!bakerst!kathy ------------------------------------------------------------------------- >From: Dale Gass <rutgers!seismo!dalcs!dalcsug!dalegass> Subject: Turbo C and Aztec C Organization: Dalhousie University, Halifax, N.S., Canada Although Turbo C is by far my favourite, Aztec C is very fast (and generates better code, in my opinion), and is *very* unix compatible, which seems to be a major concern of yours. Price ranges from $100 or so for a small packages (small memory model) to $500 or so for the full-blown version (with full library sources included). -dalegass@dalcsug.uucp ------------------------------------------------------------------------- >From: rutgers!rochester!rocksvax!martyl (Marty Leisner) Subject: Aztec C, MSC Organization: Xerox, Rochester, N.Y. I use Aztec. I don't like MSC. Everyone uses MSC -- I'm not sure why. I've had no portability problems with the compiler. You do have problems when Unix software does fork/execs. marty leisner xerox corp leisner.henr@xerox.com martyl@rocksvax.uucp ------------------------------------------------------------------------- >From: <rutgers!ames!lll-tis!ptsfa!cogent!mark> Subject: Aztec C Organization: Cogent Software Solutions, Stockton, CA While I haven't used it myself, I have heard nothing but praise for Aztec C. I've heard it's top in speed, low object size, and portability. Mark Steven Jeghers {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark ------------------------------------------------------------------------- >From fubar!cliff Subject: Microsoft C, Turbo C Without a doubt the very best C compiler available is Microsoft C 4.0. HOWEVER, I reccomend that you either wait and buy 5.0, or get 4.0 with the idea that you'll soon have to upgrade to 5.0. If you've never programmed in C before, then Turbo C would be a good idea: cheap, has an easy environment to work in, lots of books our about it already. BTW: MSC 5.0 will come with the MSC 5.0 compilers (best in the world), and ALSO with Quick C (which is very like Turbo C). Turbo C: 69 dollars MSC C: 250 dollars This may very well be the deciding factor. -cliff@fubar ------------------------------------------------------------------------- Subject: Microsoft C, Computer Innovations c86 Organization: Chinet - Public Access Unix >From: ihnp4!chinet!stox I never thought I would see the day, but I would have to vote for the MicroSoft 5.0 compiler. I have been bouncing a bunch of engineering applications between an AT w/MSDOS, a 3B1, and a pair of Zilogs with little problem. However, unless they have changed much, my personal favorite for a learning compiler is the Computer Innovations c86 compiler. Their support in the past has been excellent, whereas MicroSoft has the most pompous support people I have ever had the misfortune of talking with. Ken Stox ihnp4!stox!ken ------------------------------------------------------------------------- From: rutgers!harvard!yale!hsi!mark (Mark Sicignano) Subject: Turbo C I would recommend the Turbo C compiler. I've been using C heavily now for about 3 months. Turbo C comes with a command line C compiler which is much like cc on Unix(TM), an integrated environment compiler (compiler and editor remain in memory, has windows, lots of nice little extras), a Unix(TM) like make utility, and plenty of neat functions in it's libraries. I find it to be a fast compiler with more features than I'll every use. The best part is that it only cost me $61.95 from 47th Street Photo in NYC. Net : {noao!ihnp4!yale!}!hsi!mark Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511 Bell : (203) 562-2101 ext. 32 ------------------------------------------------------------------------- From: ihnp4!n8emr!oink!jep Re: Your request about MS-DOS C Compilers About half of the work I do for a living is done in C on PCs of various types. Outside of work I have to contend with not only my own XT clone, but an old CP/M system, an OS-9 machine, and this UNIX-PC. I have been concerned with portability for quite some time. It is a major reason for doing much of my in C. Whenever I here of compilers, much of my questions concern adherance to K&R (and now ANSI), and adherance to UNIX SYSTEM calls. Mark Williams: Screwy. A UNIX guru I used to work with said they just couldn't resist doing things their own "better" way. He said the part that suffered the most was the system calls. Lattice: Better. My experience was with Microsoft C V2.0 which was a variant of Lattice's compiler. My understanding was that Microsoft had bought non-exclusive rights to modify and sell Lattice's compiler (at the same time that Lattice was selling it under their own name). I have never seen the pure Lattice compiler. I have been told by those who tried both that the Microsoft version was less buggy and adhered to UNIX system calls better. This version came with a copy of K&R. Microsoft V3.0 Microsoft rewrote it from SCRATCH! Microsoft got serious. I only found one bug in all the time that I used it. It followed K&R better (it hadn't been bad to begin with). It ran faster, produced better code, and had much better adherance to UNIX style system calls. They started noting the few incompatibilities that did exist. They had a lot of references to XENIX. Like I said, they got serious. There manuals even started to look like an AT&T manual. One big gripe of mine is that they substituted their own language definition manual for the previously included K&R. I figured that this was a ploy so that they could say to say to people that would complain about any K&R incompatibilities that they weren't claiming to follow K&R. (Can't you see that here on page 43 of our fine manual that we define C as being x, so that your complaint/ comment about K&R incompatibily is stupid?). I also figured that it was a way to get out of having to shell out bucks to Prentice-Hall for the copies. They added every kind of compilation switch imaginable (good). Microsoft V4.0 Started adding proposed ANSI stuff. Faster compilation, better optimization of code generated. The main reason for this release was codeview, a source level windowing debugger. Microsoft in general concering MS-DOS compatibility. Microsoft has the best MS-DOS compatibility. This should come as absolutely no surprise since they wrote MS-DOS and have quite a stake in trying to keep everyone using it and their other products. The compatibility is in two concerns: 1. They don't rely upon any particular hardware or BIOS ROMs. (Except for codeview) 2. All their object modules are compatible with MS-DOSs link, which is an extension of the previous standard object module format that Intel had laid down as law. This is especially important for people who need to mix assembly and C. Microsoft V5.0 Microsoft's answer to Turbo C. Turbo C is selling like hotcakes. Microsoft doesn't like that. Microsoft is being forced to compete by throwing in "Quick-C". I think this will be available "Real Soon Now" (thanks Jerry Pournelle). Turbo C Damn fast. Cheap. Almost as compatible as Microsoft. Object modules are incompatible with Microsoft's. For the first time, Borland put out something that wasn't so unique (like Turbo Pascal). Kahn understood that C people live and die (and purchase) by standards. I haven't used it, but the guy who works next to me bought it and loves it. He has also been using Microsoft V4.0 at work. All the other compilers have all sorts of neat gonzo features that are as powerful as they are incompatible, which makes them unusable for any serious work. If you need the ultimate in compatibility (which concerns not only K&R, ANSI, and UNIX, but also compatibility across all MS-DOS machines, and other peoples' compilers/assemblers that produce object modules that you have to link with), then get Microsoft. The next best choice is Turbo C. I am considering buying Turbo C for myself just for the quicker developement. i.e. I would use Turbo C as a super-lint. I will still use Microsoft for compiling the final product that I ship. Please send me a trivial mail reply as this is the first time that I have sent mail outside this location, and consider this as also a test of my system and my use of mail. James E. Prior {ihnp4|cbosgd}!n8emr!oink!jep ------------------------------------------------------------------------- From: ihnp4!n8emr!oink!jep Subject: Computer Innovations Optimizing C86 Earlier this year I downloaded the source to ARC.EXE for MS-DOS. I tried to convert it to compile under Microsoft C without much luck. It had been written to compile under Computer Innovations Optimizing C86. The CI compiler has by far the most powerful and most incompatible preprocessor I've ever seen. Here's a little sample grep'ed from the code: $define(tag,$$segment(@1,$$index(@1,=)+1))# $define(version,Version $tag( TED_VERSION DB =5.12), created on $tag( TED_DATE DB =02/05/86) at $tag( $undefine(tag)# $version { printf("ARC - Archive utility, $version\n"); $emit(push,off) $define(arcmark,26) special archive marker $define(arcver,8) archive header version code $define(strlen,100) system standard string length $define(fnlen,13) file name length $define(maxarg,25) maximum number of arguments $emit(pop)# char buf[$strlen]; /* input buffer */ $emit($arc)# char fix[$strlen]; /* fixed name buffer */ $emit(on)# James E. Prior {ihnp4|cbosgd}!n8emr!oink!jep ------------------------------------------------------------------------- From: ihnp4!n8emr!oink!jep To: n8emr!ihnp4!wrcola!kathy Subject: Aztec C Re: Your request about MS-DOS C Compilers My first exposure to Aztec C was in '83 or '84 with a CP/M version. It was a fuller version than the compiler that I had been using, but: It was very buggy. Even some very simple programs with while loops didn't work right. I think one of them had while (1) as the main loop, and it just wouldn't work. There was always a work around, but it wasn't trustworthy. Its floating point worked but was weird. Most floating point math regardless of whether it is done by hardware or software is done in binary scientific notation. IBM 370s do it in hexadecimal scientific notation. Aztec did it in base 256. i.e. for a four byte float the number was something like: mantissa = byte1/256 + byte2/(256^2) + byte3/(256^3) exponent = (byte0 & !SIGN_MASK) -0x40 number = mantissa * 256 ^ exponent A nice result of this was that the range of numbers that could be represented was about (+|-)10 ^ ((+|-)151), as opposed to (+|-)10 ^ ((+|-)38) for typical four byte binary scientific notation. The bad result was loss of significant digits. I don't feel like explaning the why, but I will explain the what. The amount of mantissa that one can rely upon being significant is one less digit (in whatever base one is working in) than that of the whole mantissa. For a three byte base 256 mantissa, this is: three digits, two that one can rely upon yielding only about 16 significant bits. For a three byte binary mantissa, this is: 24 digits (bits), 23 of which are significant, almost 50% more accuracy than base 256. For number crunching, this loss of accuracy with base 256 is unacceptable. Last year, a C compiler was needed for another project here where I work. It needed to compile on MS-DOS machines and generate Z80 code. The people working on it mentioned that they were considering an Aztec compiler. I told them of my past bad experience with it, but they bought it anyway. They've had nothing but trouble since then. The new compiler runs on MS-DOS and generates code for MS-DOS machines. To generate Z80 code, Manx supplies a separate code generator program, (but the rest of the compiler stays exactly the same). The new compiler is as buggy as ever, some of which have been very difficult to discover, let alone fix. The object modules produced require their proprietary linker which doesn't like to be told where to put various modules. In our application, it is mandatory that code be in ROM and variable data be in RAM. They still have the screwy base 256 floating arithmetic. 'nuff said? I consider this to be another compiler to avoid. James E. Prior {ihnp4|cbosgd}!n8emr!oink!jep ------------------------------------------------------------------------- From: ihnp4!n8emr!oink!jep To: n8emr!ihnp4!wrcola!kathy Subject: [ Aztec C ] MS-DOS cc The Aztec C Compiler does have one virtue. It does have most of the new ANSI stuff. ------------------------------------------------------------------------- >From n8emr!oink!jep Re: ANSI C Nothing in ANSI's proposed C standard is cast in concrete yet. I have been following its developements in various magazines. The people on the committee, all seem to be very competent people who actually want a clean language that lets them get their work done. Everytime they write an article about what's going on, they include where to send suggestions and get copies of whatever is the current spec. The most recent article that I dug out of my archives is from the July/August 1987 issue of Programmer's Journal. The tail of it is as follows: Future Meetings The schedule for future ANSI meetings is: September 14-18, Framingham, Massachusetts. The December 7-11 meeting scheduled for Phoenix, Arizona, has been replaced by the January 25-29, 1988, meeting at Austin, Texas. Rex Jaeschke is an independent computer consultant, writer, and lecturer. He is also a member of the X3J11 C Standard's Commit- tee. Co-founder and Editor of the C Journal, and the C Language Editor of the DEC Professional. If you would like to comment on or question any aspect of the Proposed ANSI C Standard, write to Rex Jaeschke 2051 Swans Neck Way Reston, VA 22091 Rex will address your concerns in future columns as space permits. <End of article> I've been impressed by all the articles. The articles are always as much to get feedback as they are to distribute the goings on. The ANSI C Standard doesn't affect me much yet, because I cannot rely upon coding to something that may change. There are some things I can't resist using immediately, but even then I try to write my ANSIish code so that I can readily revert to K&R. The new ANSI stuff that I can recall off the top of my head is: void type for functions that don't return anything. void pointers for pointers that really aren't typed such as the pointer returned by malloc. The new ANSI C is much stricter about implied type casts, and the void pointer helps ease the burden of having to explicitly cast every malloc. structure assignment, i.e. copying of whole structures. function prototyping: specifying the arguments of all functions more strictly, so that the compiler can do more type checking. There are sweating the details. James E. Prior {ihnp4|cbosgd}!n8emr!oink!jep ------------------------------------------------------------------------- From: rutgers!gatech!philabs!mergvax!lenoble Subject: Re: C compilers for MS=DOS machines I use a compiler from the MIX corporation, 2116 E. Arapaho, Suite 363, Richardson, Texas 75081. The compiler is very fast, cheap (I last saw an add in "Info World" where they sell the compiler, and excellent debugger, and an editor for about $100). One disadvantage of this compiler is that is does not create .OBJ files. It created intermediate files with a .MIX extention. The linker creates .EXE files. If you plan on linking in assembly language rountines, they have a utility to convert to assembly language .OBJ's to .MIX files. The compiler comes with a K&R set of library functions, and has special extentions for the MS-DOS environment. The manual that it comes with also inludes a nice tutorial on C for people who are just learning C. It has *LOTS* of examples. I would recommend that you get the debugger as well. It gives you source level debugging, allows you to set watch/break points, and also lets you examine and change the contents of variables and memory. I have only had to deal with the customer service department once and they were friendly and helpful. Orders are usually shipped within a week. Barry P.S. Maybe that sounded like an advertisement, but I'm just a happy customer. ------------------------------------------------------------------------- From: pc6300@cbnscs.UUCP (news admin) Subject: [DESMET] "C" Compiler for MS-DOS Organization: AT&T Network Systems, Columbus, Ohio I would like to recommend a very affordable "C" compiler for MS-DOS called "DESMET". It has full K&R compatability, plus an excellent screen, color, and cursor package, a full screen editor, and CLIST (a "pretty" listing w/ variables x-reference). It produces a compact object module. A debugger and a graphics package with commands reminiscent of GW-BASIC (circle, paint, etc.) are available at additional cost. The basic package is available for $109 from C Ware Corp., P. O. Box C, Sunnyvale, Ca. 94087. (408) 720-9696. I have absolutely no connection with either the author or the company. We used the package to develop the "AT&T Student Administration System" and are simply very satisfied users. ------------------------------------------------------------------------- >From: wtm@neoucom.UUCP (Bill Mayhew) Summary: Turbo C is pretty affordable/pretty good. Organization: Northeastern Ohio Universities College of Medicine Tubo C from Borland International is a rather pleasant compiler for MS-DOS based machines. The list price is often discounted to $65 or less. Turbo C is pretty full-featured and follows most of K&R and/or ANSI. The standard libaries supplied with turbo C compile code that should run on most MS-DOS machines as DOS interrupts are used rather than ROM BIOS calls or diddling with hardware. I have taken several Unix (tm AT&T) C programs and compiled them on an AT& T 6300, then run on a DEC Rainbow arfter Kermit transfer. I am not primarily a programmer, but rather an engineer. For a hacker such as myself, I have found T-C very useful and affordable. T-C's manuals are also nicely arranged for C neophytes. --Bill (wtm@neoucom.UUCP) ------------------------------------------------------------------------- >From bass.nosc.mil!crash!sdiris1!jjc Subject: Re: C compilers for MS=DOS machines I have been pretty happy with ECO-C88. Which does work nicely on the 1000. I think most of the C compilers will work on MS-DOS machines, but some libraries will not work correctly on funny machines. UUCP: ...!hp-sdd!crash!sdiris1!jim | Jim Carter or: ...!sdcsvax!jack!man!sdiris1!jim | Control Data Corporation (CIM) Work : +1 619 450 6516 | 4455 Eastgate Mall, Home : +1 619 455 0607 | San Diego, CA 92121 ------------------------------------------------------------------------- >From vijit!root I have the Microsoft C compiler. Although Lattice and others were more prevalent a while ago, I believe that msc is really gaining ground. I also believe that it's the most bug-free one around. You may want to investigate the Datalight C compiler (the new one w/optimizer). I *think* it's Datalight anyway. Some people have sworn by Borland's Turbo C, but I've read on Usenet here that it has contained mucho bugs and that Borland has not exactly been too responsive. Maybe that situation is done with now, I do not know. BTW, the version number on the Borland compiler remains at 1.00, you gotta check the compiler time/date stamp to see what you got. Sounds kinda eechy to me. Microsoft is upgrading to ver 5.0 in September. If you bought the 4.0 compiler after June, they'll give you a free upgrade to 5.0 when it's out. Dave Madsen ihnp4!vijit!madsen -------------------------------------------------------------------------