Path: utzoo!attcan!uunet!husc6!bu-cs!mirror!billc
From: billc@mirror.TMC.COM (Bill Callahan)
Newsgroups: comp.windows.ms
Subject: Re: CodeView under new Windows
Message-ID: <19723@mirror.TMC.COM>
Date: 14 Nov 88 16:54:14 GMT
References: <19626@mirror.TMC.COM> <2269@PEDEV.Columbia.NCR.COM>
Reply-To: billc@prism.TMC.COM (Bill Callahan)
Organization: Mirror Systems, Cambridge Mass.
Lines: 30

In article <2269@PEDEV.Columbia.NCR.COM> rogerson@PEDEV.Columbia.NCR.COM () writes:
>	in the near future.  In the mean time what kind of routines and
>	utilities help with debugging Windows Apps?
>
	The only thing we really have is SymDeb (SYMbolic DEBugger.)  It is
	not very powerful and has some actual bugs.  Bascially with SymDeb,
	you can set breakpoints on routine names, get stack traces, examine
	registers and memory, unassemble and view source code.  That's about
	it.  You run it with the aid of an external monitor.

	It has several bugs, the worst of which we've dubbed "The Int 3
	error."  This occurs when you are stepping through a program on the
	assembly level and pop over to another code segment during a
	function call.  While away, Windows happens to swap or move the
	calling code segment.  When the function returns, SymDeb loses track
	of where you were, and you notice that the instruction that the
	machine repeatedly excutes is the INT3 that SymDeb put there.  You
	have to reboot at this point.  The way to avoid this bug is to
	relink your program with the code segment that you are afraid will
	move defined as FIXED.

	To tell you the truth, I've had better luck putting things into my
	code to do diagnostics than using SymDeb, though SymDeb is good for
	getting a general idea of what code to look at, via stack tracing or
	maybe stepping through.

---------------------------------------------

Bill Callahan			 billc@mirror.TMC.COM
		{mit-eddie, pyramid, wjh12, xait, datacube}!mirror!billc