www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/02/08/15:12:27

Date: Tue, 8 Feb 94 14:44:06 -0500
From: DJ Delorie <dj AT ctron DOT com>
To: ghogenso AT mammoth DOT chem DOT washington DOT edu
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Unsupported Ints

> Would it be a problem to actually have DJGPP say something to this
> effect whenever an 'unsupported interrupt' message comes up, or perhaps

I can't think of anything better to say than "unsupported interrupt",
which it already says.

> a warning when 'int86' is used?  Or are there some situations where
> you would still want to use int86 rather than the go32 simulation?

Portability.  Borland and MSC don't have _go32_*.

> If not, why support int86 at all?  If the issue is "under VCPI, use
> int86, under DPMI, use go32_dpmi_simulate_int", then why not have a function
> which automatically calls the appropriate one?

_go32_dpmi_simulate_int *always* works, regardless of mode.  int86()
*always* works for those requests that go32 knows about.

> I really think this sort of thing should be transparent to the user
> who doesn't wish to mind about whether he/she's running under DPMI or VCPI.

Neither function operates differently based on run mode.

> This would aid a lot in portability of code, would it not?  No need to

> #define int86 go32_dpmi_simulate_int.

There's never a need to do this, and it wouldn't work anyway.  The
parameters are different.


- Raw text -


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