Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.djgpp > #1744 > unrolled thread

resident service providers

Back to article view | Back to comp.os.msdos.djgpp

Contents

  resident service providers "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 16:31 -0500
    Re: resident service providers Martin Str|mberg <ams@dexter.ludd.ltu.se> - 2014-02-21 08:17 +0000
      Re: resident service providers "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-21 10:55 -0500
        Re: resident service providers Louis Santillan <lpsantil@gmail.com> - 2014-02-21 08:39 -0800
          Re: resident service providers "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-21 15:19 -0500
            Re: resident service providers "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-03 18:59 -0500
        Re: resident service providers JJ <duh@nah.meh> - 2014-02-22 04:40 +0700
        Re: resident service providers Martin Str|mberg <ams@dexter.ludd.luth.se> - 2014-02-24 09:53 +0000
    Re: resident service providers "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-03 19:00 -0500

#1744 — resident service providers

Other than the DPMI 1.0 specification, what information is available online
regarding coding resident service providers, and/or DPMI enabled TSRs?

What I really need to know is how to code a resident service provider
(DPMI enabled TSR) for a DPMI 0.9 host which doesn't support the two
DPMI TSR calls (0c00h, 0c01h) that DPMI 1.0 supports.

I'm also interested in information on DOS device drivers which use DPMI
or 32-bit PM.


Rod Pemberton

[toc] | [next] | [standalone]

#1745

In comp.os.msdos.djgpp Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote:
> What I really need to know is how to code a resident service provider
> (DPMI enabled TSR) for a DPMI 0.9 host which doesn't support the two
> DPMI TSR calls (0c00h, 0c01h) that DPMI 1.0 supports.

This isn't exactly what you want, but it should do that quickly and
easily: 
Take the source code from CWSDPMI and remove support for those two TSR
calls and recompile...


-- 
MartinS

[toc] | [prev] | [next] | [standalone]

#1746

On Fri, 21 Feb 2014 03:17:50 -0500, Martin Str|mberg  
<ams@dexter.ludd.ltu.se> wrote:
> In comp.os.msdos.djgpp Rod Pemberton <dont_use_email@xnohavenotit.cnm>  
> wrote:

>> What I really need to know is how to code a resident service provider
>> (DPMI enabled TSR) for a DPMI 0.9 host which doesn't support the two
>> DPMI TSR calls (0c00h, 0c01h) that DPMI 1.0 supports.
>
> This isn't exactly what you want, but it should do that quickly and
> easily:
> Take the source code from CWSDPMI and remove support for those two TSR
> calls and recompile...
>

What?!?!  It's not April 1st yet ...  And, I don't see a smiley.

DJGPP provides functions for calling those two DPMI 1.0 calls, but CWSDPMI
being mostly DPMI 0.9 doesn't implement those two calls.  So, I don't see
how removing two non-existant calls from the CWSDPMI source and recompiling
would help me quickly and easily ...  If you're saying it's a long, painful
path not worth traveling, that would've been clearer to simply say.


AIUI, CWSDPMI is DPMI 0.9 compliant with a few DPMI 1.0 calls and features.
But, CWSDPMI doesn't support the DPMI 1.0 TSR calls 0c00h and 0c01h.   
AFAIK,
eighteen other DPMI hosts don't support the DPMI 1.0 calls 0c00h and 0c01h
either.  Even DPMIONE which is almost DPMI 1.0 compliant doesn't support
0c00h and 0c01h.  I know there is probably another twenty DPMI hosts I
could check ...

The issue is I'd like to code a resident service provider.  That's a PM
TSR which uses DPMI to install PM interrupts.  The first issue is DPMI 1.0
specification provides for this via 0c00h and 0c01h calls.  However, I've
not been able to find a DPMI 1.0 host that supports 0c00h and 0c01h calls.
The second issue is DPMI 0.9 hosts don't have support for resident service
providers at all.  A handful of DPMI 0.9 hosts is what I need the resident
service provider to work with.

If I could code a test resident service provider for a DPMI 1.0 host which
supports 0c00h and 0c01h, it might help me figure out how to code one for
a DPMI 0.9 host which doesn't support 0c00h and 0c01h, or whether it's
even possible without needing to update each DPMI host.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1747

[Multipart message — attachments visible in raw view] — view raw

Does djgpptsr not give what you need? <
http://www.netgull.com/djgpp/current/v2tk/djgpptsr.zip>

-L

On Friday, February 21, 2014, Rod Pemberton <dont_use_email@xnohavenotit.cnm>
wrote:

