Date:	Thu, 18 Feb 1999 10:03:02 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	John Scott Kjellman <jkjellman AT ameritech DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: How to check the carry flag? (long)
In-Reply-To:	<36CAE539.FD86039A@ameritech.net>
Message-ID:	<Pine.SUN.3.91.990218100210.3649D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

On Wed, 17 Feb 1999, John Scott Kjellman wrote:

> Thanks for the reply.  Before I say (type? ;-) anything else, I
> would like to take a moment to say thanks for all the help you have
> given me and the hundreds (thousands?) of people in the new groups.

You-all are welcome.

> Please let me know what to change and where and I'll take care of it at this
> end.

I will post a patched source, once I make up my mind how to fix it
best.  You will have to compile it and put it into your libc with two
simple commands.

> I have
> noticed that the BIOS ignores break codes (it never does anything when you
> release a key)

It does pay attaention to break codes, at least for the Shift/Ctrl/Alt
keys.

> Since the BIOS code is
> written for a standard PC keyboard, it may just look for values
> below 0x80 for processing.  I have had pretty good luck sending
> 0x80, but in some versions of the Phoenix BIOS this causes it to
> send something to the keyboard that is erroneous.

No, don't send 0x80, send 0 both as make and as break code.  Zero
should be always ignored.

> Come to think of it I
> do remember (vaguely ;-) something about not changing the flags in the DPMI
> register structure in an int handler.  It had something to do with
> setting a bad SP, CS or DS, can't remember which...

I'm not aware of any such requirements.  AFAIK, the flags have nothing
to do with the registers.  You might be mixing this with the
requirement to zero out the SS, SP, and FLAGS fields of the registers'
structure when you call _go32_dpmi_simulate_int function (__dpmi_int
does that for you), but that's an entirely different matter.

> This maybe why the wrapper does this.

Actually, a discussion with DJGPP developers seems to indicate that
this is simply an omission, albeit one that has been there dormant for
a very long time.

> Is there a way I can *not* use the wrapper code?

You can always write your own wrapper.  The sources are free to look
at and hack around.  Download djlsr202.zip and look for the file named
gormcb.c in the src/libc/go32 directory.  Read the relevant parts of
the DPMI spec for filling in the blanks.  It's no rocket science.

> Thanks for your help

IMHO, there's a lesson to be learned here, and it is that any such 
problems should be reported, because even code as old as this one can 
have bugs.

- Raw text -