Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!shelby!leland.Stanford.EDU!jessica.stanford.edu!aaron From: aaron@jessica.stanford.edu (Aaron Wallace) Newsgroups: comp.windows.ms.programmer Subject: Re: Borland C++ 2.0 Message-ID: <1991Feb28.173016.22964@leland.Stanford.EDU> Date: 28 Feb 91 17:30:16 GMT References: <5907@iron6.UUCP> <1991Feb28.030702.4105@rti.rti.org> Sender: Aaron Wallace Distribution: na Organization: Academic Information Resources Lines: 39 In article <1991Feb28.030702.4105@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: >In article <5907@iron6.UUCP>, yeates@motcid.UUCP (Tony J Yeates) writes: >> dsampson@x102a.harris-atd.com (sampson david 58163) writes: >> > The windows debugger IS a windows >> >application, and YES!!! you can debug with only one monitor. However >> >they tell you in the manual that if you're using VGA, they support >> >standard VGA, not super or the psuedo 8514 resolution you can get with >> >the drivers floating around now. >> >> Pardon my ignorance, but I thought a major benefit of windows applications >> was that they used library routines which make them display-independent. >> (...or was the author refering to the DOS debugger?). Other windows >> applications seem to run on anything as long as it has a windows driver.. >> whats the deal with the debugger? > >Perhaps there are problems of this type with the debugger, or perhaps >they just don't want to commit themselves to fixing any problems at >this time because they haven't had the time to test it sufficiently >for their satisfaction. Or maybe they're replacing some of the low- >level drivers for the device and haven't written this one yet (shudder), >though offhand I don't see why that should be necessary. > On the subject of on-screen, windowed debuggers: Off hand I'd suspect the problem is as follows: say your program goes around creating a whole bunch of GDI objects and, by a bug, forgets to delete them. From experience, this is a good way to kill off Windows. Now, if the GDI heap is full when the debugger needs to be called up, it's hard to see how the debugger will get much on the screen. As for not supporting non-"normal" displays, perhaps it's because in the case of a bad crash it's not possible to tell Windows to kick into the right mode, and it would be very difficult for BOrland to support every Windows-compatible display separately. (It could call the display driver, but that assumes enough memory to load the .DLL...) I imagine it's for reasons similar to this that the Mac debugger switches to a full-screen text mode; it might not be able to do graphics if the bug is bad enough... But enough hypothesizing... Aaron Wallace