CydandClaude Fable 5
63312e07f9
- BORLAND/: Borland C++ 4.52 (chosen over 4.5 by byte-match: CODE/RP/CW32.LIB
is identical to 4.52's install lib). BCC32/TLINK32/TLIB/MAKE run natively on
Win11; CODE/BT/OPT.MAK is the shipped BTL4OPT.EXE's exact flag recipe
(extender = Borland PowerPack DPMI32, not Phar Lap TNT).
- restoration/source410/: the literal 1995-form reconstruction of the missing
BT game source (never mixed into CODE/). Round 1-3 state:
* 6 of 10 surviving original TUs COMPILE CLEAN under the period toolchain
(BTMSSN, BTCNSL, BTSCNRL, BTTEAM, BTL4MODE, BTL4ARND) - first builds
since 1996.
* BT_L4/BTL4APP.CPP pilot reconstruction: 12/12 functions, Fail() lands on
its binary-recorded line 400 exactly.
* BT/BTCNSL.HPP: console wire IDs recovered from the binary's ctors
(Killed=9, Damaged=10, ScoreUpdate=13, DeathWithoutHonor=15 [T1];
TeamScore=12 flagged [T4]).
* MUNGA/: 8 engine-header backfills back-dated from the BT412 WinTesla tree
(VDATA numbering decomp-verified; AUDREND's OpenAL-era virtual removed -
the period compiler is the drift detector).
* Tooling: backdate.py (WinTesla->1995 header transform), compile410.sh
(per-TU verification sweep under authentic OPT.MAK flags).
* README: corrected roadmap - MECH.HPP is the capstone grown with the mech
TU reconstructions; BTREG.CPP green = the header-family milestone.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
422 lines
15 KiB
Plaintext
422 lines
15 KiB
Plaintext
/***********************************************************************/
|
|
TURBO DEBUGGER
|
|
TIPS AND HINTS
|
|
|
|
This file contains tips and hints concerning problems you might
|
|
encounter while using TD.EXE, TDW.EXE, and TD32.EXE. The following
|
|
topics are covered:
|
|
|
|
1. TDW.INI
|
|
2. TDW Hardware Debugging
|
|
3. Running TDW under Windows For Workgroups
|
|
4. Restart Information/Session State Saving
|
|
5. Program Reset
|
|
6. Program Interrupt Key
|
|
7. Resetting and restarting programs
|
|
8. Video Support
|
|
9. Windows debugging hints
|
|
10. Answers to common questions
|
|
|
|
|
|
------------
|
|
1. TDW.INI
|
|
------------
|
|
You must have a single copy of TDW.INI located on your system, and
|
|
it must be located in your main Windows directory (usually "\WINDOWS").
|
|
Be sure to delete any extra copies of TDW.INI that you might have on
|
|
your system.
|
|
|
|
By default, TDW.INI contains the following text:
|
|
|
|
[TurboDebugger]
|
|
VideoDll = <Your_BorlandC_Bin_Directory>\SVGA.DLL
|
|
debuggerDll = <Your_BorlandC_Bin_Directory>\TDWINTH.DLL
|
|
|
|
[VideoOptions]
|
|
|
|
You can use TD32 to debug under Win32s. However, to do so, you must
|
|
ensure you use SVGA.DLL or equivalent support in the VideoDLL entry
|
|
in the [TurboDebugger] section of TDW.INI. Use the Turbo Debugger Video
|
|
Configuration utility (TDWINI.EXE) to set the required option.
|
|
|
|
|
|
---------------------------
|
|
2. TDW Hardware Debugging
|
|
---------------------------
|
|
In order to support hardware debugging in TDW, you need to load
|
|
the device driver TDDEBUG.386. Edit your SYSTEM.INI file in the \WINDOWS
|
|
directory and add the following statement to the [386enh] section:
|
|
|
|
device=<Your_BorlandC_Bin_Directory>\TDDEBUG.386
|
|
|
|
Make sure that you comment out the line that loads the Windows driver
|
|
WINDEBUG.386 with a semicolon. For example:
|
|
|
|
;c:\windows\windebug.386
|
|
|
|
|
|
---------------------------------------------
|
|
3. Running TDW under Windows For Workgroups
|
|
---------------------------------------------
|
|
If you use Windows for Workgroups 3.11, you must use TDWINTH.DLL when
|
|
you debug with TDW. Be sure the DebuggerDll setting in your
|
|
TDW.INI file explicitly points to TDWINTH.DLL. For example:
|
|
|
|
debuggerDll=<Your_BorlandC_Bin_Directory>\TDWINTH.DLL
|
|
|
|
|
|
---------------------------------------------
|
|
4. Restart Information/Session State Saving
|
|
---------------------------------------------
|
|
Turbo Debugger saves Breakpoint, Inspector, and other session information
|
|
when you exit a debugging session. Then, when you restart a debugging
|
|
session, Turbo Debugger restores this information. To ignore the restart
|
|
information, use Turbo Debugger's -ji command line switch when you load
|
|
Turbo Debugger.
|
|
|
|
If your system crashes during a debugging session, your configuration
|
|
file is likely to become corrupt. This can cause Turbo Debugger to hang
|
|
on startup. Because of this, it is advisable to delete any .TR, .TRW, or
|
|
.TR2 files from your hard disk if you crash during a debugging session.
|
|
|
|
|
|
------------------
|
|
5. Program Reset
|
|
------------------
|
|
Dialog applications that do not have a parent window will cause your
|
|
system to hang if you reload the application.
|
|
|
|
|
|
--------------------------
|
|
6. Program Interrupt Key
|
|
--------------------------
|
|
Under TD: Ctrl-Break
|
|
Under TDW: Ctrl-Alt-SysReq
|
|
Under Win32s: Ctrl-Alt-F11
|
|
Under NT: F12
|
|
|
|
|
|
--------------------------------------
|
|
7. Resetting and restarting programs
|
|
--------------------------------------
|
|
When you reload or reset a program a number of times under Windows 32s,
|
|
it is likely that you will run out of memory. This problem has been
|
|
reported to Microsoft.
|
|
|
|
If Turbo Debugger fails to start correctly, especially after a system
|
|
crash, the debugger session state and configuration files may be
|
|
corrupted. Try removing the following files:
|
|
|
|
For TD: TDCONFIG.TD
|
|
***.TR
|
|
|
|
For TDW: TDCONFIG.TDW
|
|
***.TRW
|
|
|
|
For TD32: TDCONFIG.TD2
|
|
***.TR2
|
|
|
|
Where *** equals your application's name.
|
|
|
|
These files will be found in either the working directory,
|
|
the \BorlandC\Bin directory, or the \Windows directory.
|
|
|
|
|
|
------------------
|
|
8. Video Support
|
|
------------------
|
|
Turbo Debugger requires that you use the correct Windows video driver
|
|
for your video card. For example, if you have a TSENG card, make sure
|
|
that you are using the TSENG Windows video driver (the generic VGA
|
|
video driver does not work correctly with this video card).
|
|
|
|
To find out what type of video card you have installed in your
|
|
machine, type MSD <Enter> at the DOS prompt. Use the TDWINI.EXE
|
|
utility to set up your video driver.
|
|
|
|
SVGA.DLL supports most video card configurations, provided that you
|
|
are using the correct Windows video drivers. Use the Turbo Debugger Video
|
|
Configuration utility (TDWINI.EXE) to determine the correct Video Support
|
|
for your adapter.
|
|
|
|
|
|
Screen not being repainted
|
|
--------------------------
|
|
Ensure that the "ForceRepaint" flag is set to "Yes" in the
|
|
VideoOptions section of TDW.INI:
|
|
|
|
[VideoOptions]
|
|
ForceRepaint=Yes
|
|
|
|
This can be done through the Turbo Debugger Video Configuration
|
|
utility (TDWINI.EXE).
|
|
|
|
|
|
Dual Monitor Support under Windows 32s
|
|
--------------------------------------
|
|
TD32 can support dual monitor debugging under Windows 32s.
|
|
Ensure that a monochrome adapter is installed in your machine
|
|
and set the Mono flag in the [VideoOptions] section of TDW.INI
|
|
to "Yes."
|
|
|
|
[VideoOptions]
|
|
MONO=yes
|
|
|
|
This can be done through the Turbo Debugger Video Configuration
|
|
utility, TDWINI.EXE.
|
|
|
|
|
|
---------------------------
|
|
9. Windows debugging hints
|
|
---------------------------
|
|
View|Windows Messages
|
|
|
|
1) If you set up View|Windows Messages to display messages for
|
|
more than one procedure or handle or both, do not log all
|
|
messages. Instead, log specific messages for each procedure or
|
|
handle. If you log all messages, the system might hang, in
|
|
which case you will have to reboot to continue. This behavior
|
|
is due to the large number of messages being transferred
|
|
between Windows and Turbo Debugger.
|
|
|
|
2) When setting a break on the Mouse class of messages, note that
|
|
a "mouse down" message must be followed by a "mouse up" message
|
|
before the keyboard will become active again. When you return
|
|
to the application, you might have to press the mouse button
|
|
several times (or press the <ALT> key) to get Windows to receive a
|
|
"mouse up" message. You'll know Windows has received the message
|
|
when you see it in the bottom pane of the Windows Message window
|
|
after the program breaks.
|
|
|
|
|
|
--------------------------------
|
|
10. Answers to common questions
|
|
--------------------------------
|
|
Following is a list of the most commonly asked questions about TDW:
|
|
|
|
1) Are there any syntactic or parsing differences between Turbo
|
|
Debugger's C expression evaluation and Turbo C++ for Windows'?
|
|
|
|
You can't pass constant-string arguments when evaluating
|
|
functions.
|
|
|
|
OK: myfunc(123) myfunc(string_variable)
|
|
|
|
BAD: myfunc("constant")
|
|
|
|
2) What should I be aware of when I am debugging multilanguage
|
|
programs with Turbo Debugger?
|
|
|
|
Turbo Debugger's default source language is "Source," which
|
|
means it chooses the expression language based on the current
|
|
source module. This can cause some confusion if your program
|
|
has source modules written in different languages (like C
|
|
and assembler). Since you are actually entering a language
|
|
expression any time Turbo Debugger prompts you for a value
|
|
or an address, this can cause some unexpected results:
|
|
|
|
a. Even if you are in a CPU window or a Dump window, you
|
|
must still enter addresses in the source language,
|
|
despite the fact that the window is displaying in hex.
|
|
For example, to display the contents of memory address
|
|
1234:5678, you must type one of the following
|
|
expressions, depending on your current source language:
|
|
|
|
C 0x1234:0x5678
|
|
Pascal $1234:$5678
|
|
Assembler 1234H:5678H
|
|
|
|
b. When your current language is assembler, you must be
|
|
careful when entering hex numbers, since they are
|
|
interpreted EXACTLY as they would be in an assembler
|
|
source file. This means that if you want to enter a
|
|
number that starts with one of the hex digits A - F, you
|
|
must first precede the letter with a 0 so Turbo Debugger
|
|
knows you are entering a number. Likewise, if your number
|
|
ends in B or D (indicating a binary or decimal number), you
|
|
must add an H to indicate that you really want a hex number:
|
|
|
|
OK: 0aaaa 123dh 89abh
|
|
|
|
BAD: aaaa 123d 89ab
|
|
|
|
3) Why does the text "Cannot be changed" come up when I do an
|
|
assignment in the Data/Evaluate/Modify "New value" pane?
|
|
|
|
If you use the Data/Evaluate/Modify command (Ctrl-F4) to
|
|
change a variable by direct assignment, the "New value" pane
|
|
will say "Cannot be changed." This doesn't mean the
|
|
assignment didn't take effect. What it does mean is that the
|
|
assignment expression as a whole is not a memory-referencing
|
|
expression whose value you can change by moving to the
|
|
bottom pane. Here are some examples of direct assignment
|
|
expressions:
|
|
|
|
C x = 4
|
|
Pascal ratio := 1.234
|
|
Assembler wval = 4 shl 2
|
|
|
|
If you had typed just "x," "ratio," or "wval" into the top
|
|
pane, then you would be able to move to the bottom pane and
|
|
enter a new value. The direct assignment method using the
|
|
"=" or ":=" assignment operator is quicker and more
|
|
convenient if you don't care about examining the value of
|
|
the variable before modifying it.
|
|
|
|
|
|
4) What could happen when global breakpoints are set on local
|
|
variables?
|
|
|
|
When you set global breakpoints using local variables, make
|
|
sure the breakpoints are cleared before you exit the
|
|
procedure or function that the variables are defined in. The
|
|
best way to do this is to put a breakpoint on the last line
|
|
of the procedure or function. If you do not clear the
|
|
breakpoints, your program will break unexpectedly and may
|
|
even hang on some machines because the breakpoints are being
|
|
set in memory that is not currently being used by the
|
|
procedure or function.
|
|
|
|
5) Why is execution slower when tracing (F7) than when stepping
|
|
(F8) through my programs?
|
|
|
|
TDW can do reverse execution, which means that when you are
|
|
tracing through your program, TDW could be saving all the
|
|
information about each source line you trace over. TDW only
|
|
saves this information in the Module window if you have chosen
|
|
View|Execution History and toggled the Full History local menu
|
|
command to 'Yes'.
|
|
|
|
If you want faster execution you can step over (F8) the instruction
|
|
or toggle the Full History option to 'No' in the Execution History
|
|
window. (Although reverse execution is always available in the
|
|
CPU view, you must toggle this option to 'Yes' for it to work
|
|
in the Module view. The default setting in the Module view is 'No'.)
|
|
|
|
6) What are some of the syntactic and parsing differences
|
|
between Turbo Debugger's built-in assembler and the
|
|
standalone Turbo Assembler?
|
|
|
|
A discussion follows this short example program:
|
|
|
|
.model small
|
|
.data
|
|
|
|
abc struc
|
|
mem1 dd ?
|
|
mem2 db ?
|
|
mem3 db " "
|
|
abc ends
|
|
|
|
align 16
|
|
a abc <1,2,"xyz">
|
|
|
|
msg1 db "testing 1 2 3", 0
|
|
msg2 db "hello world", 0
|
|
nmptr dw msg1
|
|
fmptr dd msg1,msg2
|
|
nfmptr dw fmptr
|
|
xx dw seg a
|
|
|
|
.code
|
|
|
|
push cs
|
|
pop ds
|
|
mov bx,offset a
|
|
mov bx,nmptr
|
|
les si,fmptr
|
|
mov ah,4ch
|
|
int 21h
|
|
end
|
|
|
|
Because the assembler expression parser does not accept all legal
|
|
TASM instruction operands, Turbo Debugger assembler expressions
|
|
can be more general than those of TASM and can use multiple levels
|
|
of memory-referencing, much like C and Pascal. However, there are a
|
|
few constructs that you may be used to that you'll have to specify
|
|
differently for the Turbo Debugger assembler expression parser to
|
|
accept them:
|
|
|
|
a. Size overrides should always appear inside the
|
|
brackets; PTR is optional after the size. Also, when
|
|
referring to a structure, you must use the name of the
|
|
structure, not the name of the variable:
|
|
|
|
OK: [byte ptr bx] [dword si] [abc bx]
|
|
|
|
BAD: byte ptr[bx] [struc abc bx] [a bx]
|
|
|
|
b. You must specify a structure name when accessing the
|
|
members of a structure with a register pointer.
|
|
|
|
OK: [abc ptr bx].mem1 [abc bx].mem3 + 1
|
|
|
|
BAD: [bx].mem1
|
|
|
|
c. You can't use multiple instances of brackets ([]) unless they are
|
|
adjacent, and you can only follow a bracketed expression with
|
|
a dot and a structure member name or another bracketed
|
|
expression:
|
|
|
|
OK: 4[bx][si] [abc bx].mem2
|
|
|
|
BAD: [bx]4[si] [bx]+4
|
|
|
|
d. If you use a register as part of a memory expression
|
|
and you don't specify a size, WORD is assumed:
|
|
|
|
[bx] is the same as [word bx]
|
|
|
|
e. You can use any register you want between brackets ([]),
|
|
not just the combinations of BX, BP, SI, and DI allowed in
|
|
instruction operands. For example,
|
|
|
|
[ax+bx]
|
|
[bx+sp]
|
|
|
|
f. You can use multiple levels of brackets to follow chains of
|
|
pointers. For example,
|
|
|
|
[byte [[nfmptr]+4]]
|
|
|
|
g. Be careful with using registers to access memory locations.
|
|
You might get unexpected results if your segment
|
|
registers are not set up properly. If you don't
|
|
explicitly specify a segment register, Turbo Debugger
|
|
uses the DS register to reference memory.
|
|
|
|
h. When you do specify a segment register, make sure you
|
|
follow the same rule for size overrides: put it
|
|
INSIDE the brackets, as follows:
|
|
|
|
OK: [byte es:di] [es:fmptr]
|
|
|
|
BAD: es:[byte di]
|
|
|
|
i. Use the OFFSET operator to get the address of a
|
|
variable or structure. Turbo Debugger automatically
|
|
supplies the brackets around a variable name if you just type
|
|
the variable name alone.
|
|
|
|
a contents of structure a
|
|
[a] contents of structure a
|
|
offset a address of structure a
|
|
|
|
j. You can use the type overrides and the format control
|
|
count to examine any area of memory displayed as you wish.
|
|
|
|
[byte es:bx],10 10 bytes pointed to by es:bx
|
|
[dword ds:si],4 4 dwords pointed to by ds:si
|
|
|
|
This is very useful when specifying watch expressions.
|
|
|
|
k. Sometimes you use a word memory location or register to
|
|
point to a paragraph in memory that contains a data
|
|
structure. Access the structure with expressions like
|
|
|
|
[abc [xx]:0].mem1
|
|
[abc es:0].mem3
|
|
|
|
/************************* END OF FILE *****************************/
|
|
|