> On Fri, 21 Feb 2014 03:17:50 -0500, Martin Str|mberg <
> ams@dexter.ludd.ltu.se> wrote:
>
>> In comp.os.msdos.djgpp Rod Pemberton <dont_use_email@xnohavenotit.cnm>
>> wrote:
>>
>
>  What I really need to know is how to code a resident service provider
>>> (DPMI enabled TSR) for a DPMI 0.9 host which doesn't support the two
>>> DPMI TSR calls (0c00h, 0c01h) that DPMI 1.0 supports.
>>>
>>
>> This isn't exactly what you want, but it should do that quickly and
>> easily:
>> Take the source code from CWSDPMI and remove support for those two TSR
>> calls and recompile...
>>
>>
> What?!?!  It's not April 1st yet ...  And, I don't see a smiley.
>
> DJGPP provides functions for calling those two DPMI 1.0 calls, but CWSDPMI
> being mostly DPMI 0.9 doesn't implement those two calls.  So, I don't see
> how removing two non-existant calls from the CWSDPMI source and recompiling
> would help me quickly and easily ...  If you're saying it's a long, painful
> path not worth traveling, that would've been clearer to simply say.
>
>
> AIUI, CWSDPMI is DPMI 0.9 compliant with a few DPMI 1.0 calls and features.
> But, CWSDPMI doesn't support the DPMI 1.0 TSR calls 0c00h and 0c01h.
>  AFAIK,
> eighteen other DPMI hosts don't support the DPMI 1.0 calls 0c00h and 0c01h
> either.  Even DPMIONE which is almost DPMI 1.0 compliant doesn't support
> 0c00h and 0c01h.  I know there is probably another twenty DPMI hosts I
> could check ...
>
> The issue is I'd like to code a resident service provider.  That's a PM
> TSR which uses DPMI to install PM interrupts.  The first issue is DPMI 1.0
> specification provides for this via 0c00h and 0c01h calls.  However, I've
> not been able to find a DPMI 1.0 host that supports 0c00h and 0c01h calls.
> The second issue is DPMI 0.9 hosts don't have support for resident service
> providers at all.  A handful of DPMI 0.9 hosts is what I need the resident
> service provider to work with.
>
> If I could code a test resident service provider for a DPMI 1.0 host which
> supports 0c00h and 0c01h, it might help me figure out how to code one for
> a DPMI 0.9 host which doesn't support 0c00h and 0c01h, or whether it's
> even possible without needing to update each DPMI host.
>
>
> Rod Pemberton
>

[toc] | [prev] | [next] | [standalone]

#1748

On Fri, 21 Feb 2014 11:39:39 -0500, Louis Santillan <lpsantil@gmail.com>  
wrote:

> Does djgpptsr not give what you need? <
>

Yes and no.  Yes, that may help me.  No, this was for assembly,
not for C.  Sorry, I mentioned that in a different thread.

Yes, one would think that 'djgpptsr' was all that is needed ...
  (Or, it's equivalent in assembly.)

So, that likely means I have an error in the assembly for the
PM TSR somewhere.

Thanks for reminding me of that TSR.  I might be able to use a
modified version of the DJGPP C TSR code to help me test.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1757

On Fri, 21 Feb 2014 15:19:42 -0500, Rod Pemberton  
<dont_use_email@xnohavenotit.cnm> wrote:

[from c.o.m.d. only replies to the thread]

> [...]
> So, that likely means I have an error in the assembly for the
> PM TSR somewhere.
>

Well, I made a few mistakes with the assembly PM TSR using DPMI:

1) I was switching to 32-bit PM when 16-bit PM was sufficient.

2) I used the DPMI's 16-bit PM CS for my interrupt's code selector.
I needed a 32-bit PM code selector for the interrupt.

3) I was attempting to stay resident by trapping Int 0x21, AH=4Ch
instead of calling the TSR interrupt ...  The TSR interrupt can be
called in PM and will be reflected to 16-bit RM.

Now, the TSR installs a PM interrupt.  I can call the PM interrupt.
However, I have an issue with exiting the interrupt.  An 'iret'
causes a stack fault in the DPMI host (CWSDPMI for DJGPP), while
a jump to the DPMI hosts original PM interrupt causes a reboot,
which is likely a triple fault.  This is probably covered in
the DPMI documentation somewhere.  But, the basics work!

> Thanks for reminding me of that TSR.  I might be able to use a
> modified version of the DJGPP C TSR code to help me test.
>

Well, I haven't used it yet.  I found TSR's in C with DJGPP to be
a pain some years ago and I haven't decided whether I want to
revisit the issue or not.  Of course, 16-bit DPMI in assembly
isn't exactly pleasant.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1749

On Fri, 21 Feb 2014 10:55:23 -0500, Rod Pemberton wrote:

