home *** CD-ROM | disk | FTP | other *** search
/ Liren Large Software Subsidy 7 / 07.iso / c / c083 / 20.ddi / TDDOC.PAK / TD_RDME.TXT < prev    next >
Encoding:
Text File  |  1993-12-02  |  11.7 KB  |  273 lines
  1. /*************************************************************************/
  2.                              TURBO DEBUGGER
  3.                          Turbo Debugger Readme file
  4.  
  5. This file discusses the following Turbo Debugger related topics:
  6.  
  7.   1. Using TDW with Borland C++ and Borland Pascal
  8.   2. New tools
  9.   3. Debugging throw calls
  10.   4. Debugging under Windows 32s
  11.   5. Corrupt session state files
  12.   6. Using TD.EXE in a Windows DOS box
  13.   7. Debugging multiple applications using TDW
  14.   8. TDW and <Ctrl><Alt><SysReq>
  15.   9. TDW and TD32s' Icons
  16.  10. Resetting an application that's running under TDW
  17.  11. Resetting a process that's attached to TD32
  18.  12. Network messages and TDW and TD32
  19.  13. Debugging DLL's via LoadLibrary under WIndows
  20.  14. PENDING activity indicator
  21.  15. TDW Video Support with Resource intensive applications
  22.  16. TDW & The Integrated Debugger with PC Tools for Windows version 1.0.
  23.  
  24.  
  25. 1. Using TDW with Borland C++ and Borland Pascal
  26. ------------------------------------------------
  27. If you have both Borland C++ and Borland Pascal installed on your system:
  28.  
  29.   You cannot run both versions of TDW simultaneously. TDW 3.1 must be
  30.   run to debug your Borland Pascal programs, and TDW 4.0 must be run
  31.   to debug Borland C++ programs.
  32.  
  33.   Make sure that old copies of TDW.INI are removed from your system
  34.   (run the TDWINI.EXE utility to clean up old TDW.INI files).
  35.  
  36.   If you wish to use TDWGUI.DLL with TDW version 3.1 you need to
  37.   manually add UseTimer=Yes to the VideoOptions section of TDW.INI.
  38.   Note that this option should not be set when using TDW version 4.0.
  39.   This means that you would need to hand change your TDW.INI file each
  40.   time you switched between versions of TDW. For this reason, we
  41.   recommend the non-windowed video DLLs (such as SVGA.DLL) for
  42.   customers who debug both BP and BC applications.
  43.  
  44.   Check the [386Enh] section in your Windows SYSTEM.INI file for
  45.    multiple entries for the device TDDEBUG.386. Remove duplicate
  46.   entries of TDDEBUG.386 so that only the version from Borland C++
  47.   is loaded. On disk, you may also want to rename or remove the BP7
  48.   versions of TDDEBUG.386 and TDWIN.DLL to avoid their accidental loading.
  49.   You must restart Windows after making changes to system.ini.
  50.  
  51.  
  52. 2. New tools
  53. ------------
  54. The 16-bit linker now handles symbol tables larger than 64K in the
  55. debug information for an .exe file. This change required a modification
  56. to the format of the debug information generated by the linker. As a
  57. result, the following tools have been updated to correspond to this
  58. TLINK modification:
  59.  
  60.     TDW, TDUMP, TDUMP32, the IDE Debugger, the IDE Browser
  61.  
  62. If you attempt to use any of the new tools with old executable files,
  63. they will output an error message and refuse to run. To work around this
  64. condition, relink your application using the new TLINK.EXE. However, if you
  65. use an old version of TDUMP (or TDUMP32) it checks for version 4.0 and later.
  66. If TDUMP generates garbage when dump an executable file, check the symbolic
  67. debug version number contained in the header. If it is version 4.01, make sure
  68. that you are using the correct version of TDUMP (TDUMP prints out "Version 4.1"
  69. in the banner when you run them).
  70.  
  71.  
  72. 3. Debugging throw calls
  73. ------------------------
  74. If you step over or into a throw() call, the application will run until it
  75. reaches a breakpoint or program termination instead of stopping at the
  76. appropriate catch() function. To debug catch() functions, set breakpoints
  77. within the functions.
  78.  
  79.  
  80. 4. Debugging under Windows 32s
  81. ------------------------------
  82. a) To use TD32 under Windows 3.1, you must have Win32s installed. Win32s
  83. is usually installed at the same time you install BC4. If Win32s is not
  84. properly installed, TD32 will not run under Windows 3.1. To verify that
  85. Win32s is properly installed, run the Freecell application supplied with
  86. Win32s.
  87.  
  88. b) Because Win32s does not run under Windows 3.0, TD32 is not compatible
  89. with Windows 3.0.
  90.  
  91. c) TD32 can support dual monitor debugging under Win32s. Ensure that
  92. a monochrome adapter is installed in your machine and set the
  93. [VideoOptions] section of TDW.INI to the following setting:
  94.  
  95.     [VideoOptions]
  96.     MONO=yes
  97.  
  98. This operation can be performed automatically by using the TDWINI.EXE Video
  99. Configuration Utility and selecting the Mono option in the SVGA.DLL Settings
  100. Dialog.
  101.  
  102. e) You cannot trace into Windows kernel code when you debug with TD32 under
  103. Win32s. TD32 steps over any call that steps into the kernel code. If you
  104. attempt to step into a statement that does not have debug information, and
  105. that statement calls the kernel code, TD32 will not perform a Screen Swap
  106. unless Display Options are set to Always or unless you are using the
  107. TDWGUI.DLL video driver.
  108.  
  109. f) See the online text file TD_HELP!.TXT for more information on
  110. using TD32 and TDW.
  111.  
  112.  
  113. 5. Corrupt session state files
  114. ------------------------------
  115. If your machine locks up while you are debugging a Windows application,
  116. it is best to delete any session state files before restarting the debugger.
  117. This can be done by either deleting the session state files or by starting
  118. the debugger with the -jn command-line option.
  119.  
  120.  
  121. 6. Using TD.EXE in a Windows DOS box
  122. ---------------------------------------
  123. The TD.PIF file included with the BC4 installation insures the proper
  124. settings for running the DOS based Turbo Debugger (TD.EXE) in a Windows
  125. DOS box. If need be, you can create this .pif file using Window's Pif
  126. editor, and setting the following values:
  127.  
  128.     Program Filename:     TD.EXE
  129.     Window Title:       Turbo Debugger for DOS
  130.     Video Memory:       Text
  131.     Memory Requirements: 128     -1
  132.     EMS:                   0     -1
  133.     XMS Memory             0   3096
  134.     Execution:          Background & Exclusive enabled
  135.             ( required for Dual Monitor debugging )
  136.  
  137.     Close Window on Exit.
  138.  
  139.     Advanced Options:
  140.     Memory Options:  Lock Application Memory.
  141.     Display Options: Retain Video Memory.
  142.  
  143. TD in a DOS Box requires heavy use of a GDI resources. Running with a high
  144. resolution video driver on some video adapters with multiple applications 
  145. running may result in an inability to display High Resolution Graphics. If this
  146. is the case, close down one or more of the Windows applications that are 
  147. currently running. 
  148.     
  149. 7. Debugging multiple applications using TDW
  150. --------------------------------------------
  151. You can debug multiple applications under TDW as follows:
  152.  
  153.     1. Load the first program to be debugged into TDW.
  154.  
  155.     2. Once the application is loaded, press the F3 key to
  156.        display the Load Module Source or DLL Symbols dialog box.
  157.  
  158.     3. In the DLL Name text entry box, enter the name of the
  159.        .EXE or  DLL to add. If the .EXE or DLL resides in
  160.        another directory, you need to provide the full path.
  161.  
  162.     4. Press <Enter>. TDW adds the program name to the
  163.        DLLs & Programs list box and puts the !! symbol after it.
  164.  
  165.     5. Close the Load Module Source or DLL dialog box, return to
  166.        the Module window, and set any necessary breakpoints in
  167.        the first program.
  168.  
  169.     6. Press F9 to run the first program.
  170.  
  171.     7. Switch to the Windows Program Manager while the first
  172.        program is running and run the second program in the
  173.        usual way.
  174.  
  175.     8. You see the display switch back to TDW with the CPU
  176.        window showing the start-up information of the second
  177.        application. Close the CPU window.
  178.  
  179.     9. In the Module window, set any necessary breakpoints in
  180.        the second application, then press the F9 key to run it.
  181.  
  182.        This method is useful for debugging DDE conversations or any
  183.        other inter-program communication in the Windows environment
  184.        (such as OLE).
  185.  
  186.  
  187. 8. TDW and <Ctrl><Alt><SysReq>
  188. ------------------------------
  189. When you're debugging with TDW, you can press <Ctrl><Alt><SysReq> to
  190. interrupt the application being debugged and to return control to the TDW.
  191. However, the behavior in TDW 4.0 has changed slightly to accommodate the
  192. use of Microsoft's TOOLHELP.DLL. If your application is idle when you
  193. interrupt its execution, TDW posts a WM_NULL message to the application
  194. to "wake it up" so it can respond to the interrupt. Because of this, you
  195. may need to press <Ctrl><Alt><SysReq> a number of times before you get a
  196. response from the application being debugged.
  197.  
  198.  
  199. 9. TDW and TD32s' Icons
  200. -----------------------
  201. The Working Directory settings in the Turbo Debugger icons have been slightly
  202. changed. To accommodate for DLLs in the working directory of the application
  203. being debugged, TDW & TD32 set the working directory to the directory used
  204. in the Command Line input box. Because of this, TDW and TD32 ignores any
  205. directories input into the Working Directory input box. You can work around
  206. this by using the -t command line option without supplying a path. Foe example
  207.  
  208.     TDW -t MYAPP.EXE
  209.  
  210. In this case, the debugger uses the icon property's working directory, but it
  211. will not be able to find the applications DLLs.
  212.  
  213.  
  214. 10. Resetting an application that's running under TDW
  215. -----------------------------------------------------
  216. If you reset TDW before running the application you're debugged runs to
  217. completion, Windows will not free the applications resources. To prevent
  218. this from occurring, run the application being debugged to completion
  219. before restating it. Resources are freed by Windows only when an application
  220. has been terminated via a WM_QUIT message.
  221.  
  222.  
  223. 11. Resetting a process that's attached to TD32
  224. -----------------------------------------------
  225. TD32 cannot reset a process which you have attached to using the File|Attach
  226. command. If you reset or terminate a process that you attached to, you must
  227. start a new debugging session.
  228.  
  229.  
  230. 12. Network messages and TDW and TD32
  231. -------------------------------------
  232. Network message broadcasts must be disabled when you run either TDW or TD32.
  233. It is recommended that you disable message broadcasts from your Windows
  234. Network dialog in the Control Panel.
  235.  
  236.  
  237. 13. Debugging DLL's via LoadLibrary under WIndows
  238. -------------------------------------------------
  239. If you debug a DLL with debug information inside TDW and the source for the DLL
  240. resides in a different directory, make sure that TDW's <Option><Path to Source>
  241. includes the directory where the DLL source is located.
  242.  
  243.  
  244. 14. PENDING activity indicator
  245. ------------------------------
  246. The PENDING activity indicator was omitted from page 52 of the Turbo Debugger
  247. User's Guide. It is documented in the section "Controlling Program
  248. Execution" on page 28.
  249.  
  250. 15. TDW Video Support with Resource intensive applications
  251. ----------------------------------------------------------
  252. SVGA.DLL performs a mode switch using the DDK API calls Death & Resurrection. 
  253. In applications that use resources intensely ( e.g. BCW4.0 ) the Death & 
  254. Resurrection calls fail inside certain Windows Display Drivers, this is a
  255. problem with the Windows Display Driver. If you encounter such behavior change
  256. the TDW.INI settings using TDWINI.EXE for SVGA.DLL to:
  257. Use Documented Mode Switch.
  258. Restart GDI when Debugger exits. 
  259.  
  260. As an alternative we recommend that you change your Video DLL to TDWGUI.DLL.
  261.  
  262. 16. TDW & The Integrated Debugger with PC Tools for Windows version 1.0.
  263. ------------------------------------------------------------------------
  264. TDW & the Integrated Debugger are not 100% compatible with PC Tools for Windows 
  265. 1.0. The known problems inside TDW are resetting & reloading applications 
  266. causing random General Protection Faults.
  267. When debugging an application with the Integrated Debugger, random General 
  268. Protection Faults occur which would not occur if run without the debugger.
  269. Central Point has acknowledged this incompatibility.
  270.  
  271. /***************************** END OF FILE *******************************/
  272.  
  273.