Mail Archives: djgpp/2001/07/20/10:41:04
> 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.
DJGPP already sets ScreenPrimary to the right value; you don't need to
cause yet another mode switch for it.
> >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.
Hard coding screen location and size isn't the right way to make it
work on multiple machines. Using the Screen* functions is.
> 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.
Trying to figure out how to directly access the PC hardware is not
"some easy things". Allegro hides all the hardware details for you;
doing something *right* with Allegro is easier than doing it *right*
on your own.
> Why should I deliberately add spaces and sparsely
> populated lines ? They only make the program larger.
They make it easier to read. If you ask for help, you should make it
easy for people to help you.
> I can't see why it should increase readability.
I'm sorry to hear that. Me, I like to have one line per statement,
with matching braces indented the same and lexical blocks indented, so
that the layout of the program provides visual clues as to is
functionality.
Please see http://www.ioccc.org/ for examples of how badly code
formatting alone can make a program unreadable.
> > (DJGPP's indent tool can do this for you). {einruecken
>
> I couldn't find it.
v2gnu/ind225b.zip on any simtel mirror. Or look in 00_index.txt:
ind225b.zip B 137,558 000425 GNU indent 2.2.5 for DJGPP V2
> So I can write short code and "indent"
> makes it more readable for people like you ? That's fine.
The idea is that it makes it more readable for *you* also.
> Is there also an unindent-tool , which compresses sparse lines ?
No. Try paragraph-fill in your favorite word processor. It's rare to
find a seasoned programmer that wants their code formatted so
compactly.
> >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.
It's not the length of the program, it's the complexity of the
formatting.
> >You should get in the habit of returning a valid exit code...
>
> because this is transmitted to DOS , I assume (?)
Yes, or whichever program ran your program (command.com by default).
> I never used this return code in DOS-programs ,
> but OK, it could be useful.
For a dos-related example, any program that you expect `make' to run
*must* return a valid error code, as make uses those to decide if it
should continue running commands or not.
- Raw text -