|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
In terms of the debugger architecture, a program:
Is a container for both a set of threads and a set of modules. A program has no single analogy in the Windows operating system.
A program is a kind of subprocess. For example, when you are debugging a Web site, a script can be seen as a program. While a script runs in the scripting engine process, independent of other scripts, it also has its own set of threads. A debug engine (DE) attaches to a program, and not to a process or a thread.
Can identify itself and the process it is running in, and can be attached to, be detached from, and describe the DE that created it, if any. A program can execute, stop, continue, and be terminated.
Can enumerate all its threads. A program can also supply its own disassembly stream, and can enumerate all the code contexts of a given document position.
Is represented by an IDebugProgram2 interface, created before the program is attached, or as part of the attach process, depending on the implementation. When a port enumerates the programs of a process, each program is created in accordance with a corresponding IDebugProgramNode2 interface passed as an argument to IDebugPortNotify2::AddProgramNode. While debug engines also create IDebugProgram2 interfaces to represent programs, these programs are not created in accordance with a program node. The IDebugProgramNode2 interfaces created by a DE are used for actual debugging, while those created by a port are used only for discovering which programs are running in a process.