Changing a DPMI host, but keeping the DOS extender

[Rod Pemberton]

The other day I had this thought:

"I wish I could keep this DPMI host's DOS extender,
but change it's DPMI host..."

That would be useful to me. The issue I'm seeing is that if I start a DPMI
host with a DOS extender, and then start a DPMI host without a DOS extender,
both as single use, each runs and exits separately of the other. That
indicates to me both are installed, but neither is activated until a DPMI
program activates DPMI. Of course, I'm trying to get *merged* or *replaced*
functionality, i.e., the DPMI host without the DOS extender to replace the
DPMI functionality of the DPMI host with DOS extender. I take it this may
require activating the DPMI host(s), and messing around with Int 0x21, AH=4C
(DPMI's exit, not DOS exit) or exiting via some other means to bypass the
DPMI exit so it stays active (?). Anyone try something like this? Any
ideas?


Rod Pemberton

[Rugxulo]

Hi,

On May 19, 7:08 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:

Does the extender not implement the whole standard? Is it a 0.9
subset? Or are you trying to bypass something complex (like Windows)
to use fuller functionality? The latter is possible but very hard (see
Japheth's NTDPMIX or QLINK's DPMIONE shims).

It sounds like you want to run one DPMI host but then override it
later. Not sure that will work, the extender probably doesn't
initialize anything if already found enabled (int 2Fh, 1687h
succeeds).

In all fairness, you're probably better off running the main one you
prefer first (e.g. "hdpmi32 -r") and then running whatever, instead of
running a weaker subset and shelling out to something that needs a
fuller implementation.

[Rod Pemberton]

"Rugxulo" <rug...@gmail.com> wrote in message
news:a0f39c43-77d7-451f...@f14g2000yqe.googlegroups.com...

> On May 19, 7:08 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:
> > The other day I had this thought:
> >
> > "I wish I could keep this DPMI host's DOS extender,
> > but change it's DPMI host..."
> >
> > That would be useful to me. The issue I'm seeing is that if I start a
> > DPMI host with a DOS extender, and then start a DPMI host without
> > a DOS extender, both as single use, each runs and exits separately of
> > the other. That indicates to me both are installed, but neither is
> > activated until a DPMI program activates DPMI. Of course, I'm trying
> > to get *merged* or *replaced* functionality, i.e., the DPMI host without
> > the DOS extender to replace the DPMI functionality of the DPMI host
> > with DOS extender. I take it this may require activating the DPMI
> > host(s), and messing around with Int 0x21, AH=4C (DPMI's exit, not
> > DOS exit) or exiting via some other means to bypass the DPMI exit so

> > it stays active(?). Anyone try something like this? Any ideas?

>
> Does the extender not implement the whole standard? Is it a 0.9
> subset?
>

I don't know. That didn't concern me. It's DPMI 0.9.

> Or are you trying to bypass something complex (like Windows)
> to use fuller functionality?

No, just a standard DPMI host+DOS extender AFAIK. Specifically, DOS4GW used
with OpenWatcom (OW). Japheth's HDPMI32 is a big improvement, but the idea
came to me with DOS4GW. I still want to see how CWSDPMI (v5)
- specifically - would work as a DPMI host with OpenWatcom DPMI executables.
Unfortunately, CWSDPMI doesn't have that DOS extender stuff the OW needs
built-in, AIUI.

> The latter is possible but very hard (see
> Japheth's NTDPMIX or QLINK's DPMIONE shims).

Ok. I take a cursory look at those. I don't recall shims with DPMIONE...

Yeah, not finding the shims ... Did you mean 386SWAT?

NTDPMIX is for Win32...

> It sounds like you want to run one DPMI host but then override it
> later. Not sure that will work, the extender probably doesn't
> initialize anything if already found enabled (int 2Fh, 1687h
> succeeds).
>
> In all fairness, you're probably better off running the main one you
> prefer first (e.g. "hdpmi32 -r") and then running whatever, instead of
> running a weaker subset and shelling out to something that needs a
> fuller implementation.

If not made resident, it's more like they're queuing up.

E.g., I'll use HDPMI for this example since it can be run from the command
line without an executable, whereas DOS4GW and DOS32A etc for OW
need a compatible executable as an argument.

C:\HDPMI
C:\CWSDPMI
C:\<dpmi_application> ; REM uses CWSDPMI - CWSDPMI exits
C:\<dpmi_application> ; REM uses HDPMI - HDPMI exits
C:\<dpmi_application> ; REM uses default host of application
C:\<dpmi_application> ; REM uses default host of application

No overlap. No collision. No merge of functionality. One runs. Then, the
other.

If both are made resident, only the last one will become active.

C:\HDPMI -r
C:\CWSDPMI -p
C:\<dpmi_application> ; REM uses CWSDPMI
C:\<dpmi_application> ; REM uses CWSDPMI
C:\<dpmi_application> ; REM uses CWSDPMI

If the "dpmi_application" is a DJGPP app, then it executes, but if it's an
OW app, it fails to work because CWSDPMI doesn't work with OW. If reversed,
then everything works because HDPMI works for both.

If the first is made resident, the second one will be active for one
execution of an application, then the permament one takes over.

C:\HDPMI -r
C:\CWSDPMI
C:\<dpmi_application> ; REM uses CWSDPMI
C:\<dpmi_application> ; REM uses HDPMI
C:\<dpmi_application> ; REM uses HDPMI
C:\CWSDPMI
C:\<dpmi_application> ; REM uses CWSDPMI
C:\<dpmi_application> ; REM uses HDPMI
C:\<dpmi_application> ; REM uses HDPMI
C:\<dpmi_application> ; REM uses HDPMI


I think, more of a guess, the PM entry address for the DPMI host must be
called to activate the DPMI host. So, the DPMI hosts chain one of the
interrupts, the first one runs and exits, then the second one ... I'm
guessing that means I'll have to run something between HDPMI and CWSDPMI to
activate HDPMI, but then perhaps not exit properly so it stays active (?)
and doesn't cause DOS to crash... Then, load CWSDPMI. But, I suspect
that'll leave the first host in PM thereby blocking the second from working
...

I suspect the DPMI hosts are chaining an interrupt, probably one of the Int
0x2F calls used by DPMI. So, maybe I could use that to cause both to
execute/activate. E.g., trap the call and call it twice ... Most likely,
the DPMI exit (same call as DOS exit) unchains a 2F interrupt.

I'll give it few days to think about it and poke around it, and then either
give it a serious go or forget about it.

Another option was to ask Japheth, or just modify his HDPMI source if
available, to disable DPMI portion. It seems HDPMI has an argument,
like -m or something, which disables DPMI 1.0 calls. So, that could be
enhanced, perhaps, to disable all DPMI calls.


Rod Pemberton

[Rugxulo]

Hi,

N.B. I've never written my own extender nor DPMI host, so my
experience is limited to end-user stuff.

On May 20, 4:38 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message

Keep in mind different versions support different things, e.g. DOS/4GW
1.97 is (I think) latest "royalty free" version but later versions
exist commercially (with bugfixes or new features, esp. in case of DOS/
4G [sic]).

And yes, you have to be careful as OW does rely on some extender stuff
(though I dunno what), so CWSDPMI alone won't work there. But of
course most "extenders" also try to mostly function okay under
external DPMI hosts (i.e. Windows).

> > The latter is possible but very hard (see
> > Japheth's NTDPMIX or QLINK's DPMIONE shims).
>
> Ok.  I take a cursory look at those.  I don't recall shims with DPMIONE...

It's not DPMIONE per se, just QLINK, which uses (rare) DPMI 1.0 calls,
apparently. So it won't work otherwise, I guess. Even DOSEMU, which I
thought was fairly full-featured, didn't work, nor even HDPMI32, IIRC.
(Nothing is perfect, I guess.)

> Yeah, not finding the shims ...  Did you mean 386SWAT?

It's in the QLINK package so that it will run under Win98 or WinXP,
etc. Maybe it's based upon Borland code, I dunno, but I doubt it. (I
think QLINK is 100% asm.)

