Re: Wanted: MS-DOS C compiler

vjs4@jaguar.uofs.edu
17 Jul 91 15:22:01 GMT

          From comp.compilers

Related articles
Re: Wanted: MS-DOS C compiler vjs4@jaguar.uofs.edu (1991-07-17)
| List of all articles for this month |
Newsgroups: comp.compilers,alt.msdos.programmer
From: vjs4@jaguar.uofs.edu
Followup-To: comp.compilers
Summary: Here they are
Keywords: C, MSDOS, summary
Organization: University of Scranton
Date: 17 Jul 91 15:22:01 GMT

I received some requests to have my replies to my request for PD C compilers
which work under MS-DOS posted, so here they are. I left in replies which
overlapped each other so that you could see how often each package was
reffered to.


I should have all the e-mail requests answered by tonight. If I have missed
anyone, I apologize, and If you send me a reminder I'll make sure that the
mail gets through (Through rain, shine, the gloom of night, mistyped
addresses... :-)


I have also gotten a few more sugestions not part of this list, which I will
post (or which are available on request) as soon as I get them together.


Have fun,


Vincent Shuta


------------------------------------------------------------------------------
Date: Wed, 10 Jul 91 12:13:40 -0400
Reply-To: Thomas B Boutell <boutell@brahms.udel.edu>
Organization: University of Delaware


No freebies, but it's worth mentioning that Power C (Mix C), from Mix Software,
only costs $20 and does what you need.


-------------------------------------------------------------------------------
Date: Wed, 10 Jul 91 09:32:10 PDT
Reply-To: raymond@math.berkeley.edu (Raymond Chen)
Organization: U.C. Berkeley


Check SIMTEL20; if you're willing to pay $20, get MIX C.


-------------------------------------------------------------------------------


Date: Wed, 10 Jul 91 11:21:08 MDT
Reply-To: Tony Foiani <afoiani@nmsu.edu>


I seem to remember a system called 'small c', designed for the 8088
PC. I can look it up if you're interested.


Tony
--
Tony Foiani a.k.a. Tkil (afoiani@nmsu.edu) or (mcsajf@nmsuvm1.bitnet)


-------------------------------------------------------------------------------
Date: Wed, 10 Jul 91 13:31:49 -0400
Reply-To: Santanu Lahiri <slahiri@magnus.acs.ohio-state.edu>
Organization: The Ohio State University


PD C/C++ Compiler? Hmmm, only one that I can recall at this time.
I've been reading quite a few articles about the DJGPP compiler,
you may want to give that a try. Available via anon ftp from
the wuarchive machine. DJ claims his compiler is XMS compatible,
and I saw a post from him saying he is working on making it DPMI
compatible as well.


I think his Email address is DJ@ctron.com, but if you poke around
the last 150 or so messages on this group you'll probably find five
or six posts from him.


I have never used DJGPP, nor have I seen the compiler yet. I just
said what DJ's posts mentioned. So I can not substantiate or refute
any claims.


------------------------------------------------------------------------------
Date: Wed, 10 Jul 91 11:23:17 PDT
Reply-To: litwin@robotics.jpl.nasa.gov (Todd Litwin)
Organization: Jet Propulsion Laboratory


