-- Using dos.exe for debug purposes
There are two main cases in which you might need using dos.exe
1. If you want to look how S/DOS works you'll need only to run
dos.exe under, for example, Turbo Debugger or any other debugger that
allows viewing source lines being executed. Viewing source lines will
help you to understand better what's going on. (You will also have an
opportunity to inspect variables and see memory dumps.)

Note that dos.exe uses config.deb instead of config.pts as configuration
file.

2. Suppose you need watching how programs dealing with disks access
disk drivers (via DOS or directly); for example you would like to find out
how DataComp works.

If you, for example, simply run DiskEditor under Turbo Debugger you can
face a problem because TD accesses disks while running which results in
overwriting Device Request Header intended for DataComp with older request
headers describing TD requests (for DOS uses only one buffer for request
header ).

This problem can be solved using dos.exe. Run it under debugger and
install device driver using config.deb.In this case background  s/dos
(loaded at boottime ) will handle TD requests while all other processes
will execute in new operating environment (dos.exe under debugger ) so that
TD requests and requests to handle by DataComp will be separated.

You can also trace DataComp using source view if DC debug information
is imbedded into code.

-- How to invoke debugger from resident program
If you need to invoke debugger from resident program (for example in
the case described above) insert, for instance, int 3 call into source and
recompile program. After installing resident tell debugger to hook int 3
( almost all of debuggers do it by default). Debugger will take control
when resident program invokes int 3.
