www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/02/04/06:58:45

Date: Thu, 4 Feb 1999 13:55:47 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Paul Derbyshire <pderbysh AT usa DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: Q: Forcing mode CO80
In-Reply-To: <3.0.6.32.19990204051602.008e4920@pop.netaddress.com>
Message-ID: <Pine.SUN.3.91.990204134831.7801X-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com

On Thu, 4 Feb 1999, Paul Derbyshire wrote:

> One question. How does one tell if the mode could not be set?

Either call get_mode right after setting it, or peek at the byte in the 
BIOS area that stores the mode.

> Your set_mode passes the ADDRESS of a struct to __dpmi_int(), so I'd guess
> that something in the struct is changed to reflect the error/success status
> of the function.

The __dpmi_regs struct returns with whatever the interrupt you called 
returned in the registers.  Since this particular function doesn't return 
neither the new mode nor an error indication, it doesn't help.  DOS 
functions set the carry flag and return error code in AX, so you can use 
that to detect errors.

> Or possibly checking the return code of __dpmi_int(), which is specified as
> returning an int.

If __dpmi_int itself returns a non-zero value, it means that there was 
some error in issuing the DPMI call that it uses to invoke real-mode 
services, such as the video BIOS interrupt 10h.  But it doesn't tell 
anything about whether the invoked service failed.  You should indeed 
check the return value of __dpmi_int to be on the safe side, but it is a 
very rare phenomenon that it fails.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019