Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!mcnc!rti!bcw From: bcw@rti.rti.org (Bruce Wright) Newsgroups: comp.windows.ms.programmer Subject: Re: Borland C++ 2.0 Summary: Debugging in a window, etc Message-ID: <1991Mar1.032721.20030@rti.rti.org> Date: 1 Mar 91 03:27:21 GMT References: <1991Feb28.173016.22964@leland.Stanford.EDU> Distribution: na Organization: Research Triangle Institute, RTP, NC Lines: 58 In article <1991Feb28.173016.22964@leland.Stanford.EDU>, aaron@jessica.stanford.edu (Aaron Wallace) writes: > In article <1991Feb28.030702.4105@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: > >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...) Umm. Maybe. But if you have a debugger which is running in a window on the screen, I don't see how it helps very much that GDI is talking to a standard VGA rather than to a super-VGA, for example. The problem is that if Windows runs out of handle space (for example), there's probably not a safe way to unjam the situation in _ANY_ display resolution. In other words, in this situation the problem is going to be with the Windows data structures, not with the code to support the screen itself. Hard to see how you can fix up the basic data structures when Windows is running on one screen and not when it's running on another. But it appears that the problem is completely different: I (and from some of the conversation on this thread, I suspect others as well) had assumed that the debugger was running in a _window_ like, for example, some of the debuggers for X-Windows systems. This is apparently not the case: In article , dsampson@x102a.harris-atd.com (sampson david 58163) writes: > When you fire up TD for W, it runs in full screen and looks like the > "regular" Turbo Debugger, that is it is rows and columns of text, not > a windows program with a main window etc. However, it definitely > debugs your windows code and let's you switch between your windows app > that's being debugged and the TD screen with a key-stroke (can't > remember if it was Alt-F5, or what). This explains what's going on - they solve the problem by taking over the _entire_ screen, therefore can't run in a window, therefore don't have to deal with GDI, etc. Or in other words, yes, in a sense they _did_ write their own drivers for the device, though not in the sense I thought they meant: it's apparently just a character-mode driver of some sort. And since the way you swap between character mode and super-VGA mode isn't completely standardized, I guess that may be the problem with supporting super-VGA resolutions in the debugger. Bruce C. Wright