> NTDPMIX is for Win32...

Yes, I know. I didn't understand what host you were trying to bypass.
NTDPMIX was Japheth's "improvements" to XP's buggy DPMI.

> > It sounds like you want to run one DPMI host but then override it
> > later. Not sure that will work, the extender probably doesn't
> > initialize anything if already found enabled (int 2Fh, 1687h
> > succeeds).
>
> > In all fairness, you're probably better off running the main one you
> > prefer first (e.g. "hdpmi32 -r") and then running whatever, instead of
> > running a weaker subset and shelling out to something that needs a
> > fuller implementation.
>
> If not made resident, it's more like they're queuing up.
>
> E.g., I'll use HDPMI for this example since it can be run from the command
> line without an executable, whereas DOS4GW and DOS32A etc for OW
> need a compatible executable as an argument.
>
> C:\HDPMI
> C:\CWSDPMI
> C:\<dpmi_application>  ; REM uses CWSDPMI - CWSDPMI exits
> C:\<dpmi_application>  ; REM uses HDPMI - HDPMI exits
> C:\<dpmi_application>  ; REM uses default host of application
> C:\<dpmi_application>  ; REM uses default host of application
>
> No overlap.  No collision.  No merge of functionality.  One runs.  Then, the
> other.

Right. Normally you just let an .EXE use whatever it finds / looks
for.

> If both are made resident, only the last one will become active.
>
> C:\HDPMI -r
> C:\CWSDPMI -p
> C:\<dpmi_application>  ; REM uses CWSDPMI
> C:\<dpmi_application>  ; REM uses CWSDPMI
> C:\<dpmi_application>  ; REM uses CWSDPMI

Right, so don't load two at once. ;-)

> If the "dpmi_application" is a DJGPP app, then it executes, but if it's an
> OW app, it fails to work because CWSDPMI doesn't work with OW.  If reversed,
> then everything works because HDPMI works for both.

HDPMI32 is more ambitious and implements a lot of extra stuff. CWSDPMI
is fairly minimal in only supporting "pure" standard 32-bit DPMI 0.9
with a few 1.0 calls. According to CWS, I think, there was no reliable
int 21h extension standard, so it was fairly hard to get various apps
working consistently. And since CWSDPMI was mainly meant for DJGPP, it
was less important.

> If the first is made resident, the second one will be active for one
> execution of an application, then the permament one takes over.
>
> C:\HDPMI -r
> C:\CWSDPMI
> C:\<dpmi_application>  ; REM uses CWSDPMI
> C:\<dpmi_application>  ; REM uses HDPMI
> C:\<dpmi_application>  ; REM uses HDPMI
> C:\CWSDPMI
> C:\<dpmi_application>  ; REM uses CWSDPMI
> C:\<dpmi_application>  ; REM uses HDPMI
> C:\<dpmi_application>  ; REM uses HDPMI
> C:\<dpmi_application>  ; REM uses HDPMI

Okay, but people don't (hopefully) load CWSDPMI when another DPMI host
is already loaded. In particular, the stub for DJGPP loads CWSDPMI
only when no other is found, and that is automatic behind the scenes.
So just running DJBLAH.EXE will not need manual loading. (I know you
knew this.)

> I think, more of a guess, the PM entry address for the DPMI host must be
> called to activate the DPMI host.  So, the DPMI hosts chain one of the
> interrupts, the first one runs and exits, then the second one ...  I'm
> guessing that means I'll have to run something between HDPMI and CWSDPMI to
> activate HDPMI, but then perhaps not exit properly so it stays active (?)
> and doesn't cause DOS to crash...  Then, load CWSDPMI.  But, I suspect
> that'll leave the first host in PM thereby blocking the second from working

