billc@mirror.TMC.COM (Bill Callahan) (11/11/88)
Well, it's time to get the ball rolling for this newsgroup, so I will start
it with a question.
What experiences have people had with installing and using CodeView under
Windows? I have heard much hype, but no word from someone who has done it.
How did it go, and, what sort of machine and periperals did you use?
---------------------------------------------
Bill Callahan billc@mirror.TMC.COM
{mit-eddie, pyramid, wjh12, xait, datacube}!mirror!billcrich@se-sd.sandiego.ncr.com (Rich Hume) (11/15/88)
In article <19626@mirror.TMC.COM> billc@prism.TMC.COM (Bill Callahan) writes: > >Well, it's time to get the ball rolling for this newsgroup, so I will start >it with a question. > >What experiences have people had with installing and using CodeView under >Windows? I have heard much hype, but no word from someone who has done it. >How did it go, and, what sort of machine and periperals did you use? > >--------------------------------------------- Everyone here who is woring on Windows apps has the following setup: NCR 916 (16 mhz 80386) 4 meg. memory EGA adapter and monitor (NCR's & NEC Multisync, some of each) Mono adapter and monitor Microsoft mouse >= 70mb disk Some general observations about CodeView with the 2.1 SDK: 1) For small apps is great! I use it exclusively (since I got it) for little windows apps. 2) For our product(s) which consist of a set of relatively large windows apps (one of which managers the communications port, or a NetBIOS session) we have found CodeView too buggy to use. Real bummer. 3) We've also found that since we still need symdeb most of the time, we include both CodeView and sysmdeb information in the executables. Unfortunately, we can't include the source directory because mapsym can't handle it. This means that when we use codeview, we have to enter the entire path for the source which gets to be a real pain. I have a question: does anyone out there have their development machines LANed togther? We're trying with Token Ring and Novell's software, but there are still too many times when we have to reboot to free up the valuable memory. Rich Hume rich@sandiego.NCR.COM
billc@mirror.TMC.COM (Bill Callahan) (11/15/88)
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