SDBG can be invoked from Visual Studio
if the project is set in "Debug Win32" or "CheckMate
Win32" mode. SDBG is launched externally when a "Run to Cursor" or "Run to
breakpoint" command is executed (see Getting
started with FTN95). If possible you should use the integrated debugger
instead. To do this select "CheckMate .NET" or "Debug .NET" for development and
change to the Win32 platform for release.
SDBG can be invoked from the command line in Command Prompt
bix in one of several ways.
Used in this way /BREAK implies the /CHECK and /LGO options.
You can also use /PROFILE on the FTN95 command line (see Profiling
For Win32 executables use SLINK and then type,
The source file for each section of the code to be debugged should be available
exactly as it was compiled (i.e. you must not edit these source files prior to
using the debugger).
Assuming that no compile-time error is encountered, each of these commands will
cause your program to be suspended at the first executable statement in a
module compiled with /DEBUG.
The /DEBUG and /DBREAK options cause the compiler to plant sufficient
information to enable SDBG to operate, but specify that no checking code is to
In general, it is better to debug a program compiled with checks, but /DBREAK
and /DEBUG are very useful in the following cases:
When a problem does not manifest itself when the checks are enabled. Often this
is a consequence of a calculation being performed with undefined variables or
array elements and you are advised to compile the program using the /UNDEF
option before using SDBG.
When the program is just too large to fit in memory when compiled with checks.
When the program runs too slowly when compiled with checks.
Programs which are not checked may well overwrite themselves and/or the tables
which SDBG uses to interpret their behaviour. This can produce unpredictable