Click above to get retro games delivered to your door ever month!

The following are some examples of using Watcom C/C++ to compile C/C++
source programs.

Example:

     C>compiler_name report /d1 /s

The compiler processes REPORT.C(PP) producing an object file which contains
source line number information.  Stack overflow checking is omitted from the
object code.

Example:

     C>compiler_name /mm /fpc calc

The compiler compiles CALC.C(PP) for the Intel "medium" memory model and
generates calls to floating-point library emulation routines for all
floating-point operations.  Memory models are described in the chapter
entitled 16-bit Memory Models.

Example:

     C>compiler_name kwikdraw /2 /fpi87 /oaxt

The compiler processes KWIKDRAW.C(PP) producing 16-bit object code for an
Intel 286 system equipped with an Intel 287 numeric data processor (or any
upward compatible 386/387, 486DX, or Pentium system).  While the choice of
these options narrows the number of microcomputer systems where this code
will execute, the resulting code will be highly optimized for this type of
system.

Example:

     C>compiler_name /mf /3s calc

The compiler compiles CALC.C(PP) for the Intel 32-bit "flat" memory model.
 The compiler will generate 386 instructions based on 386 instruction
timings using the stack-based argument passing convention.  The resulting
code will be optimized for Intel 386 systems.  Memory models are described
in the chapter entitled 32-bit Memory Models.  Argument passing conventions
are described in the chapter entitled
32-bit Assembly Language Considerations.

Example:

     C>compiler_name kwikdraw /4r /fpi87 /oaimxt

The compiler processes KWIKDRAW.C(PP) producing 32-bit object code for an
Intel 386-compatible system equipped with a 387 numeric data processor.  The
compiler will generate 386 instructions based on 486 instruction timings
using the register-based argument passing convention.  The resulting code
will be highly optimized for Intel 486 systems.

Example:

     C>compiler_name ..\source\modabs /d2

The compiler processes ..\SOURCE\MODABS.C(PP) (a file in a directory which
is adjacent to the current one).  The object file is placed in the current
directory.  Included with the object code and data is information on local
symbols and data types.  The code generated is straight-forward, unoptimized
code which can be readily debugged with the Watcom Debugger.

Example:

     C>set compiler_name=/i#\includes /mc
     C>compiler_name \cprogs\grep.tst /fi=iomods.c

The compiler processes the program contained in the file \CPROGS\GREP.TST.
 The file IOMODS.C is included as if it formed part of the source input
stream.  The include search path and memory model options are defaults each
time the compiler is invoked.  The memory model option could be overridden
on the command line.  After looking for an "include" file in the current
directory, the compiler will search each directory listed in the "i" path.
 See the section entitled Watcom C/C++ #include File Processing for more
information.

Example:

     C>compiler_name grep /fo=..\obj\

The compiler processes the program contained in the file GREP.C(PP) which is
located in the current directory.  The object file is placed in the
directory ..\OBJ under the name GREP.OBJ.

Example:

     C>compiler_name /dDBG=1 grep /fo=..\obj\.dbo

The compiler processes the program contained in the file GREP.C(PP) which is
located in the current directory.  The macro "DBG" is defined so that
conditional debugging statements that have been placed in the source are
compiled.  The object file is placed in the directory ..\OBJ and its
filename extension will be ".dbo" (instead of ".obj").  Selection of a
different filename extension permits easy identification of object files
that have been compiled with debugging statements.

Example:

     C>compiler_name /g=GKS /s \gks\gopks

The compiler generates code for GOPKS.C(PP) and places it into the "GKS"
group.  If the "g" option had not been specified, the code would not have
been placed in any group.  Assume that this file contains the definition of
the routine gopengks as follows:


     void far gopengks( int workstation, long int h )
     {
         .
         .
         .
     }

For a small code model, the routine gopengks must be defined in this file as
far since it is placed in another group.  The "s" option is also specified
to prevent a run-time call to the stack overflow check routine which will be
placed in a different code segment at link time.  The gopengks routine must
be prototyped by C routines in other groups as


     void far gopengks( int workstation, long int h );

since it will appear in a different code segment.