home *** CD-ROM | disk | FTP | other *** search
/ Reverse Code Engineering RCE CD +sandman 2000 / ReverseCodeEngineeringRceCdsandman2000.iso / RCE / Tools / TASM V5 / TASMDOC.PAK / TD_RDME.TXT < prev    next >
Encoding:
Text File  |  1996-02-21  |  23.8 KB  |  620 lines
  1. /**********************************************************************************/
  2.                                  TURBO DEBUGGER
  3.                             Turbo Debugger Readme file
  4.  
  5. This file discusses the following Turbo Debugger related topics:
  6.  
  7. 1. New tools
  8. 2. Running TD32 and Windows NT
  9. 3. Corrupt session state files
  10. 4. Using TD.EXE in a Windows DOS box
  11. 5. Debugging multiple applications using TDW
  12. 6. Interrupting your program execution
  13. 7. TDW and TD32 icons
  14. 8. Network messages and TDW and TD32
  15. 9. TDW video support with resource intensive applications
  16. 10. Using TDW with Borland C++ and Delphi
  17. 11. TDW.INI
  18. 12. TDW hardware debugging
  19. 13. Running TDW under Windows for Workgroups
  20. 14. Running TDW under Windows 95
  21. 15. Video support
  22. 16. Debugging window messages
  23. 17. Debugging Delphi applications
  24. 18. WREMOTE under Windows NT
  25. 19. Debugging under Win32s
  26. 20. Answers to common questions
  27.  
  28.  
  29. 1. New tools
  30. ------------
  31. The 16-bit linker now handles symbol tables larger than 64K in the
  32. debug information for an .EXE file. This change required a modification
  33. to the format of the debug information generated by the linker. As a
  34. result, the following tools have been updated to correspond to this
  35. TLINK modification:
  36.  
  37.     TDW, TDUMP, the IDE Debugger, the IDE Browser
  38.  
  39. If you attempt to use any of the new tools with old executable files,
  40. they will output an error message and refuse to run. To work around this
  41. condition, relink your application using the new TLINK.EXE. However, if you
  42. use an old version of TDUMP it checks for version 4.0 and later.
  43. If TDUMP generates garbage when dumping an executable file, check the 
  44. symbolic debug version number contained in the header. If it is version 
  45. 4.01, make sure that you are using the correct version of TDUMP.
  46.  
  47.  
  48. 2. Running TD32 and Windows NT
  49. -------------------------------
  50. If you are running Windows NT 3.51 and are using TD32 to debug an application
  51. that resides on a Novell network, you must have the Windows NT 3.51 ServicePack
  52. 3 (or higher) installed.
  53.  
  54.  
  55. 3. Corrupt session state files
  56. ------------------------------
  57. If your machine locks up while you are debugging a Windows application,
  58. your configuration files are likely to become corrupt. This can cause Turbo
  59. Debugger to hang on startup. In this case, it is advisable to either start
  60. the debugger with the -jn command-line option or delete the following files:
  61.  
  62. For TD: TDCONFIG.TD
  63.              ***.TR
  64.  
  65. For TDW: TDCONFIG.TDW
  66.               ***.TRW
  67.  
  68. For TD32: TDCONFIG.TD2
  69.                ***.TR2
  70.  
  71. Where *** equals your application's name.
  72.  
  73. These files will most likely be found in either the working directory, the
  74. \BorlandC\Bin directory or in the \Windows directory.
  75.  
  76.  
  77. 4. Using TD.EXE in a Windows DOS box
  78. ------------------------------------
  79. The TD.PIF file included with the BC45 installation insures the proper
  80. settings for running the DOS based Turbo Debugger (TD.EXE) in a Windows
  81. DOS box. If need be, you can create this .PIF file using Window's Pif
  82. editor, and setting the following values:
  83.  
  84.     Program Filename:     TD.EXE
  85.     Window Title:       Turbo Debugger for DOS
  86.     Video Memory:       Text
  87.     Memory Requirements: 128     -1
  88.     EMS:                   0     -1
  89.     XMS Memory             0   3096
  90.     Execution:          Background & Exclusive enabled
  91.                         ( required for Dual Monitor debugging )
  92.  
  93.     Close Window on Exit.
  94.  
  95.     Advanced Options:
  96.     Memory Options:  Lock Application Memory.
  97.     Display Options: Retain Video Memory.
  98.  
  99. TD.EXE running in a DOS Box results in heavy use of the GDI resources.
  100. Running a high resolution video driver on some video adapters while
  101. running multiple applications can result in an inability to display
  102. High Resolution Graphics. If this is the case, close one or more of the
  103. Windows applications that are currently running.
  104.  
  105.  
  106. 5. Debugging multiple applications using TDW
  107. --------------------------------------------
  108. You can debug multiple applications under TDW as follows:
  109.  
  110.     1) Load the first program to be debugged into TDW.
  111.  
  112.     2) Once the application is loaded, press the F3 key to
  113.        display the Load Module Source or DLL Symbols dialog box.
  114.  
  115.     3) In the DLL Name text entry box, enter the name of the
  116.        .EXE or  DLL to add. If the .EXE or DLL resides in
  117.        another directory, you need to provide the full path.
  118.  
  119.     4) Press <Enter>. TDW adds the program name to the
  120.        DLLs & Programs list box and puts the !! symbol after it.
  121.  
  122.     5) Close the Load Module Source or DLL dialog box, return to
  123.        the Module window, and set any necessary breakpoints in
  124.        the first program.
  125.  
  126.     6) Press F9 to run the first program.
  127.  
  128.     7) Switch to the Windows Program Manager while the first
  129.        program is running and run the second program in the
  130.        usual way.
  131.  
  132.     8) You see the display switch back to TDW with the CPU
  133.        window showing the start-up information of the second
  134.        application. Close the CPU window.
  135.  
  136.     9) In the Module window, set any necessary breakpoints in
  137.        the second application, then press the F9 key to run it.
  138.  
  139.        This method is useful for debugging DDE conversations or any
  140.        other inter-program communication in the Windows environment
  141.        (such as OLE 2 applications).
  142.  
  143.  
  144. 6. Interrupting your program execution
  145. --------------------------------------
  146. The system interrupt keystrokes no longer work in in Turbo Debugger versions
  147. 4.0 and later. In version 4.0, Turbo Debugger changed the debugging API from
  148. WINDEBUG to TOOLHELP, as was recommended by Microsoft. Unfortunately, the
  149. system interrupt keys are not documented in Microsoft's TOOLHELP API.
  150.  
  151. Here are several methods to interrupt Turbo Debugger while your application
  152. runs:
  153.  
  154. 1) If you have Turbo Debugger 3.1, you can use the TDDEBUG.386 that was
  155.    shipped with that version of the software. Set the driver in the [386 Enh]
  156.    section of your SYSTEM.INI, and use the TDWIN.DLL (shipped with BC++ 3.1)
  157.    as your DEBUGGERDLL in your TDW.INI.
  158.  
  159. 2) Pick a certain key on your keyboard (for example, ~) to use as the
  160.    system interrupt key. In the message handler for WM_CHAR, trap the message
  161.    for that key being pressed and execute an "asm int 3" instruction. This
  162.    causes the keystroke to issue a "breakpoint," which pauses the execution of
  163.    your application.
  164.  
  165.    While this method works for all versions of Turbo Debugger, it has the
  166.    disadvantage that you must modify your application. If you use this method,
  167.    make sure to remove the added keystroke handler before you distribute your
  168.    final application.
  169.  
  170. 3) If you are using Windows NT to debug a 32-bit application with TD32,
  171.    press F12 to interrupt your program execution.
  172.  
  173. 4) If you are using Windows 95 to debug a 32-bit application with TD32:
  174.    a) Place the debugger in asyncronous mode by setting Run|Wait For Child
  175.       to "No."
  176.    b) When your programis running, set a breakpoint on a line of code that
  177.       will execute.
  178.    c) When the Status Indicator on the Turbo Debugger menu bar reads
  179.       "PENDING," choose Run|Next Pending Status.
  180.    This places you back in the debugger where you can continue debugging.
  181.  
  182.  
  183. 7. TDW and TD32 icons
  184. ---------------------
  185. To accommodate for .DLLs in the working directory of the application being
  186. debugged, TDW & TD32 set the working directory to the directory used in the
  187. Command Line input box. Because of this, TDW and TD32 ignore any directories
  188. input into the Working Directory input box. You can work around this by
  189. using the -t command line option without supplying a path. For example:
  190.  
  191.     TDW -t MYAPP.EXE
  192.  
  193. causes the debugger to use the icon property's working directory, but
  194. it will not be able to find the applications .DLL files.
  195.  
  196.  
  197. 8. Network messages and TDW and TD32
  198. ------------------------------------
  199. Network message broadcasts must be disabled when you run either TDW or TD32.
  200. It is recommended that you disable message broadcasts from your Windows
  201. Network dialog in the Control Panel.
  202.  
  203.  
  204. 9. TDW video support with resource intensive applications
  205. ---------------------------------------------------------
  206. SVGA.DLL performs a mode switch using the Death & Resurrection DDK API
  207. calls. In applications that use resources intensely ( e.g. BCW ) the
  208. Death & Resurrection calls fail inside certain Windows Display Drivers.
  209. This is a problem with the Windows display driver. If you encounter such
  210. behavior, change the TDW.INI settings using TDWINI.EXE for SVGA.DLL to:
  211.  
  212.     Use Documented Mode Switch
  213.  
  214. then restart the GDI when Turbo Debugger exits.
  215.  
  216. As an alternative, change your Video .DLL to TDWGUI.DLL.
  217.  
  218.  
  219. 10. Using TDW with Borland C++ and Delphi
  220. -----------------------------------------
  221. If you have both Borland C++ and Delphi installed on your system:
  222.  
  223.  * Make sure that old copies of TDW.INI are removed from your system
  224.    (run the TDWINI.EXE utility to clean up old TDW.INI files).
  225.  
  226.  * Check the [386Enh] section in your Windows SYSTEM.INI file for
  227.    multiple entries for the device TDDEBUG.386. Remove duplicate
  228.    entries of TDDEBUG.386 so that you load only the latest version. 
  229.    On disk, you may also want to rename or remove any earlier versions
  230.    of TDDEBUG.386 and TDWIN.DLL to avoid their accidental loading.
  231.    You must restart Windows after making changes to SYSTEM.INI.
  232.  
  233.  
  234. 11. TDW.INI
  235. -----------
  236. You must have a single copy of TDW.INI located on your system, and
  237. it must be located in your main Windows directory (usually "\WINDOWS").
  238. Be sure to delete any extra copies of TDW.INI that you might have on
  239. your system.
  240.  
  241. If you use a dual-boot system (for example, if you boot up into either
  242. Windows 3.1 or Windows NT on a single system), you must reinstall the
  243. correct video driver with TDWINI.EXE each time you change the operating
  244. system you boot into; you cannot configure a different TDW.INI file
  245. for each operating system you boot into.
  246.  
  247. By default, TDW.INI contains the following text:
  248.  
  249.    [TurboDebugger]
  250.    VideoDll = <Your_Borland_Compiler_Bin_Directory>\SVGA.DLL
  251.    debuggerDll = <Your_Borland_Compiler_Bin_Directory>\TDWINTH.DLL
  252.  
  253.    [VideoOptions]
  254.  
  255.  
  256. 12. TDW hardware debugging
  257. --------------------------
  258. In order to support hardware debugging in TDW, you need to load
  259. the device driver TDDEBUG.386. Edit your SYSTEM.INI file in the \WINDOWS
  260. directory and add the following statement to the [386enh] section:
  261.  
  262.    device=<Your_Borland_Compiler_Bin_Directory>\TDDEBUG.386
  263.  
  264. Make sure that you comment out the line that loads the Windows driver
  265. WINDEBUG.386 with a semicolon. For example:
  266.  
  267.    ;c:\windows\windebug.386
  268.  
  269.  
  270. 13. Running TDW under Windows for Workgroups
  271. --------------------------------------------
  272. If you use Windows for Workgroups 3.11, you must use TDWINTH.DLL when
  273. you debug with TDW. Be sure the DebuggerDll setting in your
  274. TDW.INI file explicitly points to TDWINTH.DLL. For example:
  275.  
  276.    debuggerDll=<Your_Borland_Compiler_Bin_Directory>\TDWINTH.DLL
  277.  
  278.  
  279. 14. Running TDW under Windows 95
  280. --------------------------------
  281. Because TDW.EXE is a hard-mode debugger, it takes control of the WIN16 subsystem
  282. on Windows 95. Pressing <Ctrl><Alt><Delete> to attempt to change tasks under
  283. Windows 95 can leave the debugger in an unstable state. To change tasks under
  284. Windows 95, you must exit TDW.EXE.
  285.  
  286.  
  287. 15. Video support
  288. -----------------
  289. Turbo Debugger requires that you use the correct Windows video driver
  290. for your video card. For example, if you have a TSENG card, make sure
  291. that you are using the TSENG Windows video driver (the generic VGA
  292. video driver does not work correctly with this video card).
  293.  
  294. To find out what type of video card you have installed in your
  295. machine, type MSD <Enter> at the DOS prompt. Use the TDWINI.EXE
  296. utility to set up your video driver.
  297.  
  298. SVGA.DLL supports most video card configurations, provided that you
  299. are using the correct Windows video drivers. Use the Turbo Debugger Video
  300. Configuration utility (TDWINI.EXE) to determine the correct Video Support
  301. for your adapter. 
  302.  
  303. There are known conflicts between TDW's SVGA video DLL and some video drivers. To
  304. solve the problem, reconfigure TDW to use TDWGUI.DLL or reconfigure Windows to use a standard VGA or SVGA driver.
  305.  
  306.  
  307. Screen not being repainted
  308. - - - - - - - - - - - - - -
  309. Ensure that the "ForceRepaint" flag is set to "Yes" in the
  310. VideoOptions section of TDW.INI:
  311.  
  312.      [VideoOptions]
  313.      ForceRepaint=Yes
  314.  
  315. This can be done through the Turbo Debugger Video Configuration
  316. utility (TDWINI.EXE).
  317.  
  318.  
  319. 16. Debugging window messages
  320. -----------------------------
  321. 1) If you set up View|Windows Messages to display messages for
  322.    more than one procedure or handle or both, do not log all
  323.    messages. Instead, log specific messages for each procedure or
  324.    handle. If you log all messages, the system might hang, in
  325.    which case you will have to reboot to continue. This behavior
  326.    is due to the large number of messages being transferred
  327.    between Windows and Turbo Debugger.
  328.  
  329. 2) When setting a break on the Mouse class of messages, note that
  330.    a "mouse down" message must be followed by a "mouse up" message
  331.    before the keyboard will become active again. When you return
  332.    to the application, you might have to press the mouse button
  333.    several times (or press the <ALT> key) to get Windows to receive a
  334.    "mouse up" message. You'll know Windows has received the message
  335.    when you see it in the bottom pane of the Windows Message window
  336.    after the program breaks.
  337.  
  338.  
  339. 17. Debugging Delphi applications
  340. ---------------------------------
  341. Stepping into Delphi's dynamic methods
  342. - - - - - - - - - - - - - - - - - - - -
  343. By default, single-stepping through a program skips over dynamic methods; Turbo
  344. Debugger does not step into them. This is because TDW normally determines all the
  345. single-step points when the program is first loaded, at which time dynamic methods
  346. are not yet defined.
  347.  
  348. However, by following these steps, you can change the way TDW determines stop
  349. points, which makes it possible to step into dynamic methods:
  350.     1) Choose View|Execution History.
  351.  
  352.     2) Invoke the Execution History SpeedMenu, either by clicking the right mouse
  353.        button or by pressing Alt+F10.
  354.  
  355.     3) Toggle the "Full history" option from No to Yes.
  356.  
  357. You should now be able to step into dynamic methods created by Delphi.
  358.  
  359.  
  360. WREMOTE and Delphi exception handling
  361. - - - - - - - - - - - - - - - - - - - - -
  362. Exception handling in a Delphi application is not visible from WREMOTE. To debug
  363. Delphi exception handling code, you must use Turbo Debugger locally.
  364.  
  365.  
  366. 18. WREMOTE under Windows NT
  367. ----------------------------
  368. There is a new command line switch you can use with TDW and WREMOTE which 
  369. facilitates remote network debugging under NT. Use the -raX command-line switch to
  370. tell TDW or WREMOTE which LAN adapter port is to be used by NetBios. The adapter
  371. number must match the following registry key:
  372.  
  373. HKEY_LOCAL_MACHINE
  374.      Software
  375.          Microsoft
  376.                RPC
  377.                   NetBios
  378.                        ncacn_nb_nb0: xxx
  379.  
  380. For example, if the value of the ncacn_nb_nb key is 0x2, then you must use
  381. command-line switch -ra2. The default value for the -ra switch is 0 (zero).
  382.  
  383. Remember: Network remote debugging is only supported if you have installed the
  384. NetBios network protocol.
  385.  
  386.  
  387. 19. Debugging under Win32s
  388. --------------------------
  389. TD32 no longer supports Win32s debugging.
  390.  
  391.  
  392. 20. Answers to common questions
  393. -------------------------------
  394. Following is a list of the most commonly asked questions about Turbo debugger:
  395.  
  396. 1) Are there any syntactic or parsing differences between Turbo
  397.    Debugger's C expression evaluation and Turbo C++ for Windows'?
  398.  
  399.    You can't pass constant-string arguments when evaluating
  400.    functions.
  401.  
  402.      OK:   myfunc(123)   myfunc(string_variable)
  403.  
  404.      BAD:  myfunc("constant")
  405.  
  406. 2) What should I be aware of when I am debugging multilanguage
  407.    programs with Turbo Debugger?
  408.  
  409.    Turbo Debugger's default source language is "Source," which
  410.    means it chooses the expression language based on the current
  411.    source module. This can cause some confusion if your program
  412.    has source modules written in different languages (like C
  413.    and assembler). Since you are actually entering a language
  414.    expression any time Turbo Debugger prompts you for a value
  415.    or an address, this can cause some unexpected results:
  416.  
  417.    a. Even if you are in a CPU window or a Dump window, you
  418.       must still enter addresses in the source language,
  419.       despite the fact that the window is displaying in hex.
  420.       For example, to display the contents of memory address
  421.       1234:5678, you must type one of the following
  422.       expressions, depending on your current source language:
  423.  
  424.        C            0x1234:0x5678
  425.        Pascal        $1234:$5678
  426.        Assembler     1234H:5678H
  427.  
  428.    b. When your current language is assembler, you must be
  429.       careful when entering hex numbers, since they are
  430.       interpreted EXACTLY as they would be in an assembler
  431.       source file. This means that if you want to enter a
  432.       number that starts with one of the hex digits A - F, you
  433.       must first precede the letter with a 0 so Turbo Debugger
  434.       knows you are entering a number. Likewise, if your number
  435.       ends in B or D (indicating a binary or decimal number), you
  436.       must add an H to indicate that you really want a hex number:
  437.  
  438.        OK:   0aaaa   123dh   89abh
  439.  
  440.        BAD:  aaaa    123d    89ab
  441.  
  442. 3) Why does the text "Cannot be changed" come up when I do an
  443.    assignment in the Data/Evaluate/Modify "New value" pane?
  444.  
  445.    If you use the Data/Evaluate/Modify command (Ctrl-F4) to
  446.    change a variable by direct assignment, the "New value" pane
  447.    will say "Cannot be changed." This doesn't mean the 
  448.    assignment didn't take effect. What it does mean is that the
  449.    assignment expression as a whole is not a memory-referencing
  450.    expression whose value you can change by moving to the
  451.    bottom pane. Here are some examples of direct assignment
  452.    expressions:
  453.  
  454.      C              x = 4
  455.      Pascal         ratio := 1.234
  456.      Assembler      wval = 4 shl 2
  457.  
  458.    If you had typed just "x," "ratio," or "wval" into the top
  459.    pane, then you would be able to move to the bottom pane and
  460.    enter a new value. The direct assignment method using the
  461.    "=" or ":=" assignment operator is quicker and more
  462.    convenient if you don't care about examining the value of
  463.    the variable before modifying it.
  464.  
  465.  
  466. 4) What could happen when global breakpoints are set on local
  467.    variables?
  468.  
  469.    When you set global breakpoints using local variables, make
  470.    sure the breakpoints are cleared before you exit the
  471.    procedure or function that the variables are defined in. The
  472.    best way to do this is to put a breakpoint on the last line
  473.    of the procedure or function. If you do not clear the
  474.    breakpoints, your program will break unexpectedly and may
  475.    even hang on some machines because the breakpoints are being
  476.    set in memory that is not currently being used by the
  477.    procedure or function.
  478.  
  479. 5) Why is execution slower when tracing (F7) than when stepping
  480.    (F8) through my programs?
  481.  
  482.    TDW can do reverse execution, which means that when you are
  483.    tracing through your program, Turbo Debugger could be saving all
  484.    the information about each source line you trace over. TD only
  485.    saves this information in the Module window if you have chosen
  486.    View|Execution History and toggled the Full History local menu
  487.    command to 'Yes'.
  488.  
  489.    If you want faster execution you can step over (F8) the instruction
  490.    or toggle the Full History option to 'No' in the Execution History
  491.    window. (Although reverse execution is always available in the
  492.    CPU view, you must toggle this option to 'Yes' for it to work
  493.    in the Module view. The default setting in the Module view is 'No'.)
  494.  
  495. 6) What are some of the syntactic and parsing differences between
  496.    Turbo Debugger's built-in assembler and the standalone Turbo Assembler?
  497.  
  498.    A discussion follows this short example assembler program:
  499.  
  500.           .model small
  501.           .data
  502.  
  503.    abc    struc
  504.    mem1   dd      ?
  505.    mem2   db      ?
  506.    mem3   db      "   "
  507.    abc    ends
  508.  
  509.           align   16
  510.    a      abc     <1,2,"xyz">
  511.  
  512.    msg1   db      "testing 1 2 3", 0
  513.    msg2   db      "hello world", 0
  514.    nmptr  dw      msg1
  515.    fmptr  dd      msg1,msg2
  516.    nfmptr dw      fmptr
  517.    xx     dw      seg a
  518.  
  519.           .code
  520.  
  521.           push   cs
  522.           pop    ds
  523.           mov    bx,offset a
  524.           mov    bx,nmptr
  525.           les    si,fmptr
  526.           mov    ah,4ch
  527.           int    21h
  528.           end
  529.  
  530.    Because the assembler expression parser does not accept all legal
  531.    TASM instruction operands, Turbo Debugger assembler expressions
  532.    can be more general than those of TASM and can use multiple levels
  533.    of memory-referencing, much like C and Pascal. However, there are 
  534.    a few constructs that you may be used to that you'll have to 
  535.    specify differently for the Turbo Debugger assembler expression 
  536.    parser to accept them:
  537.  
  538.      a. Size overrides should always appear inside the
  539.         brackets; PTR is optional after the size. Also, when
  540.         referring to a structure, you must use the name of the
  541.         structure, not the name of the variable:
  542.  
  543.           OK:  [byte ptr bx]   [dword si]        [abc bx]
  544.  
  545.           BAD: byte ptr[bx]    [struc abc bx]    [a bx]
  546.  
  547.      b. You must specify a structure name when accessing the
  548.         members of a structure with a register pointer.
  549.  
  550.           OK:  [abc ptr bx].mem1  [abc bx].mem3 + 1
  551.  
  552.           BAD: [bx].mem1
  553.  
  554.      c. You can't use multiple instances of brackets ([]) unless they 
  555.         are adjacent, and you can only follow a bracketed expression 
  556.         with a dot and a structure member name or another bracketed
  557.         expression:
  558.  
  559.           OK:  4[bx][si]    [abc bx].mem2
  560.  
  561.           BAD: [bx]4[si]    [bx]+4
  562.  
  563.      d. If you use a register as part of a memory expression
  564.         and you don't specify a size, WORD is assumed:
  565.  
  566.           [bx] is the same as [word bx]
  567.  
  568.      e. You can use any register you want between brackets ([]),
  569.         not just the combinations of BX, BP, SI, and DI allowed in
  570.         instruction operands. For example,
  571.  
  572.           [ax+bx]
  573.           [bx+sp]
  574.  
  575.      f. You can use multiple levels of brackets to follow chains of
  576.         pointers. For example,
  577.  
  578.           [byte [[nfmptr]+4]]
  579.  
  580.      g. Be careful with using registers to access memory locations.
  581.         You might get unexpected results if your segment
  582.         registers are not set up properly. If you don't
  583.         explicitly specify a segment register, Turbo Debugger
  584.         uses the DS register to reference memory.
  585.  
  586.      h. When you do specify a segment register, make sure you
  587.         follow the same rule for size overrides: put it
  588.         INSIDE the brackets, as follows:
  589.  
  590.           OK:  [byte es:di]    [es:fmptr]
  591.  
  592.           BAD: es:[byte di]
  593.  
  594.      i. Use the OFFSET operator to get the address of a
  595.         variable or structure. Turbo Debugger automatically
  596.         supplies the brackets around a variable name if you just type
  597.         the variable name alone.
  598.  
  599.           a            contents of structure a
  600.           [a]          contents of structure a
  601.           offset a     address of structure a
  602.  
  603.      j. You can use the type overrides and the format control
  604.         count to examine any area of memory displayed as you wish.
  605.  
  606.           [byte es:bx],10  10 bytes pointed to by es:bx
  607.           [dword ds:si],4  4 dwords pointed to by ds:si
  608.  
  609.         This is very useful when specifying watch expressions.
  610.  
  611.      k. Sometimes you use a word memory location or register to
  612.         point to a paragraph in memory that contains a data
  613.         structure. Access the structure with expressions like
  614.  
  615.           [abc [xx]:0].mem1
  616.           [abc es:0].mem3
  617.  
  618. /********************************* END OF FILE ************************************/
  619.  
  620.