Don't load CWSDPMI at all. It won't be auto-loaded by DJGPP unless no
other DPMI is found.

Part of the problem "may" be that DPMI itself allows a DPMI client and
host to somewhat intermix features that the other lacks, e.g. virtual
memory. Maybe that's what you're indirectly experiencing. (Dunno,
honestly, very confusing.)

> I suspect the DPMI hosts are chaining an interrupt, probably one of the Int
> 0x2F calls used by DPMI.  So, maybe I could use that to cause both to
> execute/activate.  E.g., trap the call and call it twice ...  Most likely,
> the DPMI exit (same call as DOS exit) unchains a 2F interrupt.
>
> I'll give it few days to think about it and poke around it, and then either
> give it a serious go or forget about it.

I'm not seeing the goal here, but messing around is always fun. Though
it'd probably just be easier to always use HDPMI32, assuming you don't
need virtual memory. Honestly, I don't know whether most DPMI hosts
are buggy or just meant for their own limited environments (e.g. most
DJGPP apps indirectly assume DJGPP-only .EXEs, same with OpenWatcom
stuff).

> Another option was to ask Japheth, or just modify his HDPMI source if
> available, to disable DPMI portion.  It seems HDPMI has an argument,
> like -m or something, which disables DPMI 1.0 calls.  So, that could be
> enhanced, perhaps, to disable all DPMI calls.

HDPMI32 was always claimed to support "most" of 1.0, but I don't know.
At least it still reports (conservatively??) 0.90. Anyways, not a lot
of apps use full 0.90, much less 1.0.

But this last bit makes me even more confused about what you're trying
to do. Hmmmm. I think Causeway doesn't use DPMI unless already
available (like if loading CWSDPMI first), e.g. prefers VCPI if found.
Similarly DOS/32A (at least 9.1.2, not sure why OW 1.9 still only has
"old" 7.2 or whatever). Recently I discovered that DOS32A.EXE 9.1.2
will always (!) ignore DPMI in favor of VCPI, even if DPMI is
available. Apparently this used to be optional or tweakable but now no
longer! DOS/32A doesn't even work properly under "VCPI NOEMS" (unlike
others). Long story short, the "fix" I found was this: "hdpmi32 -r",
"jemm386 novcpi", "gs386.exe" (or whatever app), "jemm386 vcpi",
"hdpmi32 -u". Then it has no choice but to use DPMI only (a la WinXP
where you have nothing else).

[Ross Ridge]

Rod Pemberton <do_no...@notemailntt.cmm> wrote:
>The other day I had this thought:
>
> "I wish I could keep this DPMI host's DOS extender,
> but change it's DPMI host..."
>
>That would be useful to me. The issue I'm seeing is that if I start a DPMI
>host with a DOS extender, and then start a DPMI host without a DOS extender,
>both as single use, each runs and exits separately of the other. That
>indicates to me both are installed, but neither is activated until a DPMI
>program activates DPMI.

Well, DPMI can't really be running while you're using MS-DOS, since
DPMI provides a protected mode enviroment and MS-DOS runs in real mode.
It's going to have to sit around waiting for some application to request
the use of services before switching to protected mode and actually
providing DPMI functionality.

Note that a DOS extender doesn't necessarily need to use DPMI. DPMI is
designed to handle the case where some other operating system is emulating
MS-DOS in virtual 8086 mode and doesn't want give up full control of the
CPU. Many DOS extenders were designed to switch into protected mode from
real mode directly and only fell back on DPMI when that wasn't possible.

Somewhat complicating the issue is that memory managers like EMM386
would switch the CPU into virtual 8086 mode in order implement EMS memory
and UMBs. In this case DOS extenders would use VCPI to gain full control
of the CPU and switch into protected mode.

>Of course, I'm trying to get *merged* or *replaced*
>functionality, i.e., the DPMI host without the DOS extender to replace the
>DPMI functionality of the DPMI host with DOS extender.

You might get better luck if you start the DPMI host before running the
DOS extended application.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[Rod Pemberton]

"Rugxulo" <rug...@gmail.com> wrote in message

news:bd08c320-a1a3-4eaf...@j28g2000yqe.googlegroups.com...

> But this last bit makes me even more confused about what
> you're trying to do.

An OpenWatcom DPMI host is:
OW DPMI host => [1) (OW) DPMI host + 2) OW Dos extender]

A DJGPP DPMI host is:
DJGPP DPMI host => [3) (DJGPP) DPMI host]

I'm trying to get to this:
[1) (OW) DPMI host (disabled) + 2) OW Dos extender (enabled)]
+
[3) (DJGPP) DPMI host (enabled)]

I want the DJGPP DPMI functions to be called instead of the OW DPMI
functions for an OW application. The problem is OW applications also need
an OW compatible DOS extender. DJGPP DPMI hosts don't have any DOS
extender. I.e., I need a DJGPP DPMI host + 1/2 of an OW DPMI host - the
half with the DOS extender.

> Similarly DOS/32A [...][prefers VCPI if found].

> Recently I discovered that DOS32A.EXE 9.1.2
> will always (!) ignore DPMI in favor of VCPI, even if DPMI is
> available. Apparently this used to be optional or tweakable but now
> no longer! DOS/32A doesn't even work properly under
> "VCPI NOEMS" (unlike others). Long story short, the "fix" I
> found was this: "hdpmi32 -r", "jemm386 novcpi", "gs386.exe"
> (or whatever app), "jemm386 vcpi", "hdpmi32 -u". Then it has no
> choice but to use DPMI only (a la WinXP where you have
> nothing else).

In Win98/SE, you can turn EMS off for any "console" Window started by a
short-cut to MS-DOS or an MS-DOS application. Right-click. Properties.
Memory tab. There you can tell it what to do for EMS, XMS, DPMI, HMA, etc.
Was this functionality removed from XP? From a few quick searches, you
might be able to do that on the executable in XP.


