From: Sterten AT aol DOT com
Message-ID: <104.656927c.28899a58@aol.com>
Date: Fri, 20 Jul 2001 10:29:44 EDT
Subject: Re: pokeb peekb
To: dj AT delorie DOT com
CC: djgpp AT delorie DOT com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 3.0 16-bit for Windows sub 60
Reply-To: djgpp AT delorie DOT com

me:
 >> #include<go32.h> 
 >> int main() { // gcc video3.c -o video3.exe 
 >> _farpokeb(_dos_ds,0xb8000+12*160+40*2,1);}
 >> 
 >> compiles and runs fine. (gcc2.03)

DJ Delorie:
 >If you run it on my old laptop it will fail, because my laptop has a
 >monochrome screen (0xb0000).  It will fail on my newer laptop because
 >the screen is not 80x25 cells.  It will fail if the center cell has a
 >black-on-black attribute already (or any other same-on-same

yes, I'm aware of this. I did have this b000 vs. b800 problem with older
cards. I checked this by calling int 16 with ah=15  in assembly.

 >attribute).  Just because it happens to run on your machine does not
 >mean you have learned a proper and useful technique.

it does. Once you know how to do it on one system , it's easier
to do the same on another system or to make it work on many systems
simultaneously.

 >If your purpose is to do graphics programming, then you are learning
 >the wrong techniques anyway.  You want to learn about the _farns*
 >functions and nearptrs, or use Allegro (which hides the hardware
 >layer, allowing you more than 640x480 without having to know what kind
 >of card you're using) or GRX.  *Especially* if you're teaching people
 >how to program!  Give them a high-level library like Allegro and
 >they'll see better results faster, which will encourage them to
 >continue.
 >
 >See also http://www.delorie.com/djgpp/doc/ug/ which has a chapter on
 >graphics programming for DJGPP.

maybe later. ATM other things are more important to learn for me.
You won't start with the heavy stuff . First do some easy things
and enjoy the little successes , then slowly advance and extend.
At this point I'm not sure , whether I will ever need that
Allegro etc. 
Probably it takes many hours , before I understand it and will be
able to use it.

 >As for general C, you should get in the habit of adding spaces and
 >sparsely populated lines (appropriately, of course) to make your
 >program more readable .

I tend to disagree (although that might change once I know 
more about DJGPP)
Why should I deliberately add spaces and sparsely
populated lines ? They only make the program larger.
I can't see why it should increase readability.
I prefer compact programs which fit on one printed page
or monitor page  rather than wandering through many pages ,
when trying to find a function or just finding the "}" 
corresponding to the "{" some hundred lines below.

 > (DJGPP's indent tool can do this for you). {einruecken

I couldn't find it. So I can write short code and "indent"
makes it more readable for people like you ? That's fine.
Is there also an unindent-tool , which compresses sparse lines ?

 >This is especially important if you want someone else to read your code
 >to help you solve a problem.

maybe some (most ?) people think so.
But when I see long programs, I become discouraged.

 >Before:
 >
 >int main() { // gcc video3.c -o video3.exe 
 >_farpokeb(_dos_ds,0xb8000+12*160+40*2,1);}
 >
 >After:
 >
 >int
 >main ()
 >{
 >  // gcc video3.c -o video3.exe 
 >  _farpokeb (_dos_ds, 0xb8000 + 12 * 160 + 40 * 2, 1);
 >}
 >
 >You should get in the habit of returning a valid exit code, either by
 >calling exit() with a suitable value (zero for success, nonzero for
 >failure) or returning a suitable value from main (rather than just
 >falling off the end as you do).

because this is transmitted to DOS , I assume (?)
I never used this return code in DOS-programs ,
but OK, it could be useful.


Guenter