Tutorial: Building a Debug Engine Using ATL COM
In this tutorial, you create a combination of interpreter and debug engine, although the interpreter part of the project does not actually do or interpret anything. However, Visual Studio still responds to a breakpoint being placed. You will end up being able to create a text file in Visual Studio, place a breakpoint on a line in that file, and then “run” the text file. This launches TextInterpreter, which stops on the set breakpoint. Continuing to “run” the text file causes TextInterpreter to exit (it responds only to the last breakpoint set).
In a typical implementation, the debug engine would be created in a separate module or DLL file from the interpreter being debugged. The debug engine would then call the interpreter to monitor and affect the progress of the interpreted program being debugged. In this circumstance, the debug engine would run in the same address space as the interpreter.
For compiled languages, the debug engine would use any available run-time mechanisms to monitor and affect the execution of the program being debugged. This is when the debug engine is running in the address space of Visual Studio.
For the TextInterpreter project, we combine the debug engine with the interpreter in a single module to simplify the tutorial.
The occasional note along the way will suggest other approaches that you might take for a particular problem. The approach below is by no means the only way or even the best way; it simply illustrates the basic ideas of creating a debug engine.