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