Chapter 3. Debugging
Faulty
code has been with us since the dawn of computing. The first
general-purpose stored-program computer to become fully operational
was the EDSAC,[1] built at
England's University of Cambridge. Maurice Wilkes
was in charge of this project and recalls that while writing the
computer's first real application,
"the realization came over me with full force that a
good part of the remainder of my life was going to be spent in
finding errors in my own programs." If his 126-line
program running within the confines of the EDSAC's
2-kilobyte memory capacity proved so difficult to debug, then what
hope can there be for modern computer systems, which are many orders
of magnitude more complex? Fortunately, debugging technology has
improved since the 1940s.[1] ENIAC was completed first, but unlike
all modern computers, it was unable to execute code out of its own
storageprograms were quite literally hardwired. The Manchester
Baby was the first computer with a
"stored-program" facility ever to
execute a program, but EDSAC was the first to execute production code
for real applications.
Visual Studio .NET moves the state of the art of debugging forward.
As you would expect, it provides all of the features we now consider
mandatory in a debugging toolsource-level debugging,
single-stepping, breakpoints, and variable watches. It also has many
new and powerful features. Multiprocess and multihost applications
can now be debugged from a single session. Multilanguage projects are
supported. A single debugging session can deal seamlessly with code
written in radically different technologies such as managed code,
native code, and T-SQL. Web applications can now be debugged with
ease.