Xref: utzoo comp.os.msdos.programmer:3965 comp.windows.ms.programmer:1337 Path: utzoo!attcan!uunet!elroy.jpl.nasa.gov!decwrl!mcnc!rti!bcw From: bcw@rti.rti.org (Bruce Wright) Newsgroups: comp.os.msdos.programmer,comp.windows.ms.programmer Subject: Re: Borland C++ 2.0 Summary: Windows driver support Message-ID: <1991Feb28.030702.4105@rti.rti.org> Date: 28 Feb 91 03:07:02 GMT References: <5907@iron6.UUCP> Followup-To: comp.windows.ms.programmer Distribution: na Organization: Research Triangle Institute, RTP, NC Lines: 52 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? Windows does hide the low-level implementation details from a program, so if the program works on one display device it's likely to do something at least slightly useful on another display device rather than just die like some DOS apps that encounter display devices that they don't know how to deal with. Unfortunately that's not quite the same as device independence. It is quite possible for a Windows program to get hold of the _logical_ structure of the display device; in fact for advanced graphics it's practically essential. For example, Windows allows a program to be aware of the pixel (width, height, bit planes) and physical (width, height, aspect ratio) attributes of the display device; this allows you to write programs that can work great on one device and yet do inappropriate things on another (such as choosing the wrong size fonts or inappropriate sizes or aspect ratios for various objects, or relying on colors that don't exist, etc). This sort of thing can mean that although the program does _something_ on a display device for which it wasn't intended, it doesn't do something very _useful_. This isn't to say that that's the usual case with Windows programs; just that it's possible. Most Windows programs probably don't have problems like this, but the more sophisticated programs (graphically speaking, not necessarily sophisticated in other ways) are the ones that are more likely to be doing fancy things and are therefore more likely to have problems. And of course poorly-written programs of any level of sophistication will have more problems than well-written programs. Even Microsoft isn't immune: try running Reversi on a CGA-resolution screen sometime. 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. Bruce C. Wright