Rod Pemberton

[Rugxulo]

Hi,

On May 20, 7:46 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:bd08c320-a1a3-4eaf...@j28g2000yqe.googlegroups.com...
>

> I want the DJGPP DPMI functions to be called instead of the OW DPMI
> functions for an OW application.  The problem is OW applications also need
> an OW compatible DOS extender.  DJGPP DPMI hosts don't have any DOS
> extender.  I.e., I need a DJGPP DPMI host + 1/2 of an OW DPMI host - the
> half with the DOS extender.

I suppose HDPMI32 is compatible with both, or at least seems to be.
Esp. since Japheth seems to prefer OW. Or is there something (virtual
memory? extra functions?) that CWSDPMI supports that none other does
(even HDPMI32)??

> In Win98/SE, you can turn EMS off for any "console" Window started by a
> short-cut to MS-DOS or an MS-DOS application.  Right-click.  Properties.
> Memory tab.  There you can tell it what to do for EMS, XMS, DPMI, HMA, etc.
> Was this functionality removed from XP?  From a few quick searches, you
> might be able to do that on the executable in XP.

I don't use XP anymore. All those machines got hosed or died or
similar. So I can't say for sure without testing. However, from
memory, XP isn't nearly as good as Win9x re: DOS or memory. Even
things that used to work or "supposed" to work don't anymore. EMS is
disabled by default, not sure it can 100% be enabled (on all machines
or at all), which is why one guy wrote EMS Magic (real-mode TSR). XMS
is some ridiculously low value, and I'm fairly certain you can't
configure it, at least not via PIFs anymore, not successfully. I could
be wrong, but I'm pretty sure XP didn't work that great. DPMI was the
only reliable method to alloc memory. I know both Win9x and XP had
some minor bugs, but XP just seems like the NTVDM developers barely
cared anymore. Vista's DPMI limit (EDIT: sorry, originally from
Win2k3) kinda proved that (as it wasn't configurable at all, esp. not
via right-clicking or anything obvious, only fixable via undocumented
registry setting in SP1 or later). So let's be honest, MS doesn't care
about "legacy" anymore, only "modern" things like HTML5 or C# or Metro
or whatever. Blind guess, but you'd probably find better DPMI support
in eComStation!

[Rod Pemberton]

"Rugxulo" <rug...@gmail.com> wrote in message

news:1b3dbd0a-b36e-4c82...@n42g2000yqm.googlegroups.com...

> On May 20, 7:46 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:

> > [... mix-n-match DPMI...]

>
> Or is there something (virtual memory? extra functions?) that
> CWSDPMI supports that none other does (even HDPMI32)??

Is there something in particular that I was wanting to test that CWSDPMI
has? No. I just wanted to see how well CWSDPMI v5 worked with OW. In
part, that was because DOS4GW seemed to be unable to allocate as much memory
as CWSDPMI, but that might've been an error on my part ... As an
afterthought, I considered it's ability to use swap space.

> > In Win98/SE, you can turn EMS off [...]

> > Was this functionality removed from XP?
>

> I don't use XP anymore.
>

Sigh, I misunderstood you. I thought you said you used XP and you couldn't
turn off EMS except by using a convoluted sequence with HDPMI32 and Jemm386.
Ok, you mentioned XP a few times, sorry... Where was that problem? DOS?
Vista? Win7? VirtualBox? DOSEMU?


Rod Pemberton

[Rugxulo]

Hi,

On May 22, 2:39 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message

>
> news:1b3dbd0a-b36e-4c82...@n42g2000yqm.googlegroups.com...
>
> > On May 20, 7:46 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > wrote:
> > > [... mix-n-match DPMI...]
>
> > Or is there something (virtual memory? extra functions?) that
> > CWSDPMI supports that none other does (even HDPMI32)??
>
> Is there something in particular that I was wanting to test that CWSDPMI
> has?  No.  I just wanted to see how well CWSDPMI v5 worked with OW.  In
> part, that was because DOS4GW seemed to be unable to allocate as much memory
> as CWSDPMI, but that might've been an error on my part ...  As an
> afterthought, I considered it's ability to use swap space.

DOS/4GW is just really old and, despite its name, buggy and not really
up for big multi-gigabyte allocations. It's not bad, it works, but
yeah, CWSDPMI is overall better (and better maintained over the
years). Then again, DJGPP's malloc is more efficient than OW also, so
both DJGPP + CWSDPMI work well together.

You may? have more success mixing Causeway and CWSDPMI or even D3X.

> > > In Win98/SE, you can turn EMS off [...]
> > > Was this functionality removed from XP?
>
> > I don't use XP anymore.
>
> Sigh, I misunderstood you.  I thought you said you used XP and you couldn't
> turn off EMS except by using a convoluted sequence with HDPMI32 and Jemm386.

No, I never used EMS with XP, and I'm not sure it would work anyways.
XP's NTVDM was good but more or less abandoned. I just wanted to make
it clear that, despite how many people whine about Win9x, it was
better than XP in some regards (e.g. DOS support).

> Ok, you mentioned XP a few times, sorry...  Where was that problem?  DOS?
> Vista? Win7? VirtualBox? DOSEMU?

It was just a small bug / incompatibility with DOS/32A in pure DOS.
The odd part was that he removed the pre-existing ability to configure
it to use DPMI first instead of VCPI, and I don't know why.

Anyways, I'm done "playing" with "EMM386 NOEMS", so now I'm back to
preferring plain XMS. It's just seems easier. So I'll just "JEMM386
LOAD" when (rarely) needing EMS.

[Rugxulo]

Hi,

