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 " 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.