> On Fri, 21 Feb 2014 03:17:50 -0500, Martin Str|mberg  
> <ams@dexter.ludd.ltu.se> wrote:
>> In comp.os.msdos.djgpp Rod Pemberton <dont_use_email@xnohavenotit.cnm>  
>> wrote:
> 
>>> What I really need to know is how to code a resident service provider
>>> (DPMI enabled TSR) for a DPMI 0.9 host which doesn't support the two
>>> DPMI TSR calls (0c00h, 0c01h) that DPMI 1.0 supports.
>>
>> This isn't exactly what you want, but it should do that quickly and
>> easily:
>> Take the source code from CWSDPMI and remove support for those two TSR
>> calls and recompile...
>>
> 
> What?!?!  It's not April 1st yet ...  And, I don't see a smiley.
> 
> DJGPP provides functions for calling those two DPMI 1.0 calls, but CWSDPMI
> being mostly DPMI 0.9 doesn't implement those two calls.  So, I don't see
> how removing two non-existant calls from the CWSDPMI source and recompiling
> would help me quickly and easily ...  If you're saying it's a long, painful
> path not worth traveling, that would've been clearer to simply say.
> 
> AIUI, CWSDPMI is DPMI 0.9 compliant with a few DPMI 1.0 calls and features.
> But, CWSDPMI doesn't support the DPMI 1.0 TSR calls 0c00h and 0c01h.   
> AFAIK,
> eighteen other DPMI hosts don't support the DPMI 1.0 calls 0c00h and 0c01h
> either.  Even DPMIONE which is almost DPMI 1.0 compliant doesn't support
> 0c00h and 0c01h.  I know there is probably another twenty DPMI hosts I
> could check ...
> 
> The issue is I'd like to code a resident service provider.  That's a PM
> TSR which uses DPMI to install PM interrupts.  The first issue is DPMI 1.0
> specification provides for this via 0c00h and 0c01h calls.  However, I've
> not been able to find a DPMI 1.0 host that supports 0c00h and 0c01h calls.
> The second issue is DPMI 0.9 hosts don't have support for resident service
> providers at all.  A handful of DPMI 0.9 hosts is what I need the resident
> service provider to work with.
> 
> If I could code a test resident service provider for a DPMI 1.0 host which
> supports 0c00h and 0c01h, it might help me figure out how to code one for
> a DPMI 0.9 host which doesn't support 0c00h and 0c01h, or whether it's
> even possible without needing to update each DPMI host.
> 
> Rod Pemberton

Implementing the DPMI TSR functions outside the DPMI host that has no TSR
support will depend on its client termination handling. Whether the host
perform client cleanups on DOS TSR call, or not. Without this knowledge, it
would be difficult to implement and to get consistent result between
different DPMI hosts.

If the DPMI host does client cleanups on DOS TSR call, implementation of
DPMI TSR functions will require the original Int 21h, since DPMI hosts hook
Int 21h for client termination handling. So, a small DOS TSR must be loaded
first, before the DPMI host is loaded, in order to save the original Int
21h, where it can be retrieved later by the DPMI TSR functions
implementation.

[toc] | [prev] | [next] | [standalone]

#1751

In comp.os.msdos.djgpp Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote:
> On Fri, 21 Feb 2014 03:17:50 -0500, Martin Str|mberg  
> <ams@dexter.ludd.ltu.se> wrote:
>> In comp.os.msdos.djgpp Rod Pemberton <dont_use_email@xnohavenotit.cnm>  
>> wrote:

>>> What I really need to know is how to code a resident service provider
>>> (DPMI enabled TSR) for a DPMI 0.9 host which doesn't support the two
>>> DPMI TSR calls (0c00h, 0c01h) that DPMI 1.0 supports.
>>
>> This isn't exactly what you want, but it should do that quickly and
>> easily:
>> Take the source code from CWSDPMI and remove support for those two TSR
>> calls and recompile...
>>

> What?!?!  It's not April 1st yet ...  And, I don't see a smiley.

Well I hope I entertained someone by this...

> DJGPP provides functions for calling those two DPMI 1.0 calls, but CWSDPMI
> being mostly DPMI 0.9 doesn't implement those two calls.  So, I don't see
> how removing two non-existant calls from the CWSDPMI source and recompiling
> would help me quickly and easily ...  If you're saying it's a long, painful
> path not worth traveling, that would've been clearer to simply say.

I misread/misunderstood you.

I thought you wanted a DPMI server which didn't implement 0c00h, 0c01h.
I got the impression that the ones that you have (like CWSDPMI) didn't
do what you wanted, thus they DID implement those calls (this is where
I went awry).


Now I see that you're in the client position and want to to code a TSR
in a DPMI 0.9 environment.

Sorry for any confusion I've caused.


Then it's not that simple. One way might be to add those support for
functions 0x0c00 and 0x0c01 to CWSDPMI.


-- 
MartinS

[toc] | [prev] | [next] | [standalone]

#1760

On Thu, 20 Feb 2014 16:31:42 -0500, Rod Pemberton  
<dont_use_email@xnohavenotit.cnm> wrote:

> Other than the DPMI 1.0 specification, what information is available
> online regarding coding resident service providers, and/or DPMI
> enabled TSRs?
>

I think the answer to my question is just a PM TSR that uses DPMI.  Sorry.

> I'm also interested in information on DOS device drivers which use DPMI
> or 32-bit PM.

It might still be useful to know about any books that cover this ...


Rod Pemberton

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.msdos.djgpp

csiph-web