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

Groups > comp.os.msdos.programmer > #581

Re: DOS and DPMI

Show all headers | View raw

"Geoff Barnard" <geoff@jgb17not.co.uk> wrote in message
news:20120513213859.9D8A01AA107@smtp.zedz.net...
> Hello,
> [...]

Yeah, I'm not familiar with those problems.

> If I try to use add-on DPMI processes, these seem to do something but
> when I try to compile something CL gives a message to say 'No DPMI'.  But
> supposedly there IS DPMI.
>

By CL, do you mean "command-line"? (yes...)

For DosBox, *supposedly*, they've disabled all or most DPMI service calls.
I.e., you'll probably have to set up DPMI as needed for a real mode (RM) x86
DOS.

For a Windows 98 console window (i.e., "dosbox") , Windows provides the
DPMI.  If a DPMI executable detects that DPMI is already installed, then it
won't load it's preferred DOS DPMI host but will use Windows DPMI instead.

For a RM x86 DOS, most of the time the DPMI host is not bound to the
executable.  Sometimes it is bound to the executable.  When it is, you don't
need a DPMI host.  It's built in.  When it isn't, you need the specific DPMI
host that the executable requires.  The DPMI stub on the executable will
check for the DPMI host to be loaded/installed in memory as a TSR, or if not
loaded that it is available on the drive in the one of the path's specified
by the PATH variable.  Which host depends on who coded it (assembly) or what
compiler compiled it.  The exception is when you're executing in a
Win98/SE/ME console window when Windows provides DPMI services.  E.g.,
DJGPP (GCC C compiler) needs CWSDPMI, or an alternate like PMODETSR
(aka PMODEDJ) or CWSDPR0.  OpenWatcom C compiler uses PMODEW or
DOS4GW and maybe Causeway.  While both PMODEW and PMODETSR
(aka PMODEDJ) are derived from PMODE, PMODEW can't be used with
DJGPP and PMODETSR can't be used with OpenWatcom.  DOS4G
cannot be used with OpenWatcom, but it's derivative DOS4GW is specifically
for OpenWatcom.

So, there are different DPMI hosts and they *usually*, almost always, match
the executable.  However, there are some tools that will allow you to unstub
the executable and restub it with a stub for a different DPMI host.  This
can be useful for using a faster DPMI host, better DPMI host, or eliminating
a DPMI host you can't find, etc.  E.g., you'll find stub/unstub tools with
various DPMI hosts: WDOSX DPMI host has STUBIT, D3X has STUBX,
DOS32A has SB.  When you restub, you still have to make sure the new DPMI
host supports that type of executable.  DJGPP provides an executable to
change DPMI compatible hosts within a DJGPP executable's stub, called
STUBEDIT.  COFF2EXE or STUBIFY adds the executable's DPMI stub for
raw DJGPP COFF files.  EXE2COFF removes the stub for DJGPP COFF.

There are numerous DPMI hosts for DOS.  My last count was like 33 or so ...

CWSDPMI CWSDPR0 PMODETSR DOS4GW DOS4G PMODEW Causeway
DOS32 DOS32A WDOSX DPMIONE QDPMI PRO32 D3X HDPMI Pharlap386
Pharlap286 PharlapTNT DPMS 386MAX START32 PMODE ZRDX 386Power
DosWin32 X32 X32VM Raw32 DOSXNT 32RTM U7WIN9x TinyDPMI EOS

> BLINKER will run fine, and I think that needs DPMI as well??
>

You said this is a DJGPP executable?  Anything compiled with DJGPP needs a
DJGPP-compatible DPMI host: CWSDPMI, PMODETSR, CWSDPR0.  Make
sure your PATH variable has the directory that they are in on the path.  The
stub for DJGPP defaults to loading CWSDPMI, but can be changed with
STUBEDIT to one of the other two.  Changing to another DPMI host requires
un-stubbing, re-stubing with the other hosts tools, if available.

> I've been looking for any prog that might 'test' DPMI and confirm
> that it is there, GO32 with djgpp says it IS.

If this is for RM x86 DOS, the presence of a DPMI host depends on the
executable being run, or *sometimes* you running the DPMI host first.  E.g.,
DJGPP's DPMI hosts can be run by themselves and will provide DPMI to
whatever runs next, typically for a single execution.  I.e., you have to
keep reloading it.  OpenWatcom compatible DPMI hosts cannot be run from
the command line.  Only the executable can load them.

> Anyone any ideas why 386Max might not work

Sorry, no, I learned about DPMI much later ...


Rod Pemberton

Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

DOS and DPMI "Geoff Barnard" <geoff@jgb17not.co.uk> - 2012-05-13 22:10 +0000
  Re: DOS and DPMI "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-13 20:49 -0400
    Re: DOS and DPMI "Auric__" <not.my.real@email.address> - 2012-05-14 06:23 +0000
  Re: DOS and DPMI cg_chas <cg_chas@hotmail.com> - 2012-05-13 22:58 -0400
  Re: DOS and DPMI Robert AH Prins <spamtrap@prino.org> - 2012-05-14 07:48 +0000
  Re: DOS and DPMI Rugxulo <rugxulo@gmail.com> - 2012-05-14 17:10 -0700

csiph-web