On May 22, 10:41 am, Rugxulo <rugx...@gmail.com> wrote:
>
> On May 22, 2:39 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:
>
> > "Rugxulo" <rugx...@gmail.com> wrote in message
>
> >news:1b3dbd0a-b36e-4c82...@n42g2000yqm.googlegroups.com...
>
> > > On May 20, 7:46 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > > wrote:
> >
> > Is there something in particular that I was wanting to test that CWSDPMI
> > has?  No.  I just wanted to see how well CWSDPMI v5 worked with OW.  In
> > part, that was because DOS4GW seemed to be unable to allocate as much memory
> > as CWSDPMI, but that might've been an error on my part ...  As an
> > afterthought, I considered it's ability to use swap space.
>
> DOS/4GW is just really old and, despite its name, buggy and not really
> up for big multi-gigabyte allocations. It's not bad, it works, but
> yeah, CWSDPMI is overall better (and better maintained over the
> years). Then again, DJGPP's malloc is more efficient than OW also, so
> both DJGPP + CWSDPMI work well together.
>
> You may? have more success mixing Causeway and CWSDPMI or even D3X.

You said in another thread that your PC has 4 GB. I don't know why
you're still using older tools, e.g. CWSDPMI r5. His latest is r7 and
fixes and improves some stuff (though still has one or two rare bugs),
e.g. 4 MB pages (in some circumstances). I keep both around (among
others) for comparison.

Long story short, I was messing around re: your Knuth recursion test
attempts in DOS, and I noticed (yet again) that Causeway (among
others) doesn't seem to allocate correctly. I tried confirming that by
using my old dopey compile of paq8o8z. For whatever reason, Causeway
wouldn't work with -8 when under XMSv3 only. I don't know exactly why
(page tables?), but I had to "set CAUSEWAY=DPMI" and then manually run
"HDPMI32" and *then* run "paq8o8z -8 doydoy8 paq8o8z.cpp" for it to
work. (This uses over a gig of RAM, by the way, which is pretty rare
as most apps don't need that, even at highest settings.)

I should've really grabbed a text screenshot for you, but whatever.
And the other point I wanted to make is that paq8o8z compiled by DJGPP
uses less RAM on such a high setting. Normally it is (or should be)
the same, e.g. 37 MB for -1 (level one) when not using higher models
(.JPG), but I've noticed that at high settings it uses like 32 MB more
RAM for OpenWatcom. So I assume that's their malloc rounding up or
whatever.

I feel kinda silly even mentioning this since I'm not smart enough to
understand or tweak or fix most things like this. Just wanted you to
know that sometimes issues come up.

[Rod Pemberton]

"Rugxulo" <rug...@gmail.com> wrote in message

news:8f63638a-889d-46bd...@n42g2000yqm.googlegroups.com...

> You said in another thread that your PC has 4 GB. I don't know why
> you're still using older tools, e.g. CWSDPMI r5. His latest is r7 and
> fixes and improves some stuff (though still has one or two rare bugs),
> e.g. 4 MB pages (in some circumstances). I keep both around (among
> others) for comparison.

Yeah, so far, I haven't seen any advantage to r7. r5 works great. A few
times, I thought r7 worked worse ... But, honestly, I haven't used r7
enough to confirm. And, I've never checked if 4MB pages are enabled or
disabled by default. I'd rather *not* have them enabled, i.e., choosing
small pages by default.

> [...] and I noticed (yet again) that Causeway (among others)
> [has problems]

I'm replying to an altered version of your topic...

I collected many DPMI hosts a few years ago, but found most of them had one
issue or another. The main thing for me at that point in time was that they
work with either DJGPP or OpenWatcom. So, I mostly stick to what works for
those. CWSDPMI, CWSDPR0, PMODETSR (aka PMODEDJ) for DJGPP.
DOS4G/W and HDPMI32 for OpenWatcom. I've not used Causeway with
OpenWatcom. IIRC, I couldn't seem to get it to work with it, but I don't
recall why. That was when I was very new to DPMI. So, I suspect it does
work.


Um, Rugxulo... Did you write most of this webpage? Be honest...

http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.DPMI


I might have to take a look at DOS/32A someday.

These features are very good:
-"fast"
-"large ram"
-"drop-in replacement [for DOS4G/W]"
-"applications are run in Ring0"
-"written in assembly"
-"it's source is very nice and well commented"
-"compiles with TASM using IDEAL mode"

I suspect these problems are probably easily fixable:
-"in real mode also install[s] it[']s own DPMI kernel
(bypassing the existing one)"
-"prefer[s] VCPI over DPMI"

These features are so-so:
-"paging won't be enabled"
-I suspect no virtual memory (as a disk file) either (since no paging)...

This feature might be useful for what I was asking about:
-"bad habit ... to ignore an existing DPMI host"

This feature tells me it should be easy to convert to NASM:
-"compiles with TASM using IDEAL mode"


NASM sources would be great. I suspect converting DOS/32A to NASM would
be easier than figuring out how to compile stuff by Japheth. That's one of
the *big* problems, IMO, with the great stuff Japheth comes up with. Yes,
I'm aware he was probably working on some of those projects for decades.


Rod Pemberton

[Rugxulo]

Hi,

On May 24, 2:38 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message

>
> news:8f63638a-889d-46bd...@n42g2000yqm.googlegroups.com...
>
> > You said in another thread that your PC has 4 GB. I don't know why
> > you're still using older tools, e.g. CWSDPMI r5. His latest is r7 and
> > fixes and improves some stuff (though still has one or two rare bugs),
> > e.g. 4 MB pages (in some circumstances). I keep both around (among
> > others) for comparison.
>
> Yeah, so far, I haven't seen any advantage to r7.  r5 works great.  A few
> times, I thought r7 worked worse ...  But, honestly, I haven't used r7
> enough to confirm.  And, I've never checked if 4MB pages are enabled or
> disabled by default.  I'd rather *not* have them enabled, i.e., choosing
> small pages by default.

I've used r7 a lot by now. More or less it's always better than r5 for
me. And while I love it and it works very very well, it does have one
or two bugs (sadly). You may encounter that on a 4 GB machine (due to
not taking into account needing to have page tables in low RAM, which
can sometimes run out on high amounts due to big RAM machines these
days; bad design flaw that would be tedious to test and fix).

You can use CWSPARAM to completely disable 4 MB pages in your r7. I
don't know the details of usage, though. I think it only uses 4 MB
pages if hardware supports it (586-686) and only if huge allocations
are used and only if not under EMM386/VCPI and only above a certain
amount of memory. (shrug) It's lots faster than 4 kb pages too, but
strict DPMI 1.0 wasn't technically designed for it (since 4 MB pages
didn't exist), so it may have very rare issues in those rare cases.
And something like it won't page/swap out 4 MB pages. Heh, I know,
sounds like a mess, welcome to modern hardware. ;-) I just like
having the option to use it, among others, and I usually use r7 by
default if at all possible.

