X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Rod Pemberton" <dont_have AT bitbucket DOT cmm>
Newsgroups: comp.os.msdos.djgpp
References: <43E12016 DOT 2070308 AT mainstreetsoftworks DOT com> <7t88b3-d2q DOT ln1 AT news DOT infowest DOT com> <43E1863D DOT 8080308 AT mainstreetsoftworks DOT com> <fgt8b3-c4u DOT ln1 AT news DOT infowest DOT com> <43E216B4 DOT 70509 AT mainstreetsoftworks DOT com> <43E243F8 DOT 7060401 AT mainstreetsoftworks DOT com> <1o8ab3-2i71 DOT ln1 AT news DOT infowest DOT com> <k2qab3-d7b1 DOT ln1 AT news DOT infowest DOT com> <43E2C6DA DOT 4080700 AT mainstreetsoftworks DOT com>
Subject: Re: TSR issues (with code)
Lines: 77
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-IWN-Posted-By: [68.60.59.250] Fri Feb  3 00:17:56 2006
Message-ID: <4mcbb3-q1f1.ln1@news.infowest.com>
X-Complaints-To: abuse AT eli DOT net
X-Trace: 52616e646f6d49564b835516cab6b1f728cd0aaad111e06a2859ca5fe614c2a3fdb4d17c804a296421caf04f2ab9f8217b417d482fcbb552089ca82b80bb481345affa41c76a04563e4586d15fac227105e57dd48ffbeb340ad56674301783bd215427609dff2e350be87ac7df8ec94ab6fff26fc17b2a4201b5b27a826390d2754dc046059d86d96e4e246b08dc41fa
X-Abuse-Info: Please be sure to forward ALL headers so that we may process your complaint properly.
NNTP-Posting-Date: Fri, 03 Feb 2006 07:29:42 UTC
Date: Fri, 03 Feb 2006 07:46:57 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


"Brad House" <brad AT mainstreetsoftworks DOT com> wrote in message
news:43E2C6DA DOT 4080700 AT mainstreetsoftworks DOT com...
> Wow, thanks for the insight.  Actually, I think what I posted
> actually hooks 0x1c instead of 0x08

I thought you had it named properly. :-)  int 0x08 calls int 0x1c...

> maybe PMODETSR reflects 0x08 but not 0x1c...

The assumption on my end is it is not reflecting whichever one your program
uses. :-)

> 0x28 from realmode to protected mode, all I see that doing is
> improving latency since my app wouldn't execute while the

Speed is good.

> Also, on reflection, how would I go about doing that? Can that
> be done within one app, or does the DPMI need to be hacked ?

No you'll be using code like these snippets (not in a useable order):
__dpmi_raddr old_handler, new_handler;
__dpmi_regs *r;
  r->x.cs = old_handler.segment;
  r->x.ip = old_handler.offset16;
__dpmi_get_real_mode_interrupt_vector(0x21, &old_handler);
__dpmi_set_real_mode_interrupt_vector(0x21, &new_handler);
__dpmi_allocate_real_mode_callback(int_handler, r, &new_handler);

If you have future plans to use OpenWATCOM, make sure you only use the _dpmi
functions don't use any of the _go32 functions since there is no way to
convert some of the _go32 functions to regular _dpmi functions.

> Btw, dosmemget() doesn't call an interrupt, does it?

No interrupt.  dosmemget calls movedata, they are in dmg.c and md.S
respectively.  dosmemget moves between _dos_ds and _my_ds() selectors.

I haven't confirmed this, but I think the following are interrupt free: the
main C compiler (constants, variables, integer arithmetic, flow control and
procedures), memxxx(), isxxx(), strxxx(), scanf, sprintf, etc.  Basically, I
think anything that you can do without the libraries, or memory only
functions, or character only functions should be interrupt clean.  Any
functions which call fileio will most likely call an interrupt, including
some you wouldn't expect at first, like printf().

Darn, I'm going to sound arrogant here, this is a lesson on how to 'think'
about PM DPMI applications:
Basically, you are switching between two "OS's" which are completely
separate.  That includes interrupt tables.  Those two "OS's" are  "RM BIOS &
DOS" and "PM DPMI."  Of course, RM BIOS & DOS is fairly functional.  But, PM
DPMI only has a stripped down memory manager (the DPMI calls), no actual
operating system.  So, to do anything useful, you must switch back and forth
to RM, calling DOS or BIOS as necessary.  Some of this is handled by the
DPMI host and/or DOS-extender.  Some is handled by the C libraries.
Everything else isn't.  Some RM interrupts are also supposed to trigger the
same PM interrupt per the DPMI specs.  Most don't.  This is called
'reflection' which is done via a 'real mode callback'.  When a decent number
of PM interrupts are setup to trigger the same RM interrupt, it's called a
DOS-extender.  Now, your program is running in PM, so when DOS or BIOS calls
int 0x08, int 0x1c, or int 0x21 this is in RM and your PM program is
'unaware' of it.  If the interrupt isn't reflected by the DPMI host, you can
'reflect' it using a 'real mode callback'.  The 'real mode callback'
switches from RM to PM and calls a PM routine you specify and then switches
back to RM from PM.  It's a wrapper around your routine which handles the
PM/RM or "OS" switching.  If you set a RM interrupt vector to point to a
real mode callback which points to a routine in your PM code,  your PM
application is getting RM interrupts via reflection.


Rod Pemberton