Microsoft C Compiler Version 3.00
Release Notes
This document contains information related to Version 3.00 of the
Microsoft C compiler and libraries for MS-DOS. This document
contains information which is more up-to-date than the printed
manuals. As a result, where information in the manuals conflicts
with information in this document, this document should be
assumed to contain the correct information.
The drivers contain two new features which are not documented in
the manuals:
1. the addition of /help and /HELP options to both the CL and
MSC drivers. If this option is specified, a list of the
most commonly used options, together with a short
description of their effect, is printed on the screen. The
options are grouped together by general function, with
headers to identify each group. Note that not all of the
available options are given, only the most common ones. See
appendices B and C of the Users Guide for a more complete
list of the options available for MSC and CL.
Following the list will be a line which says
"type any character to continue"
if you are using MSC, or
"type any character to exit"
if you are using CL. When using CL, after a character is
typed, the driver returns to the DOS command level. Other
inputs on the command line are ignored. When using MSC
however, the driver will process all information on the line
containing the /help (either the command line or a response
line for one of the prompts), and re-issue the current
prompt for further input if needed. Note that any input
given up to this point has been processed so, for example,
if you had typed a filename followed by the /help option,
that filename will show up as the default value when the
prompt is re-issued. The only exception to these rules is
for source file names. If the source file name was given
together with the /help option, the source file prompt is
NOT re-issued, but instead the object file prompt will be
the next one given after the help menu is listed.
2. in the CL driver only, typing "CL <ret>" will cause CL to
print a usage prompt indicating the general form of the
input to CL.
There are three undocumented object files on your diskettes.
They are SVARSTCK.OBJ, MVARSTCK.OBJ, and LVARSTCK.OBJ. These are
the small, medium, and large model versions of a routine which,
when linked into your program, will allow the memory allocation
functions (malloc, calloc, and realloc) to allocate items in
unused stack space if they run out of other memory.
Normally programs compiled and linked under Microsoft C run with
a fixed stack size (default size is 2048 bytes). The stack
resides above static data and the heap uses whatever space is
left above the stack. However, for some programs a fixed stack
model may not be ideal, and a model where the stack and the heap
compete for space is more appopriate. Linking with the
xVARSTCK.OBJ routine (where x is appropriate for the memory model
you choose) gives you a similar environment. The heap can grow
until it runs out of memory, then it will try to use unused stack
space. If it runs into the top of the stack, it fails. The
stack, however, cannot grow to an unlimited size, but only to the
size it was given at link time.
There is another undocumented file on your diskettes and that is
sieve.c. This is a version of the standard Sieve of Eratosthenes
benchmark program. We invite you to compile this program with
Microsoft C Version 3.00 and compare the size and speed of the
generated program with the executable program generated by any
other C compiler for MS-DOS. We think you will be pleased with
the results.
There have been several recent changes to the behavior and
capabilities of the EXEMOD and EXEPACK programs provided on this
release which are not covered in the printed manuals.
EXEPACK attempts to prevent you from compressing a file onto
itself. It is not infallible - it can be fooled by a statement
of the form:
EXEPACK TEST.EXE .\TEST.EXE
If it detects an attempt to compress a file onto itself it will
issue the message:
"exepack: cannot pack file onto itself"
and exit with return code 1. Also, when using EXEPACK to
compress an .EXE file with overlays, the compressed file should
be renamed back to the original name of the linked file to avoid
the overlay manager prompt (see Overlays in the User Guide).
EXEMOD has an undocumented switch, /h, which can be seen in the
usage prompt (it is not shown in the Users Guide description of
the usage prompt). This option CANNOT be used with any of the
other options, and it is equivalent to typing:
EXEMOD PROG.EXE
That is, it simply displays the header fields of the .EXE file
without modifying them.
EXEMOD has also been modified to work correctly on packed (via
EXEPACK) files. When it recognizes a packed file, it will print
the message:
"exemod: (warning) packed file"
If the stack value is changed, it modifies the value that SP will
have AFTER expansion. If either min or stack is set, min will be
corrected as necessary to accomodate unpacking or stack. Setting
max operates as it would for unpacked files.
If the header of a packed file is displayed, the CS:IP and SS:SP
values are displayed as they will be after expansion, which is
not the same as the actual values in the header.
The compiler executable files (CL, MSC, P0, P1, P2, and P3) are
not packed on the distribution diskettes. We recommend that when
you set up your own diskettes (as recommended in the manual or
otherwise), you run EXEPACK on all the compiler executable files.
The savings is not great on most of them, but it is about 11K for
P2.EXE!
If your machine has an 8087 or an 80287, you should read this
closely to see if this pertains to your hardware configuration.
All Microsoft languages which support the 8087 need to intercept
8087 exceptions in order to correct bugs with the chip to produce
accurate results and properly detect error conditions. Most
other languages vendors do not bother to correct or even detect
these errors. The math libraries which contain the 8087
exception handler and emulator (EM.LIB and 87.LIB) are designed
to work without modification with the following machines:
IBM PC family and compatibles, Wang PC, AT&T 6300
(any machine which uses NMI for 8087 exceptions)
Texas Instruments Professional Computer
There is a source file EMOEM.ASM included with the release that
can be modified. Any machine which sends the 8087 exception to
an 8259 Priority Interrupt Controller (master or master/slave)
should be easily supported by a simple table change to the
EMOEM.ASM module. In the file there are further instructions on
how to modify the file and patch libraries and executables.
There are several issues which have caused some confusion to
users which are not covered in the documentation. We will try to
cover some of those here in order to (hopefully) save some time
and frustration later on.
1. When using the stat.h, utime.h, or timeb.h include files
(all found in the SYS subdirectory), remember that types.h
(also in SYS) must being included PRIOR to any of the three
include files above.
2. When passing standard device names, (e.g. CON or LPT1) to
any of C runtime routines which handle device names (creat,
open, sopen, fopen, freopen, or stat), trailing colons in
the names (e.g. CON: or LPT1:) are NOT supported.
3. Non-standard MS-DOS/PC-DOS environments (such as some
commonly used networks) often intercept some/all DOS system
calls and handle them themselves to provide some
additional/different capabilities. When running the
compiler under such environments, this different operation
of the system calls may cause some functions to differ from
their documented behaviour. For example, compiler temporary
files may not always removed when you use ^C or ^BREAK to
terminate a compilation. Changes in the way the PATH is
handled, may cause open, for example, to find (or fail to
find) a given file name where it would fail (or succeed) on
a standard DOS environment.
4. In order for some of the buffered file IO routines,
primarily fseek and ftell, to operate reasonably on TEXT
mode files (where carriage return-linefeed (CRLF) pairs are
translated to linefeed (LF) only on input and LF is
translated to CRLF on output), an assumption is made that
TEXT files DO NOT contain stand-alone LF characters (0x0A in
the ASCII table). If you have files which contain only LF
characters as line separators you should either process them
in BINARY mode, or you must write a filter which can read
the file in BINARY mode, and write it back out in TEXT mode,
which will expand the LF's to CRLF pairs on output. The
resulting file can then be processed as a TEXT file. If you
do not use fseek/ftell, this restriction is not required.
5. If you use the system() library function to invoke a new
COMMAND.COM and do a DOS SET command, a new environment
variable ";C_FILE_INFO" has been created to pass open file
information to child programs.
6. The FP_SEG and FP_OFF macros in DOS.H have been modified so
that they can be used to get or set the segment and offset
portions of a far pointer.
When reporting problems with the compiler we ask that you please
provide the following information to help us in tracking down the
problem:
- the compiler version number (from the logo that is printed
out when you invoke the compiler via CL or MSC)
- the version of DOS you are running (use the DOS VER command)
- your system configuration (what machine, total memory, total
free memory at compiler execution time, etc.)
- the command line used in the compilation
- a preprocessed listing of the program (produced via any of
the -E, -P, or -EP switches), or if the problem appears to
be in the preprocessor, the C source(s) and ALL include
files referenced
- all objects/libraries (except standard ones, but please
state which standard objects/libraries you are using) needed
to link, if necessary
Having that information will be of immense help to us in solving
your problem quickly.
