I want to write a DPMI compliant driver that can run in DOS, without
Windows being loaded, that allows this.
#1. Do QEMM, 386MAX, and other DPMI servers, by default, place the chip
in V86 while running DOS? I noticed in the DPMI 0.9 spec that this is
only an OPTION for DPMI servers, but they can also run in real mode. If
they do run in V86, then certainly it is possible to trap the exception
caused by a write to a port.
#2. How do I set the I/O map for the V86 session in a way that DPMI
allows?
#3. Does a decent API or SDK exist for DOS DPMI development?
Preferably free?
#4. Is VCPI an option for me?
Basically, I want to virtualize some hardware unbeknownst to DOS
programs.
Any suggestions?
I would appreciate any help I can get.
Eric Lange
er...@emu.com
On Wed, 4 Jun 1997, Eric Lange wrote:
> I want to trap writes to certain or all I/O ports. I know that the 386
> and up supports this in a V86 session with the I/O map and permission
> bits in the TSS. I also know that Windows provides this functionality
> with a nice handy VMM call.
>
> I want to write a DPMI compliant driver that can run in DOS, without
> Windows being loaded, that allows this.
I might be wrong here, but I think you can't, because your program
runs in ring 3, and only a ring-0 task can get the exceptions due to
priviledged calls. Charles?
> #3. Does a decent API or SDK exist for DOS DPMI development?
What's wrong with the DPMI calls in DJGPP's library? What kind of SDK
do you have in mind?
> #4. Is VCPI an option for me?
You mean, to roll your own DOS extender? Sure' that's an option; but
the amount of work...
In V86 16-bit mode, or in 32-bit protected mode?
> I want to write a DPMI compliant driver that can run in DOS, without
> Windows being loaded, that allows this.
If you just want this behavior in 32-bit protected mode, you can easily
hack this into CWSDPMI by modifying the TSS length, values, and IOPL.
> #1. Do QEMM, 386MAX, and other DPMI servers, by default, place the chip
> in V86 while running DOS?
If you have an EMM present, you will almost always run in V86 mode. Since
QEMM and 386MAX are EMM providers, you end up in V86 mode, yes. But I don't
think you have access to the V86 control structures to allow you to
mess with the IO permissions or capture the exceptions.
> I noticed in the DPMI 0.9 spec that this is
> only an OPTION for DPMI servers, but they can also run in real mode.
CWSDPMI actually does BOTH. If you are running under HIMEM (or bare)
CWSDPMI will leave the machine in real mode when running DOS (since I
didn't want to bother writing a V86 monitor). If you are running under
an EMM, CWSDPMI uses the V86 provided.
> #2. How do I set the I/O map for the V86 session in a way that DPMI
> allows?
You can't. This is a very low level function (below DPMI).
> Basically, I want to virtualize some hardware unbeknownst to DOS programs.
Check comp.lang.asm.x86 (if you can tolerate the flamewars) - I have seen
some custom V86 monitor urls posted there which allow you to watch ports.
People use them to reverse engineer what's happening on dongle writes to
LPT ports, etc.
There must be some way to do it. DesqView has to do it for disk drive
access or separate DOS sessions would walk all over eachother. And,
DesqView simply sits atop QEMM.
>> #3. Does a decent API or SDK exist for DOS DPMI development?
>
>What's wrong with the DPMI calls in DJGPP's library? What kind of SDK
>do you have in mind?
>
Well, I have to come clean. I simply did a search for DPMI in the usenet
groups and this one came up. I have no idea what DJGPP is. It just seemed
like a place where people asked intelligent questions. What is it, and how
can I get ahold of it?
>> #4. Is VCPI an option for me?
>
>You mean, to roll your own DOS extender? Sure' that's an option; but
>the amount of work...
>
I'm not sure what I mean. I just want this to peacefully coexist with
DPMI/VCPI/EMM, etc. compliant DOS programs.
>On Wed, 4 Jun 1997, Eric Lange wrote:
>
>> I want to trap writes to certain or all I/O ports. I know that the 386
>> and up supports this in a V86 session with the I/O map and permission
>> bits in the TSS. I also know that Windows provides this functionality
>> with a nice handy VMM call.
>>
>> I want to write a DPMI compliant driver that can run in DOS, without
>> Windows being loaded, that allows this.
>>
>> #1. Do QEMM, 386MAX, and other DPMI servers, by default, place the chip
>> in V86 while running DOS? I noticed in the DPMI 0.9 spec that this is
>> only an OPTION for DPMI servers, but they can also run in real mode. If
>> they do run in V86, then certainly it is possible to trap the exception
>> caused by a write to a port.
>>
>> #2. How do I set the I/O map for the V86 session in a way that DPMI
>> allows?
>>
>> #3. Does a decent API or SDK exist for DOS DPMI development?
>> Preferably free?
>>
>> #4. Is VCPI an option for me?
>>
>> Basically, I want to virtualize some hardware unbeknownst to DOS
>> programs.
>>
QEMM has special hooks for DesqView. And DesqView handles most of the
conflicts via interrupt tables, not port access. It's not a trivial
problem. You need the source to the V86 monitor.
> I'm not sure what I mean. I just want this to peacefully coexist with
> DPMI/VCPI/EMM, etc. compliant DOS programs.
It probably can't, unless you plan to write a full EMM386 replacement.
You might check the not-yet-finished EMM386 stuff for freedos, or some
of the linux source, but this will not be a quick project. If it is
fully EMM/VCPI compliant it should work with software such as CWSDPMI
which lives on top of it.
See my post to the newgroup on more ugly details.
On Thu, 5 Jun 1997, Eric W. Lange wrote:
> Well, I have to come clean. I simply did a search for DPMI in the usenet
> groups and this one came up. I have no idea what DJGPP is. It just seemed
> like a place where people asked intelligent questions. What is it, and how
> can I get ahold of it?
To read about DJGPP: http://www.delorie.com/djgpp/
To download it: ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2/
(begin with the file `readme.1st' there).