www.pudn.com > bc31.rar > README


          Welcome to Borland C++ & Application Frameworks 3.1 
          --------------------------------------------------- 
 
  This README file contains important information about Borland C++. 
  For the latest information about Borland C++ and its accompanying 
  programs and manuals, read this file in its entirety. 
 
TABLE OF CONTENTS 
----------------- 
1.  How to Get Help 
2.  Installation 
3.  Features 
4.  Important Information 
5.  Testing Your Expanded Memory 
6.  Corrections to the Documents 
 
 
 1. HOW TO GET HELP 
------------------- 
  If you have any problems, please read this file, the 
  HELPME!.DOC and other files in your DOC subdirectory, and the 
  Borland C++ manuals first. If you still have a question and 
  need assistance, help is available from the following sources: 
 
  1. Type 
 
        GO BCPPDOS     - for questions pertaining to DOS 
 
         or 
 
        GO BCPPWIN     - for questions pertaining to Windows 
 
     on the CompuServe bulletin board system for 
     instant access to the Borland forums with their libraries of 
     technical information and answers to common questions. 
 
     If you are not a member of CompuServe, see the enclosed 
     special offer, and write for full details on how to receive 
     a free IntroPak containing a $15 credit toward your first 
     month's on-line charges. 
 
  2. Check with your local software dealer or users' group. 
 
  3. Borland's TECHFAX service. Call (800) 822-4269 for a FAX  
     catalog of entries. 
 
  4. If you have an urgent problem that cannot wait and you have 
     sent in the license agreement that came with the package, 
     you may call the Borland Technical Support Department at 
     (408) 461-9133. Please have the following information ready 
     before calling: 
 
     a. Product name and serial number on your original 
        distribution disk.  Please have your serial number ready 
        or we will be unable to process your call. 
 
     b. Product version number. The version number for Borland 
        C++ can be displayed by pressing Alt-H/A in the IDE. 
 
     c. Computer brand, model, and the brands and model numbers of 
        any additional hardware. 
 
     d. Operating system and version number. (The version number 
        can be determined by typing VER at the DOS prompt.) 
 
     e. Contents of your AUTOEXEC.BAT file. 
 
     f. Contents of your CONFIG.SYS file. 
 
 2. INSTALLATION 
---------------- 
 
  You MUST use the INSTALL program to install Borland C++. The 
  files on the distribution disks are all archived and have to be 
  properly assembled.  You cannot do this by hand! 
 
  Installing to the same directory structure as a previous version 
  without erasing the directories is not recommended; you may 
  encounter problems due to old header files, libraries, memory 
  managers, or configuration files. 
 
  To start the installation, change your current drive to the one 
  that has the install program on it and type INSTALL.  You will 
  be given instructions in a box at the bottom of the screen for 
  each prompt. For example, if you will be installing from drive 
  A:, type: 
 
    A: 
    INSTALL 
 
  -  This INSTALL handles the installation of both the compiler 
     and debugger and tools in one operation, and allows several 
     new configuration options. 
 
  -  Note: The list of files is contained in a separate file 
     called FILELIST.DOC, which will appear in the target 
     directory you specify during installation. 
 
  -  After installation, make sure you insert \BORLANDC\BIN - or 
     whatever you selected as your BIN directory - into 
     your DOS path so the DLL and executable files can be found. 
 
  -  If you have previously installed Resource Workshop, make sure 
     that you remove the directory of that version from your path. The 
     version included on these disks supercedes previous versions. 
 
  -  If you use a Windows command shell other than Program Manager, 
     you may not get a Borland C++ group installed for Windows. If 
     you don't, use File|Run in Program Manager to run the following 
     command: 
 
          GROUPS GROUPS.B$$ 
 
     You will then have a new group for Borland C++. 
 
  -  After your initial installation, you can run INSTALL again to 
     add elements you omitted the first time. Select only the 
     things you want to add in the INSTALL options screen. Because 
     some things you may want to save could be overwritten, review 
     the following items to make sure you don't lose important 
     information: 
 
     1.  Selecting CMD (the Command-line compiler) causes an  
         overwrite of any existing TURBOC.CFG & TLINK.CFG file 
         with path information provided in that INSTALL session. 
         Any switches that you have added will not be preserved. 
 
     2.  By selecting any one of the following, the help file 
         paths and choices for THELP.CFG will reflect the current 
         session's installation choices:  
          
              a. CMD - command-line compiler  
              b. IDE - integrated environment 
              c. TD - Turbo Debugger 
              d. TASM - Turbo Assembler  
              e. TV - Turbo Vision 
              f. OWL - ObjectWindows library 
 
     3.  If you have made any alterations to headers or startup files 
         they will be overwritten if any library models are selected. 
 
     4.  Selecting the Create BorlandC++ Group option will add a 
         group to the desktop and insert the appropriate icons 
         into that group if this is a first time installation. If 
         this is a re-installation this option will insert the 
         appropriate icons into the existing group. 
 
     In general, any selection you make of something installed 
     earlier will cause an overwrite of the earlier version 
     without prompting. 
 
     An attempt to install to a network directory for which you 
     don't have delete rights will fail with the message "Invalid 
     directory." Make sure delete rights are secured before 
     attempting an installation to a network. 
 
  You should read the rest of this README file to get further 
  information about this release before you do the installation. 
  See also the files in the DOC subdirectory after installation 
  for general information not included in the manuals. 
 
 
 3. NEW FEATURES 
