Liren Large Software Subsidy 7

home *** CD-ROM | disk | FTP | other *** search

/ Liren Large Software Subsidy 7 / 07.iso / c / c082_122 / 1.ddi / README < prev next >

Wrap

Text File | 1992-06-10 | 55.0 KB | 1,396 lines

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<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 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=<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 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 <other options> filename.res filename.rc Change this to rc -30 filename.res filename.exe .. rc <other options> 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 = <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 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.