Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!rtech!markh
From: markh@rtech.rtech.com (Mark Hanner)
Newsgroups: comp.windows.ms
Subject: Re: Debugging Windows
Message-ID: <3252@rtech.rtech.com>
Date: 30 Jul 89 20:45:07 GMT
References: <30097@ucbvax.BERKELEY.EDU> <106580054@hpcvlx.HP.COM> <3239@rtech.rtech.com> <8850@june.cs.washington.edu>
Reply-To: markh@rtech.UUCP (Mark Hanner)
Organization: Relational Technology Inc, Alameda CA
Lines: 65

In article <8850@june.cs.washington.edu> roper@june.cs.washington.edu (Michael Roper) writes:
>[I asked for an example of why one would be forced to write code 
>that was video device-specific.]
>Mark Hanner writes:
>> Certainly once you get [the mapping modes] set up and parameterize 
>> all your code, you have a nice virtual device interface, but its 
>> more code you have to write where bugs can develop. 
>
>> It is also  all too easy to hack in hard codings that work fine on 
>> a 640x450 but produce unpredictable results on 800x600 and forget 
>> about them. 
>
>This again, is a different issue.  The point here seems to be that
>writing parameterized code is harder than writing single-case code 
>or that writing poor code is easier than writing good code.  Obviously, 
>you'll not find many that disagree.  However, your original assertion 
>was that one was -forced- to write different code for different 
>displays.  I still haven't seen an example of this.  Which is not 
>to say there aren't some, there are.  But I don't believe it is a 
>damning problem (and will be improved in 3.0).

"Please do not misundertake me, please..." what i really meant was
that you are *forced* to write *parameterized code* if you're going to work
in windows. You *can* get away with hacks in DOS (code to MONO or CGA spec and 
do nothing fancy, and the Microsoft C libraries perform magic for you); 
those who wish to move to windows are going to have to relearn programming 
the "right" way. I admit to being a "recovering hacker," and am no longer 
writing:
	
	#define XWINSIZE	200
	...

		CreateWindow(xxx,XWINSIZE,...

but rather:

	int	screensize;
	int	xwinsize;
	...

		screensize  = GetSystemMetrics(SM_CXSCREEN);
		xwinsize = screensize/2;
		CreateWindow(...,xwinsize,...)

		/* then more mumbo jumbo below to set up map modes and text 
		 * metrics to make sure that things fit into whatever xwinsize
		 * happens to be...
		 */

Power comes at the expense of complexity. I would agree that its easier to 
write code for different devices, etc. in windows than in DOS, but you do
have to make an investment in it to get the return. I'm now building a 
library to hide away this stuff away from the rest of my code, but I had
to write it myself. Like I mentioned in my previous posting, I'd really like
a higher level interface. [On the suggestion of Actor from Ken at Microsoft:
I think Actor is heading in the right direction, but it's only the first 
generation...]

cheers,
mark

-- 
markh@rtech.COM
"Crass generalizations may be justified by admitting 10 exceptions."
			-- marnie applegate