At the very least, I hope you're using r5 from 2008, which had the 3
fixes from 2002 plus added SSE support.

> > [...] and I noticed (yet again) that Causeway (among others)
> > [has problems]
>
> I'm replying to an altered version of your topic...
>
> I collected many DPMI hosts a few years ago, but found most of them had one
> issue or another.

Probably true, yes. It's hard to test in a billion environments. And
DOS ain't cool anymore, so most developers gave up the ghost. Though
most of them are pretty darn stable and work well, but admittedly,
when you add gigs of RAM and other weirdnesses, it gets more complex.

> The main thing for me at that point in time was that they
> work with either DJGPP or OpenWatcom.  So, I mostly stick to what works for
> those.  CWSDPMI, CWSDPR0, PMODETSR (aka PMODEDJ) for DJGPP.
> DOS4G/W and HDPMI32 for OpenWatcom.  I've not used Causeway with
> OpenWatcom.   IIRC, I couldn't seem to get it to work with it, but I don't
> recall why.  That was when I was very new to DPMI.  So, I suspect it does
> work.

These days I'm using DOS32A.EXE renamed to DOS4GW.EXE with OpenWatcom.
It more or less works, but I keep the "real" DOS/4GW as backup just in
case.

Again, it's very eye-opening to see various bugs and corner cases in
DOS extenders on such a big RAM machine. <joking> Maybe you and I
should write our own? ^_^ </joking>

> Um, Rugxulo...  Did you write most of this webpage?  Be honest...
>

> http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main...

No, it was probably DOS386, he's big on editing that wiki. Reading it
again pretty obviously shows it was him, he has a certain style. ;-)

> I might have to take a look at DOS/32A someday.
>
> These features are very good:
> -"fast"
> -"large ram"
> -"drop-in replacement [for DOS4G/W]"
> -"applications are run in Ring0"
> -"written in assembly"
> -"it's source is very nice and well commented"
> -"compiles with TASM using IDEAL mode"

It's only 27 kb, which is much smaller than DOS4GW.EXE. Also, I think
DOSBox devs recommended using it for old Watcom-based games that had
problems as it sometimes worked better.

> I suspect these problems are probably easily fixable:
> -"in real mode also install[s] it[']s own DPMI kernel
>       (bypassing the existing one)"
> -"prefer[s] VCPI over DPMI"

Yes, already mentioned that is a weird quirk. I emailed him, even he
doesn't remember why he did that. Oh well. But like I said, just do
"hdpmi32 -r", "jemm386 novcpi", "dos32a blah.exe ...", "jemm386 vcpi",
"hdpmi32 -u", and everything should be okay (if it doesn't work by
default, e.g. EMM386 NOVCPI, and you want to force DPMI).

> These features are so-so:
> -"paging won't be enabled"
> -I suspect no virtual memory (as a disk file) either (since no paging)...

Right. Most don't support virtual memory. The only ones that do are
CWSDPMI, DOS/4GW (barely), Causeway (but needs "full used RAM amount"
paged out, not just extra like CWS), DPMIONE, and maybe something else
I'm forgetting.

Though, like I said, DPMI seems to imply you can (client side) support
virtual memory even without explicit host support. But I have no idea,
never tried. (And my old experience with Vista with DPMI limit showed
that they must not support virtual memory for DOS apps anymore, ugh.)

We don't need virtual memory on modern machines. It was very useful on
old hardware (like my old P166), but nowadays, not so much. Anyways,
like I said, CWSDPMI r7 has a bug where, on my 6 GB machine, it says
"4 GB is free", but refuses (and can't) swap out, even when it needs
to (too many 4 kb pages to put into low / conventional memory!). So I
have to use some weird workarounds just to use Seed7 compiled compiler
+ DJGPP + tests (chkset, chkbig) or it will fail on those. (Boring,
obscure, just saying for completeness.)

> This feature might be useful for what I was asking about:
> -"bad habit ... to ignore an existing DPMI host"

It always uses VCPI despite DPMI being available also. You used to be
able to configure / choose, but no longer. Perhaps if you reassemble
it and uncomment out that part, but I haven't tried. Easier to use the
weird "jemm386 novcpi" hack mentioned above. Or just don't load
EMM386! ;-)

> This feature tells me it should be easy to convert to NASM:
> -"compiles with TASM using IDEAL mode"
>
> NASM sources would be great.  I suspect converting DOS/32A to NASM would
> be easier than figuring out how to compile stuff by Japheth.  That's one of
> the *big* problems, IMO, with the great stuff Japheth comes up with.  Yes,
> I'm aware he was probably working on some of those projects for decades.

Well, the good news is that he spent a lot of time on JWasm, and he
used that by default in latest versions. So it's less crucial (unless
you, like me, prefer NASM syntax). Yeah, DOS extenders are kinda "old
school", so they mostly use old assemblers like TASM. Though D3X is
wholly written with NASM, but it has a few quirks (not to mention non-
commercial license, which doesn't bother me, but is GPL
incompatible ...).

