CodeView: Difference between revisions

Revision as of 05:45, 13 October 2010

Revision as of 05:47, 13 October 2010

Line 4:

When running, CodeView would present the user with several [[window (computing)|windows]] that could be tiled, moved, and otherwise manipulated. Some of the windows were:

* Code window - the code window showed the currently debugged code in its [[source code]] context.

* Assembly window - the assembly (machine code) was displayed, allowing for single-stepping through functions.

* Data window - a hexadecimal dump of a user-specified memory area.

* Watch window - a contextual display of variables by name.

* Locals window - a contextual display of variables local to the current function.

* Command window - user commands (using the same or similar syntax as DEBUG.COM and [[symdeb]]) could be entered here.

* Assembly window - the assembly (machine code) was displayed, allowing for single-stepping through functions.

* Register window - to visualize the 80x86 register contents, including segments, flags and the FPU (CodeView existed before MMX and other SIMD extensions).

Creating symbollicsymbolic debugging output, which allowed memory locations to be viewed by their programmer-assigned name, along with a program database showing the source code line related to every computer instruction in the binary executable, was provided for by the command line switch -Zi given to the compiler, and -CO given to the linker. Variants with -Zs and -Zd provided lesser information, and smaller output files which, during the early 1990s, were important due to limited machine resources, such as memory and hard disk capacity. Many systems in those days had 8MB of memory or less.

CodeView supported all program models, including TINY, SMALL, COMPACT, MEDIUM, LARGE and HUGE, with TINY (DOS-based .COM files) having their symbolic debugger information stored in a separate file, with all of the other .EXE formats containing the symbolic information directly inside the executable. This often introduced a notable size increase, and it therefore became desirable for some developers to use #pragma switches within their C++ source code to prevent the majority of the application from having symbolic output, and instead limiting that output to only those portions which required it for current debugging.

Line 16 ⟶ 17:

CodeView version 3.x and more notably 4.x introduced various transport layers, which removed some of the memory space limitations to this form of symbolic debugging. Typically the debugger would run in the lower 640KB memory space alongside the application being debugged, which greatly decreased the amount of memory available to the application being debugged. The transport layer allowed only a stub to exist in main memory, while the bulk of the debugger code resided in EMS or XMS (memory above the 1MB barrier, or outside of the normal 0KB - 640KB address space typically used by DOS programs.

Microsoft released [[Visual C++]] 1.0 with CodeView CodeView functionality integrated directly into a single programming environment, known as the [[Integrated development environment|Integrated Development Environment]] (IDE) -- though CodeView was still available in the 16-bit versions of Visual C++. [[QuickC]] and a number of other development tools in the 'Quick' series also supported this move to a single-source IDE, what became the precursor to the modern Visual Studio developer environment, as well as the model for countless other developer toolsets.

This integration was seen by many developers as a more natural way of developing software because both coding and debugging could be handled without switching programs or context, and all from the same logical ___location (even though internally many separate programs were running to support editing, compiler and debugging).