Today, the typical approach to software debugging and instrumentation requires changes to the application code or execution environment as illustrated below.

The application code approach involves inserting system outputs to the console window, embedding instrumentation code and/or building special interfaces to access data. Hence, this approach is classified as intrusive. Each of these methods requires special code which affects the execution and requires a recompile between iterations, consequently increasing development costs.

The execution environment approach involves inserting breakpoints into the application code to halt execution at a specified line of code. Hence, this approach is classified as intrusive. Once the execution is halted, variable watches can be set to view multiple variables. At this point execution can be single-stepped to the next line of code or continued to the next breakpoint. Most Integrated Development Environments (IDE) provide this debugging approach. Though this approach proves to be extremely powerful in simple, single-threaded, isolated applications, it becomes unusable when coupled threads and applications continue execution while a selected one was halted.

The memory space approach involves accessing memory via the Operating System (OS) independent of the application. Hence, this approach is classified as non-intrusive. There are products that monitor memory locations using variable names real-time with limited capability such as GNU Debugger (GDB) , and others that buffer data for post analysis such as Green Hills Software (GHS) Multi EventAnalyzer . However, only CodeEyes^TM provides the real-time, robust Graphical User Interface (GUI) to view application variables across simultaneous running applications on disparate execution environments using the native compiler symbol tables.