I've not much tried, but "wasm -zcm=tasm" or lzasm or NoMySo (Perl
script) might be useful or help converting these things to NASM. A few
years ago I weakly tried to convert CWSDPMI r5 to free tools, but I
gave up half way. One of these days maybe I'll try again (though it's
not really urgent by any means).

[Ross Ridge]

Rugxulo <rug...@gmail.com> wrote:
>Yes, already mentioned that is a weird quirk. I emailed him, even he
>doesn't remember why he did that. Oh well. But like I said, just do
>"hdpmi32 -r", "jemm386 novcpi", "dos32a blah.exe ...", "jemm386 vcpi",
>"hdpmi32 -u", and everything should be okay (if it doesn't work by
>default, e.g. EMM386 NOVCPI, and you want to force DPMI).

Without VCPI enabled neither the DPMI host nor the DOS extender will have
a means to enter protected mode if something like JEMM386 or EMM386 is
running and providing EMS and/or UMBs.

>It always uses VCPI despite DPMI being available also. You used to be
>able to configure / choose, but no longer. Perhaps if you reassemble
>it and uncomment out that part, but I haven't tried. Easier to use the
>weird "jemm386 novcpi" hack mentioned above. Or just don't load
>EMM386! ;-)

If something like EMM386 or JEMM386 isn't running then the DOS extender
can just enter protected mode directly. It doesn't need to use VCPI or
the already loaded DPMI host.

Looking at the source, that's in fact what DOS/32A will do.

[Rugxulo]

Hi,

On May 25, 1:14 am, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:

> Rugxulo  <rugx...@gmail.com> wrote:
> >Yes, already mentioned that is a weird quirk. I emailed him, even he
> >doesn't remember why he did that. Oh well. But like I said, just do
> >"hdpmi32 -r", "jemm386 novcpi", "dos32a blah.exe ...", "jemm386 vcpi",
> >"hdpmi32 -u", and everything should be okay (if it doesn't work by
> >default, e.g. EMM386 NOVCPI, and you want to force DPMI).
>
> Without VCPI enabled neither the DPMI host nor the DOS extender will have
> a means to enter protected mode if something like JEMM386 or EMM386 is
> running and providing EMS and/or UMBs.

Here's the deal: I was only running JEMM386 because I wanted to use
UMBs. It was more of an temporary experiment as I don't use it much
anymore. (I already vaguely knew that there were some corner cases,
but I just wanted to refresh my memory.) Normally I just use XMS only.
Actually, here I was using "JEMM386 NOEMS MAX=0", so there was no EMS
available (despite VCPI).

I'm not sure of why some extenders choose which "type" of memory (API)
to use. In other words, should it use XMS or EMS? Well, DOS/32A seemed
to prefer VCPI/EMS despite my use of "NOEMS MAX=0". I would've rather
it just used XMS. My point was that if I load an external DPMI host
like HDPMI32, DOS/32A still would only use VCPI (which in this case
was failing). DOS/32A used to let you change it where it would prefer
DPMI (if available), but he removed that option (for some strange
reason). :-(

You're right, without VCPI, the DPMI host can't enter pmode, but it
doesn't need to if DPMI is already loaded. I just switched off VCPI so
it would be forced to use the preloaded HDPMI32. And that worked,
then, under that environment. (Of course, a different solution is to
not use DOS/32A, use something different like Causeway's CWSTUB. Or
use a DJGPP version of gs386.exe, that too works fine.)

It was just a "bug" (or design flaw?) that I was trying to avoid.

> >It always uses VCPI despite DPMI being available also. You used to be
> >able to configure / choose, but no longer. Perhaps if you reassemble
> >it and uncomment out that part, but I haven't tried. Easier to use the
> >weird "jemm386 novcpi" hack mentioned above. Or just don't load
> >EMM386!   ;-)
>
> If something like EMM386 or JEMM386 isn't running then the DOS extender
> can just enter protected mode directly.  It doesn't need to use VCPI or
> the already loaded DPMI host.
>
> Looking at the source, that's in fact what DOS/32A will do.

Right, but my problem is that you (usually) can't "unload" EMM386
without rebooting, so that's somewhat inconvenient. You can actually
do "JEMM386 UNLOAD" but only if not using UMBs. So if you don't need
UMBs (and I don't as FreeDOS is pretty space efficient, even with pure
XMS), you can "LOAD" and "UNLOAD" at will, if (rarely) needing EMS
support. But in this case, I had loaded JEMM386 at bootup in order to
use UMBs, so it wasn't possible to unload. So if a particular DOS/32A
app clashes with my memory setup, I have no choice but to use a
different extender or reboot to a different setup (e.g. XMS only).
Which is fine, just a bit inconvenient. I wanted to try to avoid that
here.

So it's kinda a silly problem, nothing worth worrying about, just an
interesting (?) study into the various compatibility issues of various
things. ;-)

[Ross Ridge]

Rugxulo <rug...@gmail.com> wrote:
>I'm not sure of why some extenders choose which "type" of memory (API)
>to use. In other words, should it use XMS or EMS? Well, DOS/32A seemed

>to prefer VCPI/EMS despite my use of "NOEMS MAX=3D0".

VCPI exists primarily as a means to enter protected mode when an EMS
driver uses virtual 8086 mode to emulate EMS memory. It's also necessary
when a driver is using virtual 8086 mode to create UMBs. Since virtual
8086 mode is a form of protected mode a DOS extender can't simply enter
protected by setting the protected mode bit. VCPI provides a way for
a DOS extender to gain full control of the CPU much like it would if it
was launched from real mode.

Note that whether or not DOS extender or DPMI host uses VCPI is a seperate
issue from whether it uses EMS or XMS memory. HDPMI32 tries to use XMS
to allocate memory when using VCPI because apparently its faster that way.

