Xref: utzoo comp.lang.c:12207 comp.windows.misc:651
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!ig!agate!ucbvax!hplabs!pyramid!infmx!greggy
From: greggy@infmx.UUCP (greg yachuk)
Newsgroups: comp.lang.c,comp.windows.misc
Subject: Re: Mysteries of Microsoft Windows and C
Keywords: Microsoft, C, Windows, MSC, Bugs
Message-ID: <390@infmx.UUCP>
Date: 29 Aug 88 20:15:45 GMT
References: <7050@umn-cs.cs.umn.edu>
Reply-To: greggy@infmx.UUCP (greg yachuk)
Organization: Informix, Menlo Park, Ca. U.S.A.
Lines: 41

In article <7050@umn-cs.cs.umn.edu> kehyoe@umn-cs.cs.umn.edu (Ong Keh Yoe) writes:
> [ bunch of info about spawning and killing processes and files (yech) ]

Sorry, can't help you out on that stuff.

>What are the net's experiences using Codeview to debug Window applications
>written in Microsoft C ?

You cannot use Codeview to debug a Windows program (something about
competing for the screen was the pseudo-explanation that I got from MS).
You must use SYMDEB, with either a second monitor, or with a terminal
hanging from the COM1 port.  The documentation for Windows 1.04 gives
an example of using COM2, but this hangs the system.  I don't know if
they corrected it for 2.0x.  You MUST use COM1.

>	Fourth, is the Microsoft window programming environment a stable
>environment ?  Is it reliable ?  What are the best tools and methods
>of tackling strange errors ?  E.g. 
>		Using codeview, 

See above

>		Going into Window source (is this possible ?)

Not available (as far as I know)

>		Debugging at assembly level,

SYMDEB has a source (e.g. C) level mode

>		Setting some obscure debug flags on ?

You can use the Debugging version of the Windows Kernel.  It gives
stack tracebacks when things blow up, but I don't REALLY find it to
be that much use.

>							Keh Yoe
>							(the happy hacker)

Greg Yachuk		Informix Software Inc., Menlo Park, CA	(415) 322-4100
{uunet,pyramid}!infmx!greggy		why yes, I DID choose that login myself