---------------- 
 
  - Borland C++ for Windows: A Windows-hosted IDE which produces 
    Optimized code. The same Optimization options available in BC.EXE  
    are in BCW.EXE. 
 
  - Color syntax highlighting: All IDEs now highlight your source 
    according to syntax. See the choices under Options|Environment| 
    Colors|Edit Window in the DOS IDE and Options|Environment| 
    Highlight in the Windows IDEs. This option is enabled by 
    Options|Environment|Editor|Syntax Highlighting. 
 
  - 386 code generation: An option has been added to produce 386 
    instructions in the generated code. Use -3 at the command line, 
    or Options|Compiler|Advanced Code Generation|80386 in the IDEs. 
 
  - The Object Data calling convention for improved efficiency of C++ 
    code. See the User's Guide chapter, "The Command-line Compiler", 
    under the option -po for more information. This option is also 
    available under Options|Compiler|Optimizations|Object data calling 
    in the IDE. 
 
  - Windows 3.1 support: All executables and DLLs have been modified 
    appropriately for compatibility with Version 3.1 of Windows. 
    The ObjectWindows Library header files have been modified for 
    compatibility with the new Windows header files as well. 
 
    NOTE CONCERNING USE OF MICROSOFT WINDOWS 3.1 REDISTRIBUTABLES FOR 
    APPLICATIONS RUNNING ON MICROSOFT WINDOWS 3.0 
 
    This Borland language product contains everything you need to develop 
    applications to run on the most recent version of Microsoft Windows, 
    version 3.1.  In some cases, you may need to copy and include in your 
    application one or more Microsoft "redistributable" files from a copy 
    of version 3.1 so that your application will also run on version 3.0. 
    Microsoft informs us that you may copy the redistributable files from 
    from Microsoft Windows 3.1 for this purpose.  If you do so, you must 
    comply with the conditions stated in the Borland No-Nonsense License 
    Statement included in this package as if the redistributable files you 
    copy were a part of this Borland language product.  Microsoft's 
    redistributable files in Windows 3.1 are: 
 
       winhelp.exe, winhelp.hlp, commdlg.dll, ddeml.dll, toolhelp.dll, 
       vtd.386, olecli.dll, olesvr.dll, ver.dll, lzexpand.dll, 
       expand.exe, regload.exe, stress.dll, dib.drv, markmidi.exe, 
       penwin.dll, and shell.dll. 
 
    If you do not find any of these files in the BIN directory, they 
    are also included in the Windows retail distribution, and installed 
    in your Windows directories. 
 
  - WinSpector, a postmortem Windows debugging tool that traps 
    general protection faults and provides information on where  
    the fault occurred and the state of the machine at the time. 
 
  - You can now increase the number of files that can be open 
    at one time in a DOS program by a simple modification of the 
    runtime library. 
 
    First, modify _NFILE.H in your INCLUDE directory by changing 
    the #define for _NFILE_: 
 
       #define _NFILE_ n 
 
    where n is the number of files you want to open. Make sure the 
    FILES statement in your CONFIG.SYS file specifies at least 
    this number. 
 
    Then compile the two files FILES.C and FILES2.C in the LIB 
    directory: 
 
       BCC -c -m files.c files2.c 
 
    where  is the memory model you're using. 
 
    Then link them directly with the program which opens the files, 
    for instance: 
 
       BCC myfile.c files.obj files2.obj 
 
    If you want the change to apply to all modules, add 
    FILES.OBJ and FILES2.OBJ created above to the libraries 
    you use; from the LIB directory, type: 
 
       TLIB c +-files.obj +-files2.obj 
 
    where  matches what you used for the BCC command 
    above. 
 
 
DPMI 
---- 
 
BC.EXE, BCC.EXE, MAKE.EXE, and TLINK.EXE are now hosted under 
DPMI. These files replace both the files with the same name in 
Borland C++ 2.0 and the BCX.EXE, BCCX.EXE, and TLINKX.EXE files 
in the same product. There is no longer a TKERNEL.EXE file. 
 
Important! 
---------- 
You must have at least 1Mb of extended memory to run these programs. 
 
If you encounter a "machine not in database" message while attempting 
to run the compiler, run the DPMIINST program to add your machine 
configuration to the DPMI server database. 
 
This version includes a resident DPMI host program, DPMIRES.EXE, 
that allows you to preload the server before invoking BC, BCC, or 
any other DPMI-hosted executables. If you want to run such hosted 
EXEs in a Windows Standard Mode DOS window, you should run 
DPMIRES.EXE before loading Windows. To do this, enter the 
following commands at DOS: 
  
  set DPMIMEM=MAXMEM 2000 
  dpmires 
  win /s 
 
If you want to limit the amount of extended memory used by the 
DPMI-hosted executables, an environment variable called DPMIMEM 
can be set to do so. For instance, the command 
 
  set DPMIMEM=MAXMEM 2000 
 
reserves about 2 Mb of memory for DPMIRES. The number after MAXMEM 
can be adjusted, but cannot be lower than 1000. 
 
DPMIRES should not be run before running Windows in Enhanced Mode. 
Windows requires its own DPMI services. 
 
The hosted executables cannot spawn each other when SHARE is loaded. 
For instance, if you run MAKE on a file which in turn calls MAKE 
again, you will get a sharing violation. In this specific case, 
you can call the real mode version, MAKER, within the given makefile, 
and a sharing violation won't occur. 
 
Note to OS/2 users: To run any DPMI-hosted executables, like BC, BCC, 
or TLINK, in a DOS Window, you need to enable DPMI for that window: 
 
   - Click the right mouse button on a DOS window icon in Command 
     Prompts 
 
   - Select Open|Settings|Session|DOS Settings|DPMI_DOS_API and select 
     ENABLED. 
 
Note to EMM386.SYS users: To run DPMI-hosted EXEs, under the EMM386 
included with Windows 3.1, you need to apply a patch to our files 
as follows: 
 
   - Go to the BIN directory 
   - Type the following command: 
 
          patch server.dif dpmi16bi.ovl 
 
You will now be able to run BC, BCC, etc. 
 
 
 4. IMPORTANT INFORMATION 