I don't know of a public-domain compiler, but I do know of a compiler which
is *very* inexpensive. It is PowerC from MIX Software. It sells for $20 plus
about $5 (for shipping, I think). I bought it last year and am very pleased
with it. It has a support library which is compatible with Microsoft C, and
its documentation is very impressive. I compiled about 7000 lines of
portable C code without any problems. It may be true (although I don't know)
that more expensive compilers may run more quickly and produce tighter, faster
code, but this $25 compiler does pretty well. I would recommand it to anyone
who is even thinking about C under MS-DOS.


                    Todd Litwin
                    Jet Propulsion Laboratory
                    litwin@robotics.jpl.nasa.gov


-------------------------------------------------------------------------------
Date: Wed, 10 Jul 91 13:51:44 CDT
Reply-To: glratt@is.rice.edu (Glenn Forbes Larratt)
Organization: CRC OCIS, William Marsh Rice University, Houston, Texas


An MS-DOS gnu C++ compiler is available for anonymous ftp from simtel
and its mirror sites in


          PD1:<MSDOS.DJGPP>


You can look for such things by downloading PD1:<MSDOS.FILEDOCS>SIMIBM.IDX;
it's an index listing of stuff archived there.








--
Glenn Forbes Larratt | CRC OCIS
glratt@rice.edu (Internet) | Rice University
GLRATT@RICEVM2 (Bitnet)


-------------------------------------------------------------------------------
Organization: Concordia University, Montreal, Quebec
Date: Wed, 10 Jul 91 20:21:14 GMT
Reply-To: rclark@concour.cs.concordia.ca


PCC12C.ARC in MSDOS.C on simtel works, but it uses K&R style C.


--
rick clark (rclark@concour.cs.concordia.ca)
Concordia University, Montreal.


------------------------------------------------------------------------------


Date: Wed, 10 Jul 91 18:11:31 -0500
Reply-To: jamshid@emx.utexas.edu (Jamshid Afshar)
Posted-Date: Wed, 10 Jul 91 18:11:31 -0500
Subject: Re: Looking for public MS-DOS C compiler
Newsgroups: comp.os.msdos.programmer
In-Reply-To: <1991Jul10.112620.1@jaguar.uofs.edu>
Organization: The University of Texas at Austin; Austin, Texas




g++ (GNU's C++ compiler) has been ported to 386 machines. It's not
public domain, but it's the only non-commercial C++ compiler for MS-DOS.
--Jamshid
====================


This is the README file for DJ's GCC port to DOS.


Contents:
        * Overview
        * What's available
        * How to install
        * Common questions
        * Deviations and Caveats
        * Copyright information


Disclaimer: This software is distributed WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.












Overview:


This package contains a 32-bit 80386 DOS extender with symbolic
debugger, a C/C++ compiler with utilities, development libraries, and
source code. It generates full 32-bit programs and supports full
virtual memory with paging to disk.


Requirements:


A 80386-based IBM compatible PC or PS/2 is required. The 80387 emulator
currently does not emulate trancendental functions (exp, sin, etc).
Approximately 4-5Mb of hard drive space is required. 640K RAM is
required.


Supported Wares:


* Up to 128M of extended (not expanded) memory
* Up to 128M of disk space used for swapping
* SuperVGA 256-color mode up to 1024x768
* 80387
* XMS & VDISK memory allocation strategies


Unsupported:


* V86 programs, like QEMM, 386MAX, DesqView, Windows/386, etc.










File location:


        host: grape.ecs.clarkson.edu
        login: ftp
        password: send your e-mail address
        directory: ~ftp/pub/msdos/djgcc


NOTE: In accordance with FSF CopyLeft, you are not allowed to upload
this program to a distribution site unless that site also makes the FSF
sources for these programs available. Please read the file COPYING for
more details. FSF sources are available on prep.ai.mit.edu, and on
either grape.ecs.clarkson.edu or sun.soe.clarkson.edu


NOTE: If your application links in object modules that were written
by FSF, your application counts as a "derived work" and must obey
the provisions of the FSF Copyrights. See the file COPYING for
details. Specifically, the C++ classes in libc.a and obstacks are
FSF works that are covered by the GNU GPL. The mere act of compiling
does not affect the copyright status of your program.




File formats:


        .ZIP format - djgpp.zip - one 2.2M file, contains everything.


        split .ZIP - djgppzip.000 through djgppzip.065 (or so), each
                                  32K. Use the merge program to merge them into
                                  djgpp.zip ("merge djgppzip djgpp.zip").


        other - readme, merge.c/.exe, split.c/.exe are separately available






Directories:


        bin all binaries (cpp, cc1, extender, etc)
        lib all libraries (crt0.*, libc.a, libgr.a, libpc.a)
        include all include files (arc'd tar file)
        docs all documents (including this one)
        go32 sources for the extender
        drivers various SuperVGA drivers
        libsrc sources for the libraries (arc'd tar file)
        diffs diffs from FSF distributions to dos-compilable
        utils sources for the utilities
        samples sample C++ sources using graphics & mouse
        emu387 80387 emulator for non-80387 systems (currently TEST version)




bin:
        bison.exe lalr(1) parser
        flex.exe lexical parser
        cpp.exe C and C++ preprocessor
        cc1.exe C compiler
        cc1plus.exe C++ compiler
        as.exe 80386/80387 assembler
        ld.exe a.out (BSD) format linker
        ar.exe archive utility
        nm.exe name list utility
        size.exe a.out section size utility
        strip.exe symbol stripper
        objdump.exe display info from .o file
        gcc.exe compilation coordinator
        go32.exe basic 32-bit DOS extender
        debug32.exe 32-bit DOS extender with symbolic debugger
        stub.exe stub to prepend on aout files to make .exe files
        aout2exe.bat turns aout file to .exe by prepending stub.exe
        diff.exe creates diffs, including context diffs
        patch.exe patches source from diffs, including context diffs
        djtarx.exe tar extractor for FSF tarfiles if you don't have a tar
        utod.exe convert Unix text files to DOS text files
        dtou.exe convert DOS text files to Unix text files
        split.exe split big binaries into many little binaries
        merge.exe merge many little binaries back into one big binary


lib:


        libc.a all standard routines (BSD style), and C++ methods & support
        libm.a math routines
        libgr.a graphics routines and mouse support
        libpc.a routines for PC support (in/out, getkey, kbhit, screen utils)
        crt0.s C runtime source
        crt0.o C runtime object
        bison.simple bison support
        bison.hairy bison support
        flex.skel flex support file
        libflex.a flex support library


include:


        Most BSD-style and SYSV-style include files. These mostly came from
        the G++ sources.
        sys/*.h MS-DOS specific
        graphics.h for libgr.a
        pc.h for libpc.a
        mouse.h for mouse routines in libgr.a


docs:


        readme this document
        copying GNU General Public License
        copying.dj Copyright information for items (C) DJ Delorie
        debug32.doc instructions for the symbolic debugger
        internal.doc information about how the extender works
        libc.a differences and enhancements
        libm.a list of implemented functions
        libpc.a documentation
        libgr.a documentation


go32:


        sources for the extender. Requires Turbo C and Turbo Assembler


drivers:


        VGA and SuperVGA drivers - source and binary. Use the GO32 environment
        variable to select and configure one of these according to the VGA card
        you have.


libsrc:


        Sources for the libraries. These are compiled with gcc. The makefile
        is set up for NDMAKE. The source files came from three sources:


                (1) Me. Mostly the system call routines, and some string routines.
                        All of libpc.a, libgr.a, libm.a .
                (2) FSF. These are the GCC support routines, C++ support, and
                        other routines that came with gcc (malloc, obstack, alloca, etc)
                (3) BSD. These are mostly the stdio and stdlib routines, and
                        the rest of the string routines. BSD requires that I mention
                        that their sources are copyright BSD and that I have modified
                        some to comply with the include files provided by FSF. These
                        sources are the "freed files" everyone keeps talking about.


diffs:


        Context diffs from the original FSF sources to the GNUDOS sources. See
        the README and VERSIONS files in that directory for more info.


utils:


        Sources for djtarx, utod, dtou, split, and merge.


samples:


        Various samples showing how to use the mouse, graphics, C++, setjmp(),
        etc.


emu387:


        80387 emulator and source code. Currently, this is a TEST version, as
        I'm not done with it yet. Trig, log, exp functions are missing, for
        starters. I don't expect this to work perfectly, but should cover
        most normal floating point math. To use, add "emu /djgcc/emu387/emu387"
        to the GO32 environment variable. (ie: set GO32=emu /djgcc/emu387/emu387)
















INSTALLING:


To install, you must do the following:


* Create a directory to install in, like c:\djgpp.


* Create a "temp" directory, like c:\tmp.


* Un-zip djgpp.zip in that directory.
        C:\DJGPP> pkunzip -d djgpp.zip


* Add the following lines to C:\AUTOEXEC.BAT:
        set gccbin=c:/djgpp/bin
        set gccinc=c:/djgpp/include
        set gcclib=c:/djgpp/lib
        set gcctmp=c:/tmp (TMP and TEMP are checked if this isn't set)
        set go32=ansi driver c:/djgpp/drivers/tseng4k.grd gw 1024 gh 768
                                                  ^^^ or whatever driver works with your VGA (optional)
        set bison_simple=c:/djgpp/lib/bison.simple
        set bison_hairy=c:/djgpp/lib/bison.hairy
        set flex_skeleton=c:/djgpp/lib/flex.skeleton
    Remember that unless you manually type these at the command line,
    they won't take effect until you reboot. Don't include the "ansi"
    keyword in the "go32" variable if you don't have an ANSI.SYS driver
    or equivalent.


* Add your binaries directory to your PATH in C:\AUTOEXEC.BAT
        SET PATH= . . . ;C:\DJGPP\BIN


That's it! G++ is now installed on your system.










The GO32 environment variable:




This variable controls the options available in go32 or debug32. The
syntax of this variable is:


    SET GO32=[parm [value]] [parm [value]] . . .


Parameters:


    ansi Use ANSI commands to control the color in debug32
    mono Use the Monochrome monitor for debugging - useful when
                                      debugging graphics applications
    emu [path] Use the specified file as the 80387 emulator
    driver [path] Use the specified file as the graphics driver
    gw [width] Default graphics width
    gh [height] Default graphics height
    tw [width] Default text width
    th [height] Default text height


These parameters may occur in any order.


Examples:


    C:\> set go32=mono driver c:\djgpp\drivers\tseng4k.grd gw 1024 gh 768 tw 132 th 43






    C:\> set go32=ansi
    C:\> set go32=driver c:\djgpp\drivers\tseng4k.grd ansi














Common Questions:


Q: When I run "gcc e:\proj\prog.c" it says "undefined escape sequence \p"?
A: Gcc is a *unix* compiler - you must use *unix* slashes (e:/proj/prog.c).
      Environment variables (like GCCINC) may, however, use either, as they
      are converted.


Q: I type "GCC PROG.C" and ld complains about PROG.C not being an object.
Q: I type "gcc prog.cxx" to compile a C++ program, and ld complains.
A: Gcc is *not* case insensitive like DOS is, and it uses the file's
      extension to determine how to compile a file. Valid extensions are:
          .cc = C++ source (passed through cpp)
          .c = C source that must be passed through cpp first
          .i = raw C source (no cpp pass)
          .S = assembler that must be passed through cpp first
          .s = raw assembler source (no cpp pass)
      any other file is passed to the linker


Q: I compile my program, but can't run the output file.
A: DOS doesn't know how to run unix-style a.out files. That's what the
      extender is for. To run an a.out file called myprog, type
          "go32 myprog . . ."


Q: Gcc doesn't recognize // as a comment in my C programs.
A: That's because // isn't a comment in C. If you want to compile C++,
      then write C++ programs. Gcc is really two compilers in one, not
      one compiler that compiles both C and C++. That's why you get
      cc1 and cc1plus.


Q: I'm reading in data files, but the data gets corrupted.
A: The default file type is DOS text, even for read() and write(). You must
      tell the system that a file is binary through the "b" flag in fopen(),
      or O_BINARY in open().


Q: I get "fatal signal 2" when I run gcc.
A: When gcc reports a "signal", it really means that an error occurred
      trying to run the given program. The "signal" number is the DOS error
      code, and 2 means "file not found". Check the GCCBIN environment
      variable and make sure it points to the directory with cpp.exe,
      cc1.exe, etc.


Q: The binaries I get with the distribution are .exe files, but gcc creates
      a.out files. I rename the a.out's to .EXE's, but they still don't work.
A: To get an .EXE from an a.out, you must *prepend* either go32.exe,
      debug32.exe, or stub.exe to the file:
          copy /b stub.exe+myprog myprog.exe


Q: What is stub.exe?
A: Stub.exe simply calles go32.exe, and passes it information it needs to
      run the a.out file attached to it. Stub is much smaller than go32, so
      less disk space is used. Also, if you change go32, you don't have to
      change stub, and all the stub-ized programs will use the new go32
      automatically.


Q: I want to change cc1. How do I do this?
A: First, get the GNU sources from FSF. They're usually available at
      prep.ai.mit.edu in /u/emacs, if not elsewhere. Use djtarx to un-tar
      them, as djtarx knows how to handle unix file names that aren't valid
      DOS file names. Look in the "diffs" sources to see what to change the
      names to when they conflict. Next, apply the "diffs" over the
      GNU sources (making sure you have the right version of GNU - see the
      versions file). For the gcc-1.39 sources, you must run utod (or some
      other unix-to-dos converter) to compile gcc.exe, then run config-d.bat,
      then run makeall.bat. For gpp-1.39, copy the g++ sources over the
      completed gcc sources, apply the gpp diffs, then run makeall.bat (gpp's
      now). For all other programs, just run make. Note that the makefiles
      are tuned for ndmake, since it knows how to make response files.


Q: I don't have an 80387. How do I compile floating point programs?
A: Add "emu c:\djgpp\emu387\emu387" to the GO32 environment variable
      (see go32 section above). This tells go32 to use the given file
      as an 80387 emulator. This emulator does not support trancendental
      functions like exp or sin yet, but it works well enough for compiles
      and standard +-*/ functions, including sqrt(). If you don't load
      this emulator, and you try to run floating point without a 387,
      you will get an error.


Q: I installed an 80387 emulator in my AUTOEXEC, but it still doesn't
      work. Why?
A: The CPU is running in *protected* mode, not real mode, and the information
      needed to emulate the 80387 is different. Not to mention that the
      exceptions never get to the real-mode handler. You must use the emu387
      emulator, which is designed for go32.


Q: I can't run a.out programs under {QEMM,386MAX,Windows}.
A: Nope, you can't. These applications put the CPU into V86 mode, not
      real mode, so go32 can't manage the real-protected interface
      properly. Go32 literally *takes over* the computer in order to
      properly service the application it is running.


Q: Can I run this on my 286? It has protected mode also...
A: True, but the 286 isn't a 32-bit processor. A 386 really is required.


Q: Can I use gcc on my 512K machine?
A: Yes, but the disk better have at least 4Mb of free space for paging.
      Go32 will use all available extended memory (up to 128M) and up to
      128M of disk space, for a grand total of 256M of virtual memory for
      your application. Try a malloc(50*1024*1024) some day.


Q: Why do my compiles are running VERY SLOW, even though I use a ramdisk
      for swap and a disk cache?
A: Gcc requires at least 1Mb of virtual memory to run, usually close to 1.5M.
      If there isn't this much real memory available, it starts paging to disk.
      It's good to leave about 1M of extended (not expanded) memory available
      for go32 to run programs with. When it needs to page a lot, you spend
      most of your time paging and little time actually running.


Q: How much memory is available when I use the system() call?
A: Everything but what go32 is loaded with. The program is completely
      paged out to memory (including the page tables themselves) before
      the second program is executed.












Deviations and Caveats:


GCC/G++ deviates from the U**x version in a number of ways, mostly to
accomodate deficiencies in the MS-DOS environment, and my own laziness.


* An 80387 is required to do floating point. An emulator is provided,
    but it does not support all the 80387 functions (it does +-*/ sqrt).
    cc1 and cc1plus shouldn't use the 387 unless compiling floating point
    code. The environment variable "387" can override the auto-detection
    routine:
        SET 387=YES to force 387 handlers to be enabled
        SET 387=NO to force 387 accesses to fault
        SET 387=QUERY to get a message showing the results of the auto-detection
    If no 80387 is present and the program attempts to use it, a message
    indicating where the instruction is will be displayed. To use the
    387 emulator, add "emu c:\djgpp\emu387\emu387" to the GO32 environment
    variable


* The VDISK method of allocating extended memory is supported. The
    INT 15h method is also. When the extender runs out of conventional and
    extended memory, it uses a paging file named $(GCCTMP)/pageXXXX.386, where
    XXXX is an unspecified hex value. This file is normally removed on exit.


* Up to 128 MB of physical memory and 128 MB of disk swap space are allowed.
    A 512K machine is sufficient, but very slow due to paging.


* The utilies support the MS-DOS standard response file method for giving
    more than 128 bytes of command line. Example: "gcc -o foo @foo.lnk" where
    foo.lnk contains a list of .o files.


* Since MS-DOS does not distinguish case in file names, some .h files
    used for C++ have had underscores prepended to them to avoid conflict
    (ie: String.h conflicts with string.h, so it became _String.h).


* When using ar to create archives, be warned that the ar version
    supplied cannot update an archive that's been sequenced (ar s foo.a),
    and cannot sequence a file that's been sequenced. Also, ld cannot
    use an archive that's not sequenced. The following method is suggested:
            ar rv mylib.a $(OBJS)
            cp mylib.a mylib2.a
            ar rvs mylib2.a
            (and then link with mylib2.a)


* The extender can be added to any gcc-compiled program by copying go32.exe
    to be <program>.exe, where <program> is the 32-bit program. For example,
    cc1plus is a gcc-compiled a.out file. cc1plus.exe is a copy of go32.exe.
    When the extender runs, it looks for a file of the same name but without
    extension in the same directory, and executes it if present. Otherwise,
    the first parameter is the executable (ie: go32 cc1plus foo.cc).


* The extender can be merged to create one .exe file that is the extender
    and the executable in one file, by using the stub.exe program:
            copy /b stub.exe+myprog myprog.exe
    This will only work if go32.exe is in your search path, because stub.exe
    runs it. Alternatively, you can prepend go32.exe itself to an a.out file
    to get a single executable (stub.exe is much smaller). Note that if
    you re-compile go32 or stub, you must strip off the symbol table first.


* The extender runs programs at logical address 0. A copy of the first
    1 MB of physical memory (including the AT channel) is mapped to
    0xE0000000 in the program's address space. The stack grows down from
    0x7FFFFFFC in the program's address space. Data usually starts at
    0x00400000.


* The paging mechanism understands how SuperVGA's map their memory onto
    the AT bus and automatically swaps pages as the program tries to
    access them. The program sees a linear range from 0xD0000000 to
    0xD0100000 that corresponds to each pixel in the 256-color modes
    of SuperVGAs. To use this feature, you'll have to set the GO32
    environment variable like this:
        C>set go32=driver c:\djgpp\drivers\tseng4k.grd gw 640 gh 480 tw 132 th 43
    These parameter pairs can be omitted or rearranged as needed. They are
    the "driver" name, default graphics width and height, and default
    text width and height. Libgr.a doesn't have to be recompiled, nor
    do graphics programs, when a different graphics mode is selected
    (the extender handles it). It is strongly recommended that the program
    use the GR_default_graphics and GR_default_text modes to switch to
    graphics or text. These modes use the parameters specified by the
    GO32 environment variable, allowing the user to select a favorite
    graphics and text mode.


* Symbols are stored in virtual memory, so you won't run out of symbol
    space until both extended memory and the disk are all used up. For
    large programs, you might notice a slight delay while it looks up
    symbols.


* Signals are not reported to the program. However, interrupts do continue
    to get serviced while in protected mode (ie: keypress, timer, etc).
    CTRL-C will get you back to the debugger in debug32, and you can continue
    from where you stopped. All signals (ie: exceptions) cause debugging
    traps in debug32, or general faults in go32.






Copyright Information:


* Source code for the GNU utilities is copyright (c) Free Software Foundation.
    For more information on the FSF copyright, see their source code or write
    Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
    A copy of their file "COPYING" is included in doc.arc. Some of the FSF
    source code has been modified to operate properly in the MS-DOS environment.


* Source code for most of libc.a are copyright (c) Regents of the University
    of California. These files include copyright information in them. The
    utilities are compiled against these libraries, and thus contain software
    developed by the University of California, Berkeley, and its contributors.
    Some of the BSD source code has been modified to operate properly in the
    MS-DOS environment.


* Any sources not falling under the copyrights of FSF or UCB (as above) are
    Copyright (c) 1991 DJ Delorie, 24 Kirsten Ave, Rochester NH 03867-2954.
    To contact me via E-Mail, sent to "dj@ctron.com". Cabletron Systems Inc
    is in no way involved with this project; I just happen to work for them
    during the day.


Terms and Conditions:


* Source code copyright FSF is distributed under the terms of the GNU
    Public General License. See the file "COPYING" in doc.arc for more
    information. If your program links in object modules (in libc.a) that
    are compiled from GNU sources, then your entire program must be
    distributed under the terms of the GNU GPL as a "derived work". These
    modules are the C++ class library (including the streams classes) and
    obstacks. The sources in libsrc have the copyright notices in them
    for the various modules.


* Source code copyright UCB is distributed under the terms listed in the
    UCB source code itself.


* Source code copyright DJ Delorie is distributed under the terms of the
    GNU General Public Licence, with the following exceptions:
    (source code and executables copyright DJ Delorie are referred to as
      "djcode" below)


    1 If the user of this software develops an application that requires
        djcode to run, and that application is distributed under the terms
        of the GNU General Public License (GPL), a binary executable of
        djcode may be distributed with binary executables of the application,
        and source files for djcode must be available with source files for
        the application, under the terms of the GNU GPL.


    2 If the user of this software develops an application that requires
        djcode to run, and that application is NOT distributed under the terms
        of the GNU General Public License (GPL), a binary executable of
        djcode may be distributed with binary executables of the application,
        provided a royalty of 5% of the total sale price or $5 (whichever is
        more) per copy sold is paid to DJ Delorie (at the address above).
        Requests for exceptions may be made to DJ Delorie, but the granting of
        an exception covers only the work excepted and does not apply to
        other works, even if distributed under the same conditions. Exceptions
        will not be granted for any work sold for profit.


    3 A person or organization who develops software that requires djcode
        but does not distribute that software under the terms of the GNU GPL
        relinquishes all rights to obtain or redistribute the source code
        for djcode, including any rights granted by the GNU General Public
        License, and may only distribute executables of djcode under the
        terms of exception 2, above.


    The intent of this copyright is this: If you make money by using the
    programs I wrote, I get some of it. If you use your sources to
    teach others how to write programs, I'll support you.


    Changes to source code copyright BSD or FSF are copyright DJ Delorie, but
    fall under the terms of the original copyright.










Donations may be made to any of the following:


        DJ Delorie
        24 Kirsten Ave
        Rochester, NH 03867-2954
        USA


        Free Software Foundation
        675 Mass Ave
        Cambridge, MA 02139
        USA


        University of California
        Berkeley, CA (sorry, I don't know their ZIP code)
        USA


-------------------------------------------------------------------------------


Subject: Re: Looking for public MS-DOS C compiler
Newsgroups: comp.os.msdos.programmer
In-Reply-To: <1991Jul10.112620.1@jaguar.uofs.edu>
Organization: AT&T Bell Laboratories
Date: 10 Jul 91 15:40:52 EDT (Wed)
Reply-To: rbr@bonnie.ATT.COM (Bob Rager)




Look for the "Personel C Compiler" in the SIMTEL20 archives. It's a
full implementation "C" compiler. It is free. It only does a small
model which isn't a constraint for many C program. Its only a problem
when you have more than 64K of data or very large arrays.


Hope this helps.


Bob Rager


-------------------------------------------------------------------------------


Date: Thu, 11 Jul 91 02:13:17 +0200
Reply-To: d0olsson@dtek.chalmers.se (Olof Olsson)
References: <1991Jul10.112346.1@jaguar.uofs.edu>


Alright, you want public domain or shareware. I don't think you can get
a good compiler in that way, or do you prefer GNU-C++. I don't know if
GNU is available for use with DOS. In any way...


WHY don't give Borland and their TC++ version 2.0, a real try???
I'm running a version 1.0 and I think TC++ version 2.0 (the current one)
is the most optimal programmers environment. You can even forget
the 640 Kb limit, both with the compiler and in your own programs.
It will handle overlays almost invisible for the user (programmer).


                                        Sincerly
                                        Olof Olsson, d0olsson@dtek.chalmers.se
-------------------------------------------------------------------------------


Date: Thu, 11 Jul 91 08:06:42 GMT
Reply-To: kstock@gouldfr.encore.fr (Kevin STOCK - MIS (Compta))
Subject: Re: Looking for public MS-DOS C compiler


Try the Personal C Compiler (also known as DeSmet C) which you can find
on Simtel and most other archives. It's shareware (registration $30, which
also gets you a disk of supporting tools), programs created with it are
limited to 64K code and 64K data.


The manual specifies the float and double types:


                float Four byte floating point value. A float number has
                                      about 7 digits of precision and has a range of about
                                      1.E-36 to 1.E+36. The floating point formats are
                                      defined by the IEEE floating-point standard.


                double Eight byte floating point value. A double number has
                                      about 13 digits of precision and a range of about 1.E-
                                      303 to 1.E+303.


I think the current archive name is pcc12c.arc .




Kevin Stock
kstock@gouldfr.encore.fr


-------------------------------------------------------------------------------
Date: Thu, 11 Jul 91 08:54:44 CDT
Reply-To: Amit Jayant Patel <amitp@owlnet.rice.edu>
Subject: Re: Looking for public MS-DOS C compiler


I don't know of a public domain C compiler, but may I suggest
you look for Power-C? It's $20 (YES!) for the whole thing
except debugger, and its library is supposed to have all the
functions of both Borland and Microsoft's libraries.


          I've heard it's very good too! (But I've never tried it)


                    Amit Patel


-------------------------------------------------------------------------------


Date: Thu, 11 Jul 91 10:07:35 -0500
Reply-To: Tom Epperly <epperly@osnome.che.wisc.edu>


Note: The DJGPP.ZIP has been repackaged into four smaller ZIP files in
order to avoid problems in merging pieces together to reconstruct the
large 2 megabyte ZIP originally released by the author. These files
are available in this archive as DJGPP1.ZIP, DJGPP2.ZIP, DJGPP3.ZIP,
and DJGPP4.ZIP.


                                      Signed: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
                                                        Maintainer of the SIMTEL20 MS-DOS archives


---


This is the README file for DJ's GCC port to DOS.


[Removed since it appears earlier.]


-------------------------------------------------------------------------------


Reply-To: davidsen@crdos1.crd.ge.com
Organization: GE Corporate R&D Center
Date: Thu, 11 Jul 91 16:19:05 EDT


gcc has been posted to cbip and will be reposted shortly. It requires a 386.
---
bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
    GE Corp R&D Center, Information Systems Operation, tech support group
    Moderator comp.binaries.ibm.pc and 386-users digest.


-------------------------------------------------------------------------------
Date: Sat, 13 Jul 91 19:20:13 PDT
Reply-To: raymond@math.berkeley.edu (Raymond Chen)
Subject: Re: Looking for public MS-DOS C compiler
In-Reply-To: <1991Jul13.133222.1@jaguar.uofs.edu>
Organization: U.C. Berkeley


[prerecorded message]


[$Id: compilers 1.2 90/09/28 12:17:30 raymond Exp Locker: raymond $]


The debate over which C compiler to use has reached religious proportions in
the IBM PC community. The good news is that due to stiff competition, all of
the leading compilers are roughly equal, differing mostly in assorted details
here and there, though some philosophical differences remain.


The bottom line is this: No matter which compiler you pick, you will probably
not be making a mistake.


The two major contenders are Borland's Turbo C and Microsoft's MSC. There are
of course other compilers of substantial merit, but these two tend to be the
main camps. MIX C does seem to be popular at the low end of the spectrum,
though.


What follows are comments culled from the net. Additional contributions
and corrections to this file are welcome.


===============================================================================
Okay, since this is my file, I'm going to be a bit egotistical and put my
comments first.


---------- Who does this guy think he is? ----------


I am a registered owner of both Turbo C (2.01) and MSC (6.0).
I'm quite familiar with the code each produces, so much so that
if you handed me an .EXE, I could tell you which compiler produced it.
(Provided it was either Turbo C or MSC. All bets are off if you
hand me Zortech, etc.)


---------- A brief history ----------


In the beginning, there was Microsoft. If you wanted a Pascal compiler, you
got Microsoft's. If you wanted a COBOL compiler, you got Microsoft's. If
you wanted a FORTRAN compiler, you got Microsoft's. Microsoft didn't have
very much competition back then. You didn't ask around for a C compiler
because C hadn't become popular yet.


Then Turbo Pascal appeared. With its aggresively low pricing (around $30 for
Turbo Pascal 3.0, as I recall), Borland captured practically the entire
hacker market. The hip language to do your programming in was Pascal. If
you look at shareware programs produced back in the mid 1980's, you'll find
that nearly all of them were written in Turbo Pascal.


As a consequence of the "hacker-oriented" philosophy of Borland, their
programming languages contain lots of nonstandard language extensions aimed
at the "power hacker". For example, Borland's languages support inlined
assembly language and permit direct access to processor registers and I/O
ports.


With this single product, Borland captured the leading position in the
"Programming languages for average people" market, a position which it
continues to hold.


Although Borland retains the lead in market share, Microsoft still holds the
lead in code generation. Even back in the CP/M days, Microsoft compilers
performed common subexpression elimination. (When I saw common subexpression
elimination happening on my 48K CP/M machine, I was completely
flabbergasted.)


While Borland worked hard at flashy user interfaces, Microsoft worked hard at
teaching their compilers to optimize code better.


Borland's compilers emit relatively straightforward code. An experienced
assembly language programmer can de-compile the code produced by Turbo Pascal
and Turbo C without too much difficulty. For example, even with all the
optimizations turned on, Turbo C 2.01 produces code for the redundant
instructions labelled below:


        foo()
        {
            int i;


            i = 2; /* code for these three lines */
            i = 3; /* is emitted, even though they */
            i = 4; /* are completely useless */
            i = 5; /* (Actually, this line is useless, too.) */
        }


Microsoft's compilers, on the other hand, are amazingly aggressive
optimizers. MSC optimized the entire function above to the null function.
MSC also performs complicated code motions, loop optimizations, and even
recognizes when it can merge two code paths together. (Those Microsoft
programmers obviously studied the Dragon Book.)


Of course, all this heavy optimization has its costs: Compilation speed.
Borland's compiler is amazingly fast because it doesn't think very hard. It
just blasts away. Microsoft's compiler is slower because it analyzes your
code much more carefully in an attempt to produce the best code it can
muster.


---------- So which should I buy? ----------


It depends.


If you are just a hacker, Turbo C is probably a better choice. You won't
need the mega-optimizations that MSC performs, and you'll probably enjoy the
snazzy integrated environment. If you are still running a slow XT-class
machine with a small hard drive (like I am), then Turbo C is the way to go;
MSC is just too God-awful big and slow for such a low-end machine.


If you are a serious professional programmer, MSC is probably a better
choice. You probably don't use integrated environments because you already
have your favorite editor. But you are very concerned with the quality of
the code your compiler produces; although there are still some intolerably
clever optimizations that MSC misses (e.g., using BP as another register
variable), for the most part, the emitted code is darn close to what I would
have written by hand. (Though it still misses some "obvious" things, like
using a register as a base register when dealing with pointser to
frequently-used structures.)




Price: Turbo C easily.
Size: Turbo C 2.0: 6 360K disks.
                                MSC 6.0: 7 1.2M disks (or 14 360K disks)


                                MSC eats up lots of disk space.


Frill programs: MSC has more frills, including a standalone editor.


Compiler speed: Turbo C.
Code quality: MSC.
OS/2, Windows: MSC can produce code for OS/2 and Windows.


Manuals: MSC.


                                MSC's reference manual is spiral-bound rather than
                                glue-bound, which means you can open it flat
                                on the table. MSC also comes with a separate manual
                                for people who want to squeeze the last drop out
                                of their code. Most of the MSC manual is not printed,
                                though; instead, it all available in on-line help.
                                This chews up more disk space.


                                Borland's manuals are glue-bound, which makes it hard
                                to hold them open. Functions start where the previous
                                one left off, which means that most of the time,
                                functions start in the middle of the page. Also, the
                                guide words at the top of the odd-numbered are the
                                name of the first function rather than the last function
                                on the page (opposite of how dictionaries work). Combined
                                with the function-in-the-middle-of-the-page layout,
                                this means that the guide word for odd-numbered pages
                                often has little to do with what's actually on that page.


                                Borland includes no language reference, preferring instead
                                to scatter information about the C language throughout
                                its tutorial. The word "lvalue" isn't in the index, which
                                is annoying when you get the error "Lvalue required" and
                                can't figure out what an lvalue is.


Debuggers: I'm not qualified to compare them, since I've never used
                                the standalone Turbo C debugger.


---------- Concluding thoughts ----------


I have not mentioned the other players in the C compiler drama because I have
had only limited experience with them.


                                -- Raymond Chen (raymond@math.berkeley.edu)


You should be able to find reviews and comparisons of C compilers in the major
computer periodicals. Here's what I found:


Doctor Dobb's Journal:
        Aug 88 : MSC 5.1 v. Watcom C 6.0 v. Turbo C 1.5
                            v. Datalight C 3.1 v. Computer Innovations C86+ 1.1
        May 89 p 68: Quick C v. Turbo C
        Jul 89 p 64: Turbo Debugger
        Aug 89 p 89: Quick C v. Turbo C
        Sep 89 p 74: Watcom C 7.0
        Jan 90 p 64: Zortech C++ 2.0
        Apr 90 p 72: Topspeed C
        Jun 90 p 62: Instant-C
        Aug 90 p 84: MSC


The remaining comments have been sorted by compiler.


===============================================================================
MIX Power C
===============================================================================
Materials:
        Four 360K disks and two manuals.


Cost:
        Compiler = $20, Debugger = $20,
        Library source and assembler = $10,
        Shipping = $5


        BCD Business Math = $10


        C/Database Toolchest (B+ Tree ISAM library) = $20 (+$20 for source)
                supports Power C, MSC, QC, TC.


Compiler:
        Claims to be ANSI-compliant, but isn't really. Handles prototypes
        and ANSI-style preprocessing, but otherwise doesn't seem to be
        fully ANSI-compliant. (See [9]'s comments below.)


        Supports interrupt functions.


        Version 1.3.0 supports only medium model.
        A newer version (v2.0.0?) supports small, medium, large and huge models.


        Optimization phase cannot be disabled(!). A definite problem
        since the optimizer sometimes encounters internal fatal errors.


      "The compiler itself is decent, but no world-beater.
        What do you expect for $20? ... Produces generally quick
        but not particularly compact code." [2]


      "Not as fast with its code as it's cracked up to be. Yes, it compiles good
        benchmarks, but average programs seem to come out slower, which leads me
        to suspect that the standard benchmarks are specifically optimised." [7]


      "The compiler is a little slower than some of the other products on the
        market, but the executibles are often smaller and faster than Turbo C
        and Microsoft C." [5]


      "The (mandatory) optimizing step of the Power C compiler sometimes
        gags with no explanation. ... Their tech support is not very helpful." [3]


      "The compiler isn't quite as good. It does a fairly good job of
        compiler correct programs, but it isn't good for developing. " [9]


      "Type checking is a joke. I could assign values to variables declared
        to be `const', I could use floats as parameters to functions that used
        chars in the prototype, and so on without any complaints. ...
        It uses [a useful but undocumented] pseudo-function `Defined(typename)'.
        Unfortunately, `Defined' is in the user name space (according to ANSI)
        so if you have a program that uses `Defined' you're in for trouble." [9]


      "Compiler is not really ANSI compatible. It was more a case of a K&R
        compiler, extended to understand prototypes and enums. The version I
        had did *not* check function calls agains prototypes as ANSI required.
        I'd be cautious about their claims to ANSI compatibility - unless
        it was substantiated by naming a particular test suite. Among other
        things it failed to compile Duff's device in most of its forms." [0]


Known bugs:
        Arrays of pointers to functions are buggy [3].


        ANSI violations as noted above by [9].


      "sprintf() doesn't work correctly for some formats, rand()/srand()
        doesn't work at all as it should, Duff's device fails to compile, etc." [9]


      "I sent the MIX people a disk with around 14 bugs, some serious, in
        March [1990]. I haven't heard from them, so I can't say how serious
        they are about fixing bugs." [9]


      "In some cases, redirected standard file descriptors weren't inherited
        properly by children." [10]


      "Mix isn't too bad if you don't push it very hard.
        It doesn't handle arrays of functions very well,
        and the /q switch to create Microsoft-compatible object files
        doesn't do anything at all." [0]


Library functions:
        Contain many of the Turbo C and Microsoft C functions.
        Also contains many System V functions.


      "Get the library source. It's only $10." [1]


Manuals:
        Includes a C tutorial and function reference.
        Every function gets a sample program.
        Many people say the manual itself is worth the $20. [0, 0, 6, 8]


      "About [the] best beginner's tutorial bundled with any compiler." [2]


      "I would recommend a beginner buying the compiler just for
        the documentation." [4]


      "Vastly superior to the documentation provided with Turbo C 2.0." [5]


Object files:
        Produces .MIX files (a proprietary object file format).
        Includes a utility to convert .OBJ files into .MIX files,
        but not vice versa.


      "If you want to link with higher-level languages,
        there is simply no way to do it." [0]


      "I would think twice about buying Power C if you will be
        interfacing with 3rd party function libraries or you have a need
        for inline assembly." [1]


      "The MIX utility that they've included to convert .OBJ files to the .MIX
        format will sometimes give the error message ``Could not process
        threads.''" [3]


      "I never got it [the .OBJ -> .MIX converter] to work properly." [0]


Integrated Environment:
        Doesn't have one.


Debugger:
      "Seems to have your normal complement of debugging features:
        breakpoints, watchpoints, multiple windows, trace execution, etc." [1]


      "The easiest debugger to use I have seen.
        Much better than Codeview or even the debugger built into Turbo C." [5]


      "I quickly discovered a way to crash it. [version 1.2.0]" [6]


      "It is surprisingly good, considered its price. In fact, it almost
        makes up for the compiler." [9]


      "The Ctrace debugger is limited to 64K symbol table space; unfortunately
        this quickly fills up when debugging programs having large numbers of
        structures and/or global variables. This is a shame as the debugger
        appears to be very good aside from this limitation." [11]


Utilities:
        The assembler that comes with the library source code is
        not MASM-compatible and comes with minimal documentation.


Support:
      "Very good. Their policy is to send a free upgrade when
        you report a bug." [1]


      "[Spent] all day today trying to get through to tech support! ...
        [They] could not tell me exactly why [the error] happened,
        how to fix it, or ... how to ... work around it." [3]


      "I set Power C as the `textbook' for a C programming unit at our Uni. ...
        When some of the shipments did not arrive, our bookshop tried every
        way known to man to contact that mob, but just could not get a reply out
        of them. And orders of hundreds of copies were involved, not just one!
        It makes me wonder what chance a buyer of one copy would have of getting
        any sort of support out of them. But then, at that price, what can you
        expect?" [7]


      "I reported a bug in an earlier version; they sent me a library source code
        patch for it, since I had purchased the library source code. I can't
        vouch for their support otherwise, having had no other problems." [8]


      "The tech support is not very knowledgeable, good mostly just for reporting
        bugs." [1]




To Order:
        1-800-333-0330


General consensus:
        A real bargain for the price. (Nearly unanimous agreement on this.)


        Good for beginners with small to medium-sized programs.
        Not for serious programming or large projects. (General agreement here.)


        Excellent manuals.


        Has some problems, but everyone adds, "What did you expect for $20?"


      "I've had the compiler for years now and have very few complaints." [1]


      "I am very satisified with this product." [11]


[0] anonymous postings from various places
[1] Bill Svirsky (svirsky@ttidcc.tti.com)
[2] Bob Stout (Bob.Stout@p6.f506.n106.z1.fidonet.org)
[3] Mark W. Schumann (catfood@ncoast.org)
[4] Dion Hollenbeck (uunet!megatek!hollen)
[5] Gary Bastin (gbastin@x102c.harris-atd.com)
[6] Ken Hoover (consp21@bingsuns.pod.binghamton.edu)
[7] Ron House (s64421@zeus.irc.usq.oz.au)
[8] Alvin E. Sylvain (asylvain@felix.UUCP)
[9] Anders Thulin (ath@prosys.se)
[10] Ted Nolan (ted@usasoc.soc.mil)
[11] Bob Alpert (alpert@chovax.dec.com)


===============================================================================
Topspeed C
===============================================================================
Materials:
        11 disks and 4 manuals.


Compiler:
        Claims to be ANSI-compliant.


      "Although the compiler seems good, it's difficult to say whether it's all
        that much better than Turbo C." [1]


      "The compiler is somewhere between MSC and Turbo C in speed, but TSC
        comes very close and in some cases better than MSC in optimization.
        Few compilers can claim the same." [2]


Library functions:
      "A very good imitation of MSC and Turbo C libraries." [4]


      "Libraries does not seem to be as compatible as one could wish." [5]


Manuals:
        Includes User's manual, ANSI C language reference, C tutorial,
        Library reference manual.


      "The documentation isn't bad but isn't great either." [3]


Integrated Environment:
      "It's very difficult to work OUTSIDE of their integrated development
        environment. It's also difficult NOT to use their "smart" make.
        These two things drive me nuts." [1]


      "Their built-in project management (make facility) is OK, but I'd
        prefer to use NDMAKE and BRIEF for my development and then just
        compile with TSC. Unfortunately, their project management makes
        this somewhat complicated." [2]


      "I'll have to agree with Joaquim's impression of the integrated
        environment. It's not bad but not as smooth [as Turbo C's].
        Also, it [has no mouse support]. Another interface quirk is that
        the Debugger interface is different from the interface to the
        rest of the environment. Overall, the environment is not bad
        and one I can learn to live with." [3]


Compatibility:
      "Even though they're mostly compatible with the Big Two, my current
        third-party libraries don't work with it. Currently, TopSpeed doesn't have
        enough market share to make it worthwile for most third party vendors to
        spend time & money converting to TopSpeed." [1]


      "The biggest problem with TSC as I see it is caused by brain-dead
        third-party library developers. TSC has a third calling convention,
        [which] causes problems with [third-party] libraries." [2]


Utilities:
        "Tech kit" includes:
                post mortem debugger
                library source code
                additional libraries (Windows, BGI, multi-threading, mouse)
              "watch" program (tracks INT 0x21 calls),
                assembler (not MASM or TASM compatible).


Support:
      "They sent out a new version (1.03) to me two weeks ago (11 disk in total)
        completely free and without my even asking for it." [3]


General comments:
      "Basically, seems pretty solid with decent speed and code generation. ...
        In short, if you've been using Microsoft C, you'll be impressed by the
        speed. If you've been using Turbo C, you probably won't see a speed
        difference. If you've never used either, you'll think it's a good
        product (if you like their environment). Beware the third party library
        situation, though..." [1]


      "All in all, TSC is a strong package and I would recommend it to
        anyone who's looking for a possible new compiler." [2]


      "Overall I'm happy with TSC." [3]


Contributors:


[1] Patrick McCarthy (mccarthy@well.sf.ca.us)
[2] Joaquim Homrighausen (mulga!csource!jhom, jhom@csource.oz.au)
[3] Eric Lau (lau@cs.ubc.ca)
[4] Ron House (s64421@zeus.irc.usq.oz.au)
[5] Peter Lundberg (peter@cs.umu.se)


===============================================================================
WATCOM C 8.0
===============================================================================


Compiler:
        Protected-mode (386) version of the compiler is also available.


      "It's gotten rave reviews, and they have a good reputation
        for super-optimizing compilers in the mainframe world." [1]


      "I have heard that (for 32 bit '386 compilers) Watcom is a bit
        better than Metaware's. " [2]


      "The optimizer is as good as Microsoft 6.0 (only it generates working
        code, as opposed to MS 6.0); as well, the compiler runs faster." [3]




Integrated environment:
        Included; no information avialable.


Linker:
        Fast. Will someday support VROOMM technology (whatever that is).


Debugger:
      "The debugger is excellent, a far superior product to (gag) CodeView.
        You can even debug 386-protect mode programs with it." [3]


Utilities:
        Profiler.


General comments:
      "I've used a number of different development platforms, and the WATCOM one
        is by far the best." [3]


[1] Jeff Pipkins (pipkins@qmsseq.imagen.com)
[2] Tim Anderson (uw-beaver!sumax!amc-gw!thebes!polari!tima)
[3] Craig Eisler (cgeisler@maytag.waterloo.edu)


===============================================================================
METAWARE
===============================================================================
General comments:
      "Metaware has started shipping religious literature with their C compiler.
        While I may or may not have qualms with their religion, I find this to
        be incredibly unprofessional, leading me to question the company as a
        whole..." [1]


[1] Tim Anderson (uw-beaver!sumax!amc-gw!thebes!polari!tima)


===============================================================================
Zortech C and C++
===============================================================================


Author: Walter Bright (bright@Data-IO.COM)


Cost:
        Developer's Edition = $400
                includes debugger, library source, C++ compiler, C++ class library, etc.


        Zortech has a policy of giving educational discounts to people with '.edu'
        addresses. No hassles with 'qualifying' for the discount. Educational
        prices: Compiler = $75, Developer's Edition = $200


Compiler:
        Supports pointers to expanded memory. (See Dr. Dobb's Journal, May 1990)


        Supports Windows, OS/2 (extra option), Rational Systems DOS extender,
        Virtual Code Management.


      "A pretty good compiler that you should seriously investigate." [1]


      "A faster compiler that generates faster and smaller code, 800 x 600
        super VGA graphics support, email bug reporting, etc, etc." [2]


      "From what I've heard/read/etc. Zortech C++ is the BEST C++ package." [3]


Support:
        The author reads the net and answers questions on Zortech's BBS.


Mailing list:


        send email to ztc-list-request@uunet.uu.net with:
                                        Add: your-user-name@your-machine-name
        In the body of the message.


        Send Zortech bug reports to zortech-bugs@proto.com




[1] Bob Nathan (bnathan@ncratl.Atlanta.NCR.COM)
[2] Joe Huffman (joe@proto.COM)
[3] Jim Dunn (nol2321@dsacg4.dsac.dla.mil)


===============================================================================
Turbo C 2.0
===============================================================================


Materials:
        6 360K disks and 2 manuals.


Compiler:
        Faster than MSC, thought doesn't optimize as well as MSC.
        No Windows or OS/2 support.


      "TC is FAST! It generates reasonable code." [6]


Integrated Environment:
      "The integrated development environment is `cute' but not terribly
        functional for big projects." [6]


      "not bad" [7]


Bugs:
      "There are several well known bugs in the compiler and/or library routines,
        but for the most part they can worked around easily without looking
        kludgy." [6]


Library functions:
      "Borland's BGI system is miles ahead of the crude MSC library." [2]


      "TurboC has several functions that QuickC doesn't, basically aimed toward
        home programming. (For example, there is no QuickC function to control
        the speaker.)" [3]


Debugger: Integrated Debugger (IDE) comes with the compiler;
                      standalone debugger (TD) costs extra.


      "TD has saved me countless hours on single projects alone." [1]


      "Quick C and Turbo C's integrated debuggers are toys.
        [TD] makes CodeView look like DEBUG. For small and/or simple programs,
        the IDE is quite enough. The ability to follow a linked list and the
        flexibility of TD's breakpoints are quite useful." [2]


      "[TD] is the best debugger I have ever used on any system." [4]


      "[IDE] is very good - within its range of capabilities.
        I find that I can find most typos and simple logic errors...
        When you try to trace/debug the interaction of your program with the
        environment, I find myself wanting a little more information, ...
        and this is where [TD] shines." [5]


Support:
      "On the rare occasion I have had to talk to Borland they were both
        pleasant and helpful." [6]


General comments:
        Lack of support for Windows and Oracle may or may not be an issue.


      "If you do go the Turbo-C route, I'd strongly suggest you purchase Turbo-C
        Professional, just for the sake of the debugger alone." [1]


      "TurboC for the home, QuickC for work - business or system programming." [3]


      "The best C compiler for the money is Turbo C++." [7]


      "For anything [other than Windows programming], TC2.0 is just fine." [8]


[1] Kevin Trojanowski (troj@umaxc.weeg.uiowa.edu)
[2] Daniel R. Kuespert (dank@eng.umd.edu)
[3] Micha Berger (mberger1%tasha@graf.poly.edu)
[4] Steve Resnick (stever@Octopus.COM)
[5] John Weeks (uunet!ssbell!weeks)
[6] Steve Resnick (steve.resnick@f105.n143.z1@FIDONET.ORG)
[7] Russ Poffenberger (poffen@sj.ate.slb.com)
[8] John Grogan (jagrogan@vax1.tcd.ie)


===============================================================================
Microsoft Quick C
===============================================================================


Compiler:
        Fully compatible with MSC.


Library functions:
      "QuickC has features, more geared toward professional programmers.
        (For example there is not only a graphics library, but a second,
        business graphics library.) It also have special niceties for system
        programmers. It allows you to declare a function to be a driver for
        a given interrupt, the debugger and integrated system are for both C
        and MASM, the inline code is full MASM." [1]


[1] Micha Berger (mberger1%tasha@graf.poly.edu)


===============================================================================
Microsoft C 6.0
===============================================================================


Compiler:
      Supports Windows and OS/2.


      "Does even better optimization than MSC 5.x, and that's saying a lot." [1]


      "For fast code and really good optimization, MSC is the way to go. Unless
        you're doing really loop-intensive types of code, though, it may not
        be worth coping with [MSC]." [2]


      "MSC 6.0 is awful. For example, three people tried to install the system
        and all three had different problems. Moreover it is slow, cumbersome,
        poorly documented etc. Give me Turbo C any day." [3]


      "As far as speed of the resultant program is concerned, MSC 6.0 has
        Watcom on the run. It's impressive. ... The compiler generates re-entrant
        code (i.e. code that will run in protected mode). Being able to port code
        from MS-DOS to OS/2 or WinNext with a minimum of hassle seems, to me at
        least, to be a _big_ plus." [5]


      "MSC is more powerful [than TC]. It's not some spot features, it's the
        overall functionality. Also, it allows development for MS Windows
        and OS/2. Optimization is better. This costs its price: much more
        used disk space and it is slow." [6]


Manuals:
      "MSC has comprehensive documentation." [1]


Integrated Environment:
      "The Browser is something like a fancy interactive cross-referencer,
        which uses the information built by the compiler." [1]


Debugger:
        Codeview can use extended memory.


      "CodeView is simply lame." [4]


Support:
      "If you want GOOD support from Microsoft, you gotta pay for it." [4]


General comments:
      Compiler supports Windows, OS/2, Oracle.


      "You can't go wrong either way, but I prefer MSC [over TC]." [1]


      "A robust compiler ... but the support tools provided with it are
        brain-dead. 6.0 runs a great deal faster than 5.1, but
        this is still fairly slow in comparison to TC." [4]


      "If you plan to use OS/2 in the future, it is probably better
        to get MSC now." [6]


      "DON'T get Microsoft 6.0 unless you have a VERY SOUPED UP MACHINE!!!
        You can get ANSI compatibility and integrated environment with Quick C." [7]


[1] Tom Haapanen (tom@mims-iris.waterloo.edu)
[2] Daniel R. Kuespert (dank@eng.umd.edu)
[3] David Caswell (dbc%bushido.uucp@umich.edu)
[4] Steve Resnick (steve.resnick@f105.n143.z1@FIDONET.ORG)
[5] Rick Schaut (schaut@garfield.cs.wisc.edu)
[6] Kai Uwe Rommel (rommel@lan.informatik.tu-muenchen.dbp.de)
[7] Jim Dunn (nol2321@dsacg4.dsac.dla.mil)


===============================================================================
Lattice C
===============================================================================


General comments:
      "Lattice was a relief. I never want to go back [to TC or MSC].
        Lattice's function libraries are far more comprehensive than
        either MSC's or TC's (especially in the graphics), the manuals
        are superb, and so is the optimizing and code generation.
        So is the technical support. ... Or so WAS the technical support.
        Lattice will continue to correct problems as they crop up, but they
        said they will not give the compiler any more capabilities." [1]


[1] Alex Matulich (alex@bilver.UUCP)


-------------------------------------------------------------------------------
Date: Sun, 14 Jul 91 17:28:20 cdt
Reply-To: Albert Crosby <acrosby@uafhp.uark.edu>


This suggestion is not for a PD or shareware compiler, but for one that works
quite nicely and costs very little:


Consider ordering PowerC from MIX Software. It is an ANSI compiler with a
library duplicating most of the functions in Microsoft C and Turbo C as well
as ANSI. It does everything you ask for except C++.


They have an 800 number that you should be able to get from 1-800-555-1212.


The cost is $19.95 + $5.00 s&h. You can also buy the library source code and
a nice debugger from them.


Here's there mailing address:


MIX Software
1132 Commerce Drive
Richardson, TX 75081
Phone: (214) 783-6001


Albert


[I'm not associated with MIX Software, just a satisfied customer.]
-------------------------------------------------------------------------------
          = Vincent Shuta
          = University of Scranton
          = VJS4@jaguar.uofs.edu
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.