Test the final version of your applicationThe Windows 3.1 SDK provides two environments for debugging or testing your Windows applications: a debugging version of the retail Windows product and a nondebugging version of the retail Windows product.
The SDK installation program creates two directories to contain the debugging and nondebugging versions of the core DLLs. Unless you specify different paths, Install places the debugging versions of the Windows core libraries in the directory \WINDEV\DEBUG and the nondebugging versions in the directory \WINDEV\NODEBUG. Install copies the nondebugging version of the Windows core libraries from your Windows system directory to the \WINDEV\NODEBUG directory.
You can conveniently switch between the debugging and nondebugging versions of Windows by running one of two batch files that Install places in the Windows development directory (named \WINDEV by default). The N2D.BAT file switches from the nondebugging to the debugging version, and D2N.BAT switches from the debugging to the nondebugging version.
These batch files either copy files from the directories \WINDEV\DEBUG and \WINDEV\NODEBUG or rename files in your Windows system directory. When you install the SDK files, Install asks if you want to keep a duplicate set of the libraries and symbol files in your Windows system directory. If you answer Yes, N2D.BAT and D2N.BAT quickly rename the duplicate files. Otherwise, the batch files copy the DLLs to your Windows system directory from the appropriate directory.
If you choose to retain a duplicate set of files, the DLLs and symbol files for the two versions of Windows appear in your Windows system directory with the same names as the core libraries and symbol files, but with the letter N (nondebugging) or D (debugging) appended to the name. For example, in addition to the GDI.EXE file, your system directory will contain the GDID.EXE and GDIN.EXE files.
The debugging version of Windows consists of a set of DLLs that replace the Windows core DLLs of the retail product. The replaced DLLs are USER.EXE, KRNL286.EXE, KRNL386.EXE, GDI.EXE, and MMSYSTEM.DLL. Accompanying these DLLs is a set of symbol (.SYM) files.
The debugging versions of the core DLLs provide error checking and diagnostic messages that help you debug a Windows application. The symbol-file information helps you track calls into Windows when using the Microsoft Windows 80386 Debugger (WDEB386.EXE). In addition, the debugging versions of these DLLs contain MicrosoftÒ CodeViewÒ symbol information for tracking calls into Windows when using MicrosoftÒ CodeViewÒ for WindowsÔ (CVW).
A special setting is available in the [386Enh] section of SYSTEM.INI for the debugging version of Windows. The form of this setting follows:
DebugPhysAddrs = {TRUE|FALSE}By default, Windows makes the entire base physical linear memory region available when a debugger is loaded. Setting the DebugPhysAddrs option to FALSE overrides this default when the debugger is loaded. Although the FALSE setting prevents you from being able to examine all memory, it creates a memory environment more like the nondebugging version of Windows, which can help you spot problems with pointers more quickly. The default value for DebugPhysAddrs is TRUE.
During application development, you should use the debugging version of Windows. However, use the nondebugging version of Windows whenever you want to do the following:
Test the final version of your application
Test the performance of your application without the performance disadvantages of the debugging version of Windows
Use the nondebugging version of Windows with the core DLLs supplied by the retail version of Windows. The Windows 3.1 SDK also provides symbol files for the nondebugging version of Windows. The retail Windows core libraries do not contain CodeView symbol information, however.