Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!blake!ano
From: ano@blake.acs.washington.edu (John Michael Ano)
Newsgroups: comp.windows.ms
Subject: Re: Debugging Windows
Message-ID: <2948@blake.acs.washington.edu>
Date: 26 Jul 89 19:04:02 GMT
References: <30097@ucbvax.BERKELEY.EDU> <106580054@hpcvlx.HP.COM> <3229@rtech.rtech.com> <8804@june.cs.washington.edu>
Reply-To: ano@blake.acs.washington.edu (John Michael Ano)
Organization: University of Washington, Seattle
Lines: 22

This posting is in response to Michael Roper's request for some discussion
of development tools in a Windows environment.  I am not a professional 
programmer, but I hope the following comments prove useful.

First of all, CodeView is nice, only if you have a dual-monitor system.
For people developing apps on a PS/2 system, this can be a pain (as one
other poster has mentioned), as one would imagine the supply of Micro
Channel display adaptors is small and the price tag large.  I called the
Microsoft support line and found out how to do screen switching on one
monitor (/S switch in cvw), but when I tried it, any mouse movement on
the CodeView screen caused the display to freeze up.  I had to resort to
toggling the screen switch to clean up the display, redraw the CodeView display with the @ command, and then continue with my trace..  Is it that difficult
to have a debugger switch between the run-time screen and the debug screen?

Spy has proved invaluable, and in many of my debugging sessions, simply using
message boxes to show the contents of variables and pointers has helped.
I haven't tried symdeb, but I think rather than try it, I'll wait for a
better debugger to hit the market.  If I could spec the next version of
CodeView for Windows, I'd give it better screen switching capabilities.

John Ano
Dept. Psychology, University of Washington.