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.
By compiling a program for immediate execution with the /BREAK option, for example:
FTN95 MYPROG /BREAK
Used in this way /BREAK implies the /CHECK and /LGO options.
By compiling the program with the /DBREAK option. This option is similar to the /BREAK option except that it does not imply the /CHECK option which causes the compiler to plant checking code.
By linking together one or more .OBJ files produced with /CHECK or /DEBUG options and executing the resultant .EXE file as follows.
You can also use /PROFILE on the FTN95 command line (see Profiling ).
For Win32 executables use SLINK and then type,
SDBG MYPROG
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 be planted.
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 results.