------------------------- 
 
  - There is now only one version of the DOS IDE, BC.EXE, and 
    of the command-line compiler program, BCC.EXE. Because the 
    BCX and BCCX files are no longer in Borland C++,  you'll need 
    to alter batch or make files that use those names. 
 
  - Borland C++ only supports Protected Mode Windows target 
    files. Make sure to use the /t option when using the Resource 
    Compiler if you want to enforce Protected Mode usage. 
 
  - When using Brief with THELP, make sure to use Brief's -p 
    switch to ensure that the THELP window will be visible. 
 
  - We recommend that you use the following mouse drivers with 
    this product: 
 
       Microsoft Mouse version 7.04 or later; 
       Logitech Mouse version 5.01 or later; 
       Genius Mouse version 9.06 or later. 
 
  - If you use MAKE or the IDE's Project Make to invoke the Resource 
    Compiler, the .RC files you wish to compile MUST be in the same  
    directory as your project or makefile.  This is because the Microsoft 
    Resource Compiler does not properly handle relative path names, and 
    returns a misleading error message that refers to an incorrectly 
    spelled version of your .RC file. 
 
  - If you get a "floating point formats not linked" message at 
    runtime, put the following somewhere in your source files: 
 
        extern void _floatconvert(); 
        #pragma extref _floatconvert 
 
    This will force inclusion of floating point formats, which 
    may not be linked to reduce executable size. 
 
  - Make sure that you use the -WE switch (Options|Compiler|Entry| 
    Windows  explicit functions exported in the IDE) when 
    using the fastcall modifier. The same applies when using the 
    fastcall compilation option (-pr on the command line, 
    Options|Compiler|Entry|Register in the IDE.) Also see the first 
    entry on using fastcall with main() in "COMPILER" below. 
 
  - If the Windows 3.0 home directory precedes the Borland C++ BIN 
    directory in your path, attempting to access Help will result in the 
    message "This version of Help file not supported." To enable 
    Help, either reorder your path or copy WINHELP.EXE to your Windows 
    3.0 directory. 
 
  - This compiler uses more strict checking of C++ syntax and argument 
    matching than previous versions. You can expect more warning 
    and error messages based on the ANSI C++ version 3.0 standard. 
 
  - If you receive a "bad object record" message from the linker when 
    building OWL or container class library applications, you are 
    probably using the Borland C++ version 3.0 class libraries and/or 
    OWL libraries. Make sure your library path specifies version 3.1 
    libraries for those applications. 
 
  COMPILER 
 
  - When using fastcalls (-pr command line option) you are 
    required to explicitly use the C calling convention, "cdecl", 
    for main. For example: 
 
        int cdecl main( ) 
 
    In Borland C++ 3.0 the compiler did not correctly name main when 
    fastcalls were used, with the result that you were not 
    required to cdecl main (in all cases).  This is a dangerous 
    condition and the compiler now (correctly) names main, 
    resulting in a linker error in Borland C++ 3.1 for those Borland C++ 
    3.0 compiled programs that didn't cdecl main. 
 
    Please correct any "non-cdecl main" definitions, if compiled 
    with fastcalls. 
 
  - In Borland C++ 3.0 the compiler allowed conversions from "const void*" 
    to "void *", contrary to ANSI; for Borland C++ 3.1 this is no 
    longer allowed.  In addition, several other conversions 
    regarding const variables have also been restricted.  If you 
    are a user of the const keyword, expect that you may have 
    conversions that were allowed to exist with Borland C++ 3.0 that 
    will need to be changed in order to compile using Borland C++ 3.1. 
 
  - In Borland C++ 3.0 the following syntax was allowed- 
 
            class foo{ 
            ... 
            }       // note that the semicolon is missing here 
 
            f(){ 
            ... 
            } 
 
    The new compiler now requires the semicolon to be added after 
    the class declaration. The compiler would interpret the 
    example above as an attempt to return a class declaration to 
    f(). 
 
  - A new implicit conversion rule is now enforced for constructors. 
 
    From page 573 of The C++ Programming Language 2nd Edition: 
 
 
      "When no constructor for class X accepts the given type, no 
       attempt is made to find other constructors or conversion 
       functions to convert the assigned value into a type acceptable 
       to a constructor for class X." 
 
    For example, 
 
            class X { /* ... */ X(int); }; 
            class Y { /* ... */ Y(X); }; 
            Y a = 1;  // illegal: Y(X(1)) not tried 
 
    Note that this rule only applies to constructors with ONE parameter. 
 
  - The inport/outport functions have been changed to accept an 
    unsigned parameter instead of an int. The new prototypes are: 
 
     unsigned      inport(unsigned) 
     unsigned char inportb(unsigned) 
     void          outport(unsigned, unsigned) 
     void          outportb(unsigned, unsigned char) 
 
  - We have new resource compiler and linker components: 
 
    BRCC is the Borland Resource Compiler. RLINK is the resource  
    linker/binder. BRC.EXE calls BRCC.EXE and RLINK.EXE, and is an  
    equivalent to Microsoft's Windows 3.1 RC. New features that  
    may not be found in other products include: 
 
       - Binding of multiple RES files is supported under RLINK. 
 
       - Resource ID conflicts are detected and resolved during 
         binding. 
 
    For more information, see the file MANUAL.RW located in your 
    \BORLANDC\DOC directory.   
 
  - There is currently support in ObjectWindows for STRICT and 
    non-STRICT versions of OWL programs for Borland C++ versions 
    3.0 and 3.1. Simply define the macros WIN30 or WIN31, and add a 
    definition for STRICT if you need STRICT compliance. For 
    more details see WIN31.DOC in the DOC directory and 
    OWL31.DOC in the OWL\DOC directory. 
 
  - The default extension for source files to the command-line 
    compiler is .CPP; that is, if you enter 
 
       BCC -c test 
 
    the compiler will search for test.cpp, and give an error if a 
    file of that name cannot be found. If you want to have the 
    command-line compiler assume a .c extension and C language 
    source, use the command-line option -P-c. For more 
    information, see "The command-line compiler" in the User's 
    Guide. 
 
  - Note that the Generate COMDEFs choice under 
    Options|Compiler|Code Generation and the -Fc command-line 
    option are only supported in the C language. Linker errors 
    will result if you attempt to use a communal variable in C++. 
 
  - The macros min() and max() are not defined when stdlib.h is 
    compiled as C++ (to allow their use in 3rd party libraries, 
    etc.). 
 
  - Note that files with the extension .SYM can come from at least 
    two different sources: Borland's precompiled headers, and the 
    output of Microsoft's MAPSYM or Borland's TMAPSYM programs,which 
    can also be used by SYMDEB and other debuggers. 
 
    These files do not have compatible formats, so collisions 
    should be avoided by renaming the precompiled header file 
    with -H= on the BCC command line, or as a BCC transfer 
    option in the IDE. 
 
  - There is now full support of distance modifiers (near and 
    far) used for class member pointers. Here are two sample 
    declarations and their meanings: 
 
       void (A::* far var) (); 
 
    this is a far variable 'var' of type 'void (A::*)()'; 
 
       void (far A::* var) (); 
 
    this is a 'default distance' variable 'var' of type 
   'void (far A::*)()' 
 
  - You must use "smart callbacks" - -WS from the command line, 
    Options| Compiler|Entry/Exit Code|Windows smart callbacks in 
    the IDE - if your application uses classes whose code is in a 
    DLL. This applies especially in the case of a class 
    implemented in an EXE which is derived from another 
    implemented in a DLL, which normally applies for users of OWL 
    and other object-oriented class libraries. 
 
  - If you use C++ templates, and use a separate TLINK command 
    line rather than letting BCC invoke TLINK, you should make 
    sure that you turn on case-sensitive links with the /c switch. 
 
 
  IDE 
 
  - When debugging a mouse application the Options|Debugger|Display 
    Swapping option should be set to "Always" for best results. 
 
  - Defines entered under Options|Compiler|Code Generation entered 
    with semicolons don't apply to RC project items. If you need to 
    make multiple definitions for resource compilation in the IDE, 
    enter separate defines in the Project Local Options, for example: 
 
        -dDEF1 -dDEF2=1 
 
  - In the DOS IDE, the mouse cursor is turned off during compilation 
    for performance improvements. 
 
  - If you run File|Printer setup from BCW.EXE (or another Windows 
    application which has printer setup support) under the Windows 
    3.0 debugging kernel, you will get a System Error from Windows. 
    You must switch to the NODEBUG version to run this option. 
 
  - The initial block marking behavior in the IDE is determined 
    by which version of the IDE is used first after installation. 
    Invoking BCW.EXE first will cause Windows-style block marking 
    conventions to be in effect; otherwise the standard DOS IDE 
    behavior will be used. You can change the behavior by 
    selecting Options|Environment| Editor and changing the 
    settings for Persistent blocks and Overwrite blocks. 
 
  - The first time you open certain projects in Borland C++ for 
    Windows (BCW), you will get a dialog indicating that one or 
    more items will be converted. This will occur for all Windows 
    projects existing prior to BC 3.1 and for all DOS projects 
    that you open in BCW.  The purpose of the dialog is to 
    indicate to you that certain changes need to be made to the 
    project to allow it to compile properly for Windows. DOS 
    projects that are opened in BCW will need to be changed to 
    target Windows, and many projects will need to generate 80286 
    code rather than 8088 code.  You have several options 
    regarding saving the changes: 
 
      Don't auto save project 
      Warn before saving project 
      Save project now 
 
    The first option will be the most likely choice for DOS C++ 
    programs that you bring up in BCW in order to browse classes. 
    When you close the project, it won't be saved, so that you don't 
    lose the options you have already set. 
 
    If you select the second option, you will be given the choice of 
    saving the project when you close it. 
 
    The last option saves the project with the new settings 
    immediately.  For your current Windows projects, you will 
    probably want to choose this option so that this dialog will no 
    longer come up for the project. 
 
  - The RC.EXE included in this release targets Windows 3.1. You 
    will need to include the -30 option for RC files in any project 
    intended to run under Windows 3.0. Use Options|Transfer|Resource 
    Compiler|Edit|Command line, and change the entry to: 
 
       -30 $RC 
 
    If you use PRJ2MAK on a project which uses this option, 
    you will need to edit the resulting .MAK file, and move 
    the "-30" option to the RC line which links the .RES 
    file to the .EXE file. For instance, the line output by 
    PRJ2MAK may look like: 
 
            rc filename.res filename.exe 
            .. 
            rc -30  filename.res filename.rc 
 
    Change this to 
 
            rc -30 filename.res filename.exe 
            .. 
            rc   filename.res filename.rc 
 
  Resource Workshop 
 
  - 256-Color bitmaps and RLE4 compression: 
 
    Due to problems with many 256-color display drivers for Windows 
    3.x, saving a bitmap with the RLE4 compression feature of 
    Resource Workshop enabled can fail to produce valid output files. 
 
    Under Windows, the display driver is responsible for providing 
    RLE compression when it is requested. However, because many 
    display drivers do not implement this feature correctly, we 
    recommend that you take the following steps when attempting to 
    use RLE4 compression: 
 
    1. Save the bitmap with the compression option set to "None". 
       This ensures that you will have a usable copy of your bitmap 
       if the remaining steps are not successful. 
 
    2. Set the compression option to "RLE4". 
 
    3. Select Resource|Save Resource As and save the bitmap under a 
       different file name. 
 
    4. Select File|Open Project and load the compressed version of 
       the bitmap. 
 
    If you cannot load the compressed bitmap, you must use the 
    uncompressed bitmap file you saved in step 1. 
 
    If your 256-color driver fails to compress the bitmap correctly, 
    contact the display driver vendor. 
 
 
    Flood-fill with the paint bucket tool 
    ------------------------------------- 
 
    Because of problems inherent to display drivers, flood-filling a 
    section of a bitmap using the paint bucket tool can fail to 
    produce the desired result. 
 
    Resource Workshop provides an alternate version of the flood-fill 
    algorithm that is slower but more reliable than the version 
    provided by most Windows 3.x display drivers. 
 
    You can enable Resource Workshop's flood-fill algorithm by adding 
    a flag called "RWS_OwnFloodFill" to the Icon editor section 
    ([RWS_Icon]) of WORKSHOP.INI. Set the flag to 1. 
 
    The edited section of WORKSHOP.INI should look something like 
    this: 
 
        [RWS_Icon] 
        RWS_OwnFloodFill=1 
        PercentLeft=50 
        ZoomLeft=8 
        ZoomRight=1 
        bVert=1 
 
    Contact the display driver vendor if you experience flood-fill 
    problems. 
 
 
  WinSight 
 
  - WinSight traces messages received by GetMessage or SendMessage. It 
    does not trace messages sent directly by function call such as 
    WM_INITDIALOG. 
 
  - Please note that messages displayed as "dispatched" are actually 
    intercepted at the time of GetMessage, not DispatchMessage. 
 
 
  EXAMPLE PROGRAMS 
 
  - When you are running any example programs that come with .PRJ 
    files, if you didn't use the standard directories when you 
    installed Borland C++ you will have to change the .PRJ file 
    to reflect your actual directory setup.  Do this from inside 
    Borland C++ with Alt-O/D. 
 
  - When run under the Windows 3.1 debug kernel, many OWL examples will 
    cause a message to be displayed like these: 
 
        USER: Invalidation with fErase==FALSE prevents WM_ERASEBKGND 
        Kernel: GlobalCompact(FFFFFFFF), discarding segments 
 
    These messages are valid runtime warnings, but they don't 
    indicate improper implementation; they are supplied for the 
    information of the user or programmer under the debug kernel. 
 
  - To build the help file for the HELPEX example, go to the 
    EXAMPLES\WIN30 directory and type 
 
         hc helpex 
 
 
  LINKING C++ WITH C 
 
  - Linking C++ modules with C modules requires the use of a 
    linkage specification.  Prototypes for C functions within C++ 
    modules must be in one of the following forms: 
 
        extern "C" declaration 
        extern "C" { declarations } 
 
    For example, if a C module contains these functions: 
 
        char *SCopy(char*, char*); 
        void ClearScreen(void) 
 
    they must be declared in a C++ module in one of the 
      following ways: 
 
        extern "C" char *SCopy(char*, char*); 
        extern "C" void ClearScreen(void); 
 
      or 
 
         extern "C" { 
            char *SCopy(char*, char*); 
            void ClearScreen(void); 
         } 
 
    Failure to do so will result in "Undefined symbol" errors 
    during link. For further examples, see the standard header 
    files. 
 
  OPTIMIZATIONS 
 
  - When Ignore Aliasing is used - Options|Compiler|Optimization| 
    Assume no pointer aliasing , or -Oa from the command line - 
    some initializations could be skipped. This applies 
    only when Copy propagation -Op or Options|Compiler|Optimization| 
    Copy propagation is used as well (which is the case when 
    using -O2 or Options|Compiler|Optimization|Fastest Code.) The 
    following case illustrates the issue: 
 
        len = 0; 
        read(help_file, (char *)&len, 1); 
        read(help_file, (char *)title, len); 
 
    The initializion of len to the value 0 above will probably 
    not be reflected in the first call to read() if aliases are 
    ignored. If the initialization of len were guaranteed by the 
    call to read(), the first line would be unnecessary, and the 
    value in len would be assigned and passed to the second read 
    correctly. We recommend that you avoid using these options 
    together when explicit initializations are used in code 
    sequences like these. 
 
 
  TURBO DEBUGGER AND TOOLS 
 
 
  Debugging Multiple Applications under Turbo Debugger for Windows 
  ================================================================ 
     You can debug multiple applications under TDW as follows: 
 
     1. Load the first program to be debugged into TDW. 
 
     2. Once the application is loaded, press the F3 key to 
        display the Load Module Source or DLL Symbols dialog box. 
 
     3. In the DLL Name text entry box, enter the name of the 
        .EXE or  DLL to add. If the .EXE or DLL resides in 
        another directory, you need to provide the full path. 
 
     4. Press the Enter key. TDW adds the program name to the  
        DLLs & Programs list box and puts the !! symbol after it. 
 
     5. Close the Load Module Source or DLL dialog box, return to 
        the Module window, and set any necessary breakpoints in 
        the first program. 
 
     6. Press F9 to run the first program. 
 
     7. Switch to the Windows Program Manager while the first 
        program is running and run the second program in the 
        usual way. 
 
     8. You see the display switch back to TDW with the CPU 
        window showing the start-up information of the second 
        application. Close the CPU window. 
 
     9. In the Module window, set any necessary breakpoints in 
        the second application, then press the F9 key to run it. 
 
     This method is useful for debugging DDE conversations or any 
     other inter-program communication in the Windows 
     environment. 
 
 
  TDW.INI, the Windows initialization file for TDW and TPROFW 
  =========================================================== 
    TDW.INI is located in your local Windows directory. It is the 
    Windows initialization file used by TDW, TPROFW, and WREMOTE. 
    TDW.INI specifies the name and location of the Debugger DLL and 
    the video driver DLL (if any)  in the [TurboDebugger] section. 
    It can also contain two other sections: 
 
    o [VideoOptions], where you put settings for the video DLL, if any 
 
    o [WRemote], where WRSETUP puts settings for remote debugging 
      and profiling 
 
   [TurboDebugger] section 
   ----------------------- 
   WINDEBUG.DLL has been replaced by TDWIN.DLL. TDWIN.DLL can be 
   located anywhere you wish (usually the main Windows directory). 
   The DebuggerDLL entry must specify the full path to TDWIN.DLL. 
   
   For example, if TDWIN.DLL is in the WINDOWS3.1 directory, its 
   TDW.INI entry is 
   
   [TurboDebugger] 
   DebuggerDLL=c:\windows3.1\tdwin.dll 
   
   The VideoDLL entry indicates a video support DLL for 8514 or 
   Super VGA, because TDW doesn't support these video modes by 
   default. This entry must specify the full path to the DLL. You 
   can set various video options for the DLL in the 
   [VideoOptions] section.  See the next section for a complete 
   explanation of video DLL and options settings. 
 
 
  SVGA support, the VideoDLL entry, and the [VideoOptions] section 
  ---------------------------------------------------------------- 
   TDW and TPROFW handle most of the popular 2, 4, 16, and 256-color 
   high-resolution Super VGA modes. If your card isn't supported 
   correctly, you need to use a special Super VGA (SVGA) DLL. 
 
   Currently, six DLLs are supplied with your language compiler to 
   support various SVGA and 8514 video cards and modes. These DLLs are 
   described in the next section. For information on how to specify the 
   Video DLL or its options, see the sections "The VideoDLL entry" and 
   "The [VideoOptions] section," which follow the "Video DLLs" section. 
 
 
     Video DLLs 
     ---------- 
     All the video DLLs described in this section are designed to work 
     with the most current Windows screen drivers for your video card.  If 
     you're not sure if you're using the latest drivers, contact your video 
     card manufacturer for more information. 
 
     From time to time we have new DLLs for new video cards. These DLLs, 
     when available, can be downloaded from Compuserve, BIX, GEnie, and our 
     local BBS (408-439-9096). As new video cards and modes appear on the 
     market, we will be creating new DLLs for them. If the card you use 
     isn't supported by one of our DLLs, please contact Tech Support for 
     the latest video DLL information. Our main Tech Support phone number 
     is 408-461-9133. 
 
 
       ATI.DLL 
       ------- 
       Works with the ATI VGA Wonder and XL cards in certain video modes. 
 
       The latest ATI Drivers from ATI Technologies Inc. require the 
       following TDW.INI file entries: 
 
 
            Resolution   ATI.DLL  Int2FAssist 
          ----------------------------------- 
          | 640X480    | Yes     |   Yes    | 
          ----------------------------------- 
          | 800X600    | Yes     |   Yes    | 
          ----------------------------------- 
          | 1024X768   | No      |    No    | 
          ----------------------------------- 
 
       EXPLANATION: ATI.DLL is required in all video modes except 
       1024 X 768 (this mode is directly supported by TDW and TPROFW). 
       When the DLL is used (VideoDLL=ATI.DLL), Int2FAssist should be 
       set to "yes" in the [VideoOptions] section. 
 
 
       TSENG.DLL 
       --------- 
       Supports TSENG ET-3000 /ET-4000 based cards in certain 
       video modes. 
 
       The latest TSENG drivers are available from the Microsoft 
       Windows Driver Library on CompuServe. They require the 
       following TDW.INI file settings: 
 
 
           Resolution   TSENG.DLL   Int2FAssist 
          ------------------------------------- 
          | 640X480    | Yes       |   Yes    | 
          ------------------------------------- 
          | 800X600    | No        |    No    | 
          ------------------------------------- 
          | 1024X768   | No        |    No    | 
          ------------------------------------- 
 
       EXPLANATION: TSENG.DLL should only be used with 640 X 480 X 256 
       resolution (set VideoDLL=TSENG.DLL and put a "Int2FAssist=Yes" 
       entry in the [VideoOptions] section). TDW and TPROFW directly 
       support the other TSENG resolutions. 
 
 
 
       TDVESA.DLL 
       ---------- 
       Supports any video card that does VESA emulation, whether 
       through a TSR or video card firmware. Use this DLL with 
       all resolution settings. 
 
           NOTE: You can run VESATEST.EXE from either DOS or 
           Windows to see if your system provides the proper 
           VESA functions. If the emulation is not loaded, TDW 
           (or TPROFW) will display an error message indicating that 
           the video DLL isn't supported by the current configuration. 
 
       The TDVESA.DLL has been tested with the following video 
       cards: 
 
         o Video Seven VRAM II--uses V7VESA TSR supplied with card 
 
         o Weitek Power Windows--emulates VESA with firmware. 
 
 
       DUAL8514.DLL 
       ------------- 
       Supports any dual-screen 8514 cards. This DLL is only for 
       systems that have two-color monitors, one attached to the VGA 
       card and one attached to the 8415/A card. It speeds up 
       performance by preventing TDW (or TPROFW) from doing some 
       things that aren't required in dual-monitor mode. 
 
           NOTE: Using this DLL is not the same as invoking TDW 
           with the -do parameter, which only specifies using a 
           monochrome screen. 
 
 
       STB.DLL 
       ------- 
       Supports the MVP2 series of multi-screen video cards. 
 
 
       ULTRA.DLL 
       --------- 
       Supports ATI Graphics cards, 8514 Ultra and Vantage cards 
       (8514/Ultra, 8514/Vantage, Graphics/Ultra, and Graphics/Vantage), 
       and 8514-based cards configured for a single monitor (including 
       most IBM 8514/A cards). If you use this DLL with an IBM 8514/A 
       card, set "ATI=no" in the [VideoOptions] section of TDW.INI. 
 
 
   The VideoDLL entry 
   ------------------ 
   To use an SVGA DLL, simply edit the TDW.INI file that the installation 
   program puts in your main Windows directory. You can modify TDW.INI 
   with any ASCII text editor. Under the section heading [TurboDebugger] 
   there is an option called "VideoDLL". This entry should equal the 
   path and filename of the DLL you want to use for SVGA support (see the 
   example later in this file). 
 
   If there's an error loading the DLL or if the DLL doesn't support 
   the selected card or mode, TDW (or TPROFW) reports the error in a 
   Windows dialog box. When this happens, TDW (or TPROFW) unloads the 
   DLL and exits. If this situation occurs, remove the DLL's name from 
   the VideoDLL line in the TDW.INI file or select a video mode that is 
   supported by that DLL. 
 
 
   The [VideoOptions] section 
   -------------------------- 
   There are options you can set for the current video DLL. You list 
   these options under the [VideoOptions] heading in any order you like. 
 
   The following list shows all the video options: 
 
     o SaveWholeScreen    --    default = no 
     o Int2FAssist        --    default = no 
     o DebugFile          --    default =  
     o IgnoreMode         --    default = no 
     o ATI                --    default = yes 
     o Rows               --    default = 25 
     o RestoreTextScreen  --    default = yes 
 
   DebugFile can be either blank or set to a specific filename. The other 
   four settings must be either "yes" or "no". Rows must be 25 or 50. 
 
 
     SaveWholeScreen   (ATI, TSENG, TDVESA) 
     --------------- 
     This option, normally set to "no", determines whether the entire 
     screen (512k - 64k from 8 planes) is saved (the entire graphics 
     screen is cleared when switching to it) or if only the top 32K of 
     planes 0 through 3 is saved (the entire screen is NOT cleared when 
     switching modes.) 
 
     Saving the whole screen is not usually necessary, but is provided 
     in case you're using a nonstandard card that requires that the whole 
     screen be saved. It also provides support for the Alt-F5 key 
     combination under Int2FAssist mode. 
 
 
     Int2FAssist  (ATI, TSENG) 
     ----------- 
     This option, normally set to "no", tells the DLL to make a special 
     Int 2F call before switching video modes. This call tells the current 
     Windows screen driver what's happening. The desired side-effect of this 
     call is to make Windows tell all its child windows to repaint 
     themselves. This option is provided mainly to support some ATI Wonder 
     and TSENG chip set video modes. 
 
 
     DebugFile   (ALL DLLs) 
     --------- 
     The video DLL normally doesn't log any debugging information. If 
     you're having problems using a particular DLL, you can use the 
     DebugFile option to specify the path and filename of a log file. 
     You can use the information logged to this file if you need to 
     contact Borland's Technical Support. 
 
     The information logged is: 
 
       o the date and time you ran TDW or TPROFW 
       o the version & location of the DLL 
       o the name of the current Windows screen driver 
       o the state of all TDW.INI options 
       o a listing of all calls and parameters to the DLL's functions 
 
 
     IgnoreMode   (ATI, TSENG) 
     ---------- 
     This option only applies when the video DLL is ATI.DLL or TSENG.DLL. 
     It tells the DLL to not do any mode or card checking and to force the 
     Int2FAssist option on. This option is useful for cards that aren't 
     directly supported by an official DLL yet, such as Paradise, Video-7, 
     Trident, or any other video card without a graphics coprocessor. 
     (With this option enabled, the functionality is identical to the 
     temporary ALL.DLL that we offered in the past.) 
 
 
     ATI   (ULTRA) 
     --- 
     This option is only used by ULTRA.DLL and is on by default. If you 
     disable it, you can use ULTRA.DLL on regular IBM 8514/A cards. 
 
 
     ROWS  (ALL DLLs) 
     ---- 
     This option is only used if you use a configuration file to change 
     the number of rows to 43/50 from 25. If you choose to have TDW 
     start in 50-line mode, set the Rows option to 50 in the TDW.INI file. 
 
 
     RestoreTextScreen   (DUAL8514, STB) 
     ----------------- 
     This option is valid only with DUAL8514.DLL and STB.DLL. The 
     settings are: 
 
       o Yes    - restores TDW's (or TPROFW's) screen after exiting. 
       o No     - does not touch TDW's (or TPROFW's) screen at all. 
       o Clear  - forces the screen to clear upon exiting TDW (or TPROFW). 
 
 
   Video DLL example 
   ----------------- 
   If you have an ATI VGA Wonder card and you want it to save 
   the entire screen and log information to a file named 
   C:\WINDOWS\TDVIDEO.LOG, the TDW.INI file will look something 
   like this: 
 
       [TurboDebugger] 
       DebuggerDLL=c:\windows3.1\tdwin.dll 
       VideoDLL=c:\borlandc\bin\ati.dll 
 
       [VideoOptions] 
       SaveWholeScreen=yes 
       DebugFile=c:\windows\tdvideo.log 
 
 
   Technical information 
   --------------------- 
   TDW, upon loading, looks for the video DLL in the following 
   locations in the following order: 
 
     1. The same directory TDW (or TPROFW) is running from 
 
     2. The Windows main directory 
 
     3. The location specified in TDW.INI 
 
 
   If it finds the file, TDW (or TPROFW) accesses the DLL as needed. 
   TDW (or TPROFW) makes calls to the DLL to handle the entire video 
   screen-switching context. The DLL accomplishes the screen switching 
   by allocating a buffer as it gets loaded. Graphics screen contents 
   are then saved to this buffer when TDW (or TPROFW)_enters text mode. 
   The DLL restores the graphics screen from this buffer when TDW 
   (or TPROFW) exits text mode. Memory allocated for the buffer is freed 
   when the DLL is unloaded. 
 
 
   Seeing the user screen of an application 
   ---------------------------------------- 
   Some video modes might require some special handling. The Int2FAssist 
   option allows these modes to work correctly on most systems. The 
   behavior is as follows: 
 
   When you set "Int2FAssist=yes", the DLL notifies Windows to tell 
   all sub-windows on the screen to repaint themselves while the user 
   application is running. This allows the user screen to be viewed 
   when stepping, tracing, or running your application. It will not, 
   however, switch to the user screen when you press the Alt-F5 key 
   combination because TDW is still in control (TDW doesn't allow Windows 
   to process any messages at this point.) 
 
   If you also set "SaveWholeScreen=yes", pressing the Alt-F5 key 
   combination shows the user screen. (The DLL will now copy the screen 
   back for you.) The drawback to enabling SaveWholeScreen is that it 
   will take longer to step or trace if TDW needs to switch back to 
   the user screen for that particular instruction. Also, extra messages 
   will be passed to your application that normally wouldn't be passed. 
   This may affect the debugging of certain pieces of code (like finding 
   a bug in an owner-draw control). In these cases, you won't want to use 
   this option on the current video mode. 
 
 
  Using TDW in Dual Monitor Monochrome Mode 
  ---------------------------------------- 
   If TDW is activated using the -do switch, there is no need for 
   a video DLL or a value in the VideoDLL section of TDW.INI. The 
   value in VideoDLL should be removed as follows: 
 
    [Debugger] 
    VideoDll= 
 
 
   The [WRemote] section 
   --------------------- 
   If you run WRSETUP to configure WREMOTE, the settings are 
   saved in the WRemote section of TDW.INI. In previous versions, 
   these settings were saved in the WRemote section of 
   WREMOTE.INI. If you have a previous version of TDW or TPROFW 
   and want to preserve your WREMOTE settings, you can append the 
   contents of WREMOTE.INI into TDW.INI. Be sure to include the 
   [WRemote] section heading. 
 
   The settings for the [WRemote] section are described in the 
   "Turbo Debugger User's Guide" in Appendix E, "Remote 
   Debugging" starting on page 386. 
 
 
  Known Problems 
  ============== 
 
  - TD386 and TF386 currently do not support machines with over 
    16M of memory.  You must disable any extra memory to use 
    these programs. 
 
  - On page 10 in Chapter 1 of the "Turbo Profiler User's Guide," 
    there is a statement that Pascal versions of the PRIMEn.C 
    programs are included on disk. Only the C versions of these 
    sample programs are included on the distribution disks. 
 
  - Some mouse drivers are incompatible with TD and will 
    cause the mouse cursor to get scrambled when debugging DOS 
    graphics applications on a second monitor (-do option).  If 
    that happens, you can try a different driver or turn off the 
    mouse in TD by using the -p- option on the TD command line. 
    The mouse will still be active in the target application. 
 
  - If you have any lines in your SYSTEM.INI that rename DLLs, such as 
    "sound.dll=mysound.drv", TDW might display the error "Can't find  
    sound.dll" when it loads a program that uses the DLL.  To solve this  
    problem, use the -wd command switch to disable TDW's DLL checking when  
    you load such a program. 
 
  - The first time a program is run under TDW or TPROFW, mouse 
    messages are processed normally. However, on every subsequent 
    execution of that program, you must press a key on the 
    keyboard before mouse messages can be processed. 
 
  - TSENG ET-4000 video chip set and Windows 3.1 problems 
 
    Under Windows 3.1, if you use the standard Windows VGA or 
    SuperVga  driver with a video card that uses the TSENG 
    ET-4000 chip set, you might encounter a number of problems 
    with running TDW on a single monitor. 
 
    o The hardware cursor (the white cursor displayed in all 
      dialog boxes that require text input) is invisible, but 
      you can still debug your program. 
 
    o On certain TSENG 4000-based cards (such as the Diamond 
      Speedstar VGA card), when you launch TDW the default 
      character set is replaced by graphic characters. 
 
   To overcome this problem please contact Microsoft Corp and ask 
   for the updated TSENG drivers that were NOT shipped with 
   Windows 3.1. They are also located in the Microsoft Forum (GO 
   MSOFT) under the Microsoft Software Library heading in 
   CompuServe. 
   
        Filenames      Date 
        ---------      ---- 
 
        TSENG1.EXE     4/6/92 
        TSENG2.EXE     4/6/92 
        TSENG3.EXE     4/6/92 
        TSENG4.EXE     4/6/92 
   
   
   In the meantime, you can use one of the following alternatives: 
   
   - Run Windows Setup and replace your Windows 3.1 VGA or SVGA driver 
     with the Version 3.0 VGA driver supplied with Windows 3.1. 
   
   - Start TDW from the DOS command line. For example, 
   
     WIN TDW myprog 
   
   - Each time you launch Windows, run a full screen DOS session 
     and type "exit" to close it. After you do this, when you run 
     TDW, it will use the correct character set. 
 
 
  CLASS LIBRARY 
 
  - If you used the add(), addAt(), or getItemsInContainer() 
    member functions of the Array class in Borland C++ 2.0 
    applications, note that their behavior has changed slightly. 
    The following rules apply to these and related functions: 
 
      1. add() will insert its argument at the lowest available 
         location in the Array.  This location is known as the 
         "insertion point". 
 
      2. detach() will remove its argument from the Array, and if 
         that Object is located below the insertion point, it 
         will move the elements above the Object being removed 
         and below the insertion point down one position, so that 
         the elements below the insertion point remain 
         contiguous.  The insertion point, of course, moves down 
         one. 
 
      3. if the location specified in a call to addAt() is below 
         or at the insertion point, the elements above the 
         specified location and below the insertion point are 
         moved up one position, and the Object is inserted.  The 
         insertion point moves up one. 
 
      4. if the location specified in a call to addAt() is above 
         the insertion point, the Object is inserted at that 
         location, replacing any Object that may have been placed 
         there previously. 
 
      5. getItemsInContainer() returns the number of elements 
         below the current insertion point.  If you use addAt() 
         to add elements above the insertion point, they will not 
         affect the value returned by getItemsInContainer().  
         This is a change from the behavior in the previous 
         version of the class library. 
 
  - Two versions of the class library sources are provided; one 
    using an implementation using C++ templates, and one not using 
    templates. The small and dynamic link libraries are provided, and 
    a makefile is provided to build other models. 
 
 
  ObjectWindows Library 
 
  - You must rebuild the class libraries in the appropriate model 
    for the intended OWL model if they don't already exist - see 
    paragraph above. 
 
  - Due to restrictions on code size, compact model is no longer 
    supported for OWL applications. 
 
  - Note that you must use the TWindow member function AssignMenu 
    to assign a window's Attr.Menu member and to load a menu for 
    that window. 
 
  - You must alter project files and makefiles to indicate 
    compatibility with either Borland C++ version 3.0 or 3.1. 
    Add WIN30 for OWL projects from Borland C++ 3.0, or WIN31 
    for projects created under Borland C++ 3.1, to the defines 
    under Options|Compiler|Code Generation in the IDE, or passing 
    -DWIN30 or -DWIN31 to MAKE. 
 
  - World of ObjectWindows video users need to make modifications 
    to their Borland C++ 3.0 make or project files in order to 
    successfully compile their OWL code with Borland C++ 3.1. You 
    must define the WIN30 flag when compiling the OWL Video code. 
    In MAKEFILE.INC add the text, "-DWIN30" to the four 'CFLAGS'/ 
    'CFLAGSD' lines.  In all project files, you must go to Options| 
    Compiler|Code Generation and put WIN30 in the Defines combo box 
    field (at the bottom of this dialog). 
 
 
  Please see OWL31.DOC for additional information on ObjectWindows 
  Library. 
 
  TURBO VISION 
 
  - For information on the Help compiler, and how to build a help 
    document, please refer to the comments in the file TVHC.CPP in 
    the help directory.  Also, see TVDemo for an example of how to 
    add help to your applications. 
 
  - Due to the complex interactions among the Turbo Vision classes, 
    certain situations can arise involving deletion of objects that 
    cannot be properly handled through destructors.  Therefore, we 
    provide a static member function void destroy( TObject * ) to 
    the class TObject.  Whenever an object of a type derived from 
    TObject is to be deleted, the function destroy() should be called 
    instead.  This will take care of terminating the object, 
    correctly freeing the memory that it occupied.  For example: 
     
             TDialog *dlg = new TDialog( ... ); 
             //delete dlg;    // DON'T DO THIS 
             destroy( dlg );  // DO IT THIS WAY 
 
  - The Turbo Vision Source Code is provided for your use and 
    modification.  IMPORTANT: Borland Technical Support will not 
    answer questions or provide any assistance relating to this 
    product.  Essentially, the Sources are provided "as is" and you 
    are on your own. 
 
  - In order to build the library, you must have Tasm available. 
 
  - When building or modifying the library it is better to place 
    debug info in only those modules in which you are interested. 
    If you place debug info all the modules, Tlink may not be able 
    to link your application. 
 
  - In order to build an overlayed Turbo Vision application with 
    Borland C++ 3.1, make sure you observe the following: 
 
      1. You need to rebuild the Turbo Vision library with 
         overlays. Change to the SOURCE directory under TVISION 
         and enter the command 
 
                 make -DOVERLAY -B 
 
         This will produce a new version of TV.LIB which will 
         support overlays. It will also produce two .OBJ files, 
         SYSINT.OBJ and TEVENT.OBJ.  These two files contain code 
         for TV's interrupt handlers, so they cannot be  
         overlayed. 
 
      2. When building an overlayed application, you must be sure 
         to link with the three files SYSINT.OBJ, TEVENT.OBJ, and 
         TV.LIB.  The two .OBJ files must not be in overlays. 
         You also need to specify local virtual tables. 
         Your command line should look something like this: 
 
         bcc -ml -Vs -B -Yo myfile -Yo- sysint.obj tevent.obj -Yo tv.lib 
 
         See the Programmer's Guide for details on the meanings 
         of the various -Yo switches. 
 
     3. To improve performance, increase the size of the global 
         variable __ovrbuffer to 0x2000 or greater. 
 
 
  RUNTIME LIBRARY SOURCE 
 
  The Borland C++ Runtime Library Source Code is provided for 
  your use and modification.  IMPORTANT: Borland Technical 
  Support will not answer questions or provide any assistance 
  relating to this product.  Essentially, the Sources are 
  provided "as is" and you are on your own. If you find what you 
  think is a genuine problem with the source code, however, we 
  would like to hear about it. See "How to Get Help" above. 
 
  See CRTL.DOC for more information on building the Runtime 
  Library from source. 
 
 5. TESTING YOUR EXPANDED MEMORY: EMSTEST.COM 
--------------------------------------------- 
 
  Included with Borland C++ is a program to test your Expanded 
  Memory hardware and software. If you have problems using 
  Borland C++ with your EMS, type EMSTEST at the DOS prompt and 
  follow the instructions. 
 
 
 6.  CORRECTIONS TO THE DOCUMENTS 
--------------------------------- 
 
Please see the MANUAL.XXX files in the DOC subdirectory for corrections 
to the documents.