>You're right, without VCPI, the DPMI host can't enter pmode, but it
>doesn't need to if DPMI is already loaded.

HDMPI32 still needs to use VCPI to enter protected mode after it's loaded
if JEMM386 is providing UMBs. There's no other way to switch the CPU
to protected mode.

>I just switched off VCPI so it would be forced to use the preloaded
>HDPMI32. And that worked, then, under that environment.

HDPMI32 saved the VCPI protected mode entry point when it was made
resident and then used it later to enter protected mode when the DOS
extender started. JEMM386 didn't actually turn off VCPI, it only
prevented it from being detected. If HDPMI32 didn't save the entry
point or if JEMM386 had actually disabled VCPI completely then the DOS
extender wouldn't have be able to start.

[Ross Ridge]

Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
>HDPMI32 saved the VCPI protected mode entry point when it was made
>resident and then used it later to enter protected mode when the DOS
>extender started.

Sorry, the entry point is only used after it switches to protected mode.
HDMPI32 just remembers the fact that it dected VCPI when it was loaded
and then uses the VCPI function INT 67h, AX=0DE0Ch enter protected mode
when the DOS extender starts.

[Rugxulo]

Hi,

On May 25, 9:06 pm, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> Ross Ridge  <rri...@csclub.uwaterloo.ca> wrote:
>
> >HDPMI32 saved the VCPI protected mode entry point when it was made
> >resident and then used it later to enter protected mode when the DOS
> >extender started.
>
> Sorry, the entry point is only used after it switches to protected mode.
> HDMPI32 just remembers the fact that it dected VCPI when it was loaded
> and then uses the VCPI function INT 67h, AX=0DE0Ch enter protected mode
> when the DOS extender starts.

Okay, you're right of course. I forgot all that. But yes, the point
was to hide VCPI so that DOS/32A wouldn't try using it (and fail) in
lieu of DPMI (which works).

BTW, apparently there is a cmdline switch to get HDPMI to use VCPI
even if XMS is detected. So at least some people agree with me that it
may be advantageous to configure it.

P.S. Under "JEMM386 NOEMS" I ended up having over 64k free UMBs
anyways, so I ended up switching to EMS by default. Unfortunately, I
know that some programs want to use more than default "MAX=120", but
changing it to approx. 512 MB exposed a rare (but vaguely familiar)
"bug" (?) in CWSDPMI, which I use a fair bit, so I just scrapped the
whole idea and went back to plain XMS. I really "by default" don't
need EMS or UMBs at all, so it doesn't matter. If I unload like one or
two TSRs (SHCDX33E, CTMOUSE), I can get 604 kb free, so that should be
plenty, even for oddball (bad) programs that need that much (old
demos??). So I guess it's fairly moot except for curiosity.

[Rod Pemberton]

"Rugxulo" <rug...@gmail.com> wrote in message

news:9c33ecf7-a1e5-460c...@d18g2000yqc.googlegroups.com...

> On May 25, 9:06 pm, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:

> > ... uses the VCPI function INT 67h, AX=0DE0Ch enter protected mode ...

>
> But yes, the point was to hide VCPI so that DOS/32A wouldn't
> try using it (and fail) in lieu of DPMI (which works).

A simple TSR blocking the needed call might work.

E.g., there is a DOS Extender called U7WIN9X that allowed Ultima 7 or 8 to
run. Apparently, it wouldn't execute with EMS. It emitted a warning and
exited. U7RUN.COM blocked the call detecting EMS so it would execute.

> BTW, apparently there is a cmdline switch to get HDPMI to use VCPI
> even if XMS is detected. So at least some people agree with me that it
> may be advantageous to configure it.

I haven't had an EMS (or VCPI) driver installed in years. XMS and DPMI and
DOS memory allocation seem to do everything I need to do when in DOS.
Mostly, that's DJGPP or OW DPMI applications, but all non-DJGPP and non-OW
applications all seem to execute fine. So, is EMS really needed? You might
try disabling it and see how much of what you've got actually runs without
it. I'd guess that the number of programs which actually *require* only EMS
and/or VCPI must be really small. Most likely, I'd assume these
applications were really old.

> [my thoughts mostly confirmed]


Rod Pemberton

[Ross Ridge]

Rod Pemberton <do_no...@notemailntt.cmm> wrote:
>E.g., there is a DOS Extender called U7WIN9X that allowed Ultima 7 or 8 to
>run. Apparently, it wouldn't execute with EMS. It emitted a warning and
>exited. U7RUN.COM blocked the call detecting EMS so it would execute.

U7WIN9X wasn't a DOS extender and didn't work by disabling the dection of
EMS. If I remember correctly it worked through a combination of patches
to the executable and a VxD that handled the faults that resulted from
how Ultima 7 tried to access memory using 32-bit offsets in real mode
(aka "unreal mode").

>I haven't had an EMS (or VCPI) driver installed in years.

You'll need to use EMS or UMBs if you want to use Rugxulo's trick
or install TSR to prevent the detection of VCPI. DOS32/A checks the
procesor's CR0 register first. If the PE (Protected Mode Enable) bit
isn't already set then it doesn't need to use VCPI or DPMI and doesn't
bother to check to see if they are available. It simply enters protected
mode directly by setting the PE bit in CR0.

>So, is EMS really needed? You might try disabling it and see how
>much of what you've got actually runs without it. I'd guess that the
>number of programs which actually *require* only EMS and/or VCPI must be
>really small. Most likely, I'd assume these applications were really old.

Rugxulo said he was no longer using EMS (or UMBs) by default anymore,
but before DOS4GW started being used in games, most of them required EMS.

[Harry Vaderchi]

I found some olde DOS progs wouldn't believe it if you had over 600k free;
I had to eatmem 20k to get one to work.

--
[dash dash space newline 4line sig]

Albi CNU