                      Welcome to Borland C++ 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 

     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.

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

  In addition, many problems users have reported have been
  corrected in this release.

  - 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<model> files.c files2.c

    where <model> 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<model> +-files.obj +-files2.obj

    where <model> 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 <DLL> 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 Win 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.  

  - 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=<filename> 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 symbols 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.

  - 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 <other options> filename.res filename.rc

    Change this to

            rc -30 filename.res filename.exe
            ..
            rc  <other options> filename.res filename.rc

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

  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.

  - 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 = <blank>
     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 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.


 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.
