info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DOS and DPMI
1,045 views
Skip to first unread message
Geoff Barnard
May 13, 2012, 6:10:22 PM5/13/12
to
Hello,
Maybe I'm digging myself a deeper hole each time?
I've had to get a new laptop, as the old SONY died. I was fine with that
one, it had a built in floppy, and XP did some useful things.
The new one has no floppy, although I've got a USB one. It's got W7 mind
you.
I could do with having W7, as I've got a number of issues I need to check
out with that, but the immediate problem is to run DOS progs, and most
important to be mobile with my MS C7 compiler setup, Libs etc.
On my main desktop PC there's no problem as that's a Pentium booting into
DOS, and using 386Max which includes all reqs for the C7 stuff, in fact
386Max was supplied with the compiler.
I spent some time playing with DosBox, and this seemed to get me nowhere
with the DPMI. I find it appears very slow, OK I understand it's emulating
a DOS prompt but it still seems slow.
I tried another tack. I can boot DOS on the floppy, and this gives a great
DOS prompt. Cannot access the NTFS HD. So I changed the HD setup, and gave
myself a 2 Gb FAT partition, but DOS wouldn't see that. Thought it might not.
So, I tried DR-DOS, and this copes better with BIG HDs, and this does give
me a DOS with the 2 Gb HD, and when I boot up into W7 I can still see the
HD so that's more usefull.
When I tried to install 386Max, this went through the initial motions OK
but when I tried to continue with MAXIMIZE the system locks up.
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.
I've tried the JEMM process, this seems to work great and does a lot of
what 386Max would do and again says I've now got DMPI. I test prog coming
with djgpp says there's DPMI. A test prog coming with the HX system says
DPMI is OK. But CL will NOT run. BLINKER will run fine, and I think that
needs DPMI as well??
Maybe I'm almost there, but CL is looking for something else?
Does anyone have any suggestions? I've been looking for any prog that
might 'test' DPMI and confirm that it is there, GO32 with djgpp says it IS.
Anyone any ideas why 386Max might not work - the manual does refer to a
lockup at the same point but is suggesting changing settings but my lockup
is immed before anything else is set??
Feeling I'm very nearly there - could be something silly is missing. Maybe
I cannot see the wood for a partic tree that's stuck in my face??
Any suggestions gratefully received.
Geoff Barnard
Maybe I'm digging myself a deeper hole each time?
I've had to get a new laptop, as the old SONY died. I was fine with that
one, it had a built in floppy, and XP did some useful things.
The new one has no floppy, although I've got a USB one. It's got W7 mind
you.
I could do with having W7, as I've got a number of issues I need to check
out with that, but the immediate problem is to run DOS progs, and most
important to be mobile with my MS C7 compiler setup, Libs etc.
On my main desktop PC there's no problem as that's a Pentium booting into
DOS, and using 386Max which includes all reqs for the C7 stuff, in fact
386Max was supplied with the compiler.
I spent some time playing with DosBox, and this seemed to get me nowhere
with the DPMI. I find it appears very slow, OK I understand it's emulating
a DOS prompt but it still seems slow.
I tried another tack. I can boot DOS on the floppy, and this gives a great
DOS prompt. Cannot access the NTFS HD. So I changed the HD setup, and gave
myself a 2 Gb FAT partition, but DOS wouldn't see that. Thought it might not.
So, I tried DR-DOS, and this copes better with BIG HDs, and this does give
me a DOS with the 2 Gb HD, and when I boot up into W7 I can still see the
HD so that's more usefull.
When I tried to install 386Max, this went through the initial motions OK
but when I tried to continue with MAXIMIZE the system locks up.
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.
I've tried the JEMM process, this seems to work great and does a lot of
what 386Max would do and again says I've now got DMPI. I test prog coming
with djgpp says there's DPMI. A test prog coming with the HX system says
DPMI is OK. But CL will NOT run. BLINKER will run fine, and I think that
needs DPMI as well??
Maybe I'm almost there, but CL is looking for something else?
Does anyone have any suggestions? I've been looking for any prog that
might 'test' DPMI and confirm that it is there, GO32 with djgpp says it IS.
Anyone any ideas why 386Max might not work - the manual does refer to a
lockup at the same point but is suggesting changing settings but my lockup
is immed before anything else is set??
Feeling I'm very nearly there - could be something silly is missing. Maybe
I cannot see the wood for a partic tree that's stuck in my face??
Any suggestions gratefully received.
Geoff Barnard
Rod Pemberton
May 13, 2012, 8:49:13 PM5/13/12
to
"Geoff Barnard" <ge...@jgb17not.co.uk> wrote in message
news:2012051321385...@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
news:2012051321385...@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.
>
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??
>
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.
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
Rod Pemberton
cg_chas
May 13, 2012, 10:58:25 PM5/13/12
to
On Sun, 13 May 2012 22:10:22 +0000, "Geoff Barnard" <ge...@jgb17not.co.uk>
wrote:
>I spent some time playing with DosBox, and this seemed to get me nowhere
>with the DPMI. I find it appears very slow, OK I understand it's emulating
>a DOS prompt but it still seems slow.
I'll go ahead and put some ideas out there. You can decide if any are helpful
or not.
I've been using DOSBox on and off for about 2 years and it has served me quite
well for DOS development and for running DOS programs.
First off, I only use DOSBox with small flat disk images created with bximage
and I do not attempt to run DOS apps directly under DOSBox, I run them under
MS-DOS under DOSBox. For example, MS-DOS 6.22 under DOSBox. Doing this gives
you the best possible compatibility with older DOS applications.
As far as performance, I did experience an issue with when I added a 2GB
second drive image, but I am not sure if it was because the drive was 2GB or
because I added a D drive, but there was a delay in processing that was not
pleasing. With a single 512MB C drive image created with bximage, DOS
performance is great.
>
>I tried another tack. I can boot DOS on the floppy, and this gives a great
>DOS prompt. Cannot access the NTFS HD. So I changed the HD setup, and gave
>myself a 2 Gb FAT partition, but DOS wouldn't see that. Thought it might not.
>So, I tried DR-DOS, and this copes better with BIG HDs, and this does give
>me a DOS with the 2 Gb HD, and when I boot up into W7 I can still see the
>HD so that's more usefull.
If MS-DOS didn't see it, it was likely because the first partition was not a
primary created by MS-DOS's fdisk. If you start with a fresh drive, create a
DOS partition <=2GB as the primary, install DOS and then install an operating
system using the free space on the drive, you can multi-boot DOS with any
operating sytem. You just need a boot loader. I use LILO for this and when I
need to manage the boot sector of the drive, I use a linux live CD/DVD. LILO
uses configuration files that have documented syntax and even supports
graphical menus.
If you have an existing operating system and are looking to adding a real
bootable DOS to it, the easiest way I have done this is by adding another
physical drive, installing DOS onto it, making the drive bootable, and using
LILO menu to point to both operating sytems. The LILO created boot sector
still has to be on the BIOS boot drive. That is, unless you dont mind
switching the bootable drive in the BIOS, which I don't like to do personally.
The most perferrable for me has been to use MS-DOS under DOSBox or VirtualBox
and then run an MS-DOS server drive share and connect to that share from
Windows 7 or Vista. To get networking under DOSBox, you'll need a revision of
it with NE2000 support and WinPcap, or VirtualBox bridged network setup.
>
>When I tried to install 386Max, this went through the initial motions OK
>but when I tried to continue with MAXIMIZE the system locks up.
Just to be clear, 386Max with MAXIMIZE locks the system with DR-DOS, but not
with MS-DOS?
I know that when running QEMM under MS-DOS 6.22 under DOSBox that stealth mode
didn't work because there was an INT that wasn't supported under DOSBox, but
it was able to complete, just without the stealth switch and it did optimize
memory nicely.
Charles
wrote:
>I spent some time playing with DosBox, and this seemed to get me nowhere
>with the DPMI. I find it appears very slow, OK I understand it's emulating
>a DOS prompt but it still seems slow.
or not.
I've been using DOSBox on and off for about 2 years and it has served me quite
well for DOS development and for running DOS programs.
First off, I only use DOSBox with small flat disk images created with bximage
and I do not attempt to run DOS apps directly under DOSBox, I run them under
MS-DOS under DOSBox. For example, MS-DOS 6.22 under DOSBox. Doing this gives
you the best possible compatibility with older DOS applications.
As far as performance, I did experience an issue with when I added a 2GB
second drive image, but I am not sure if it was because the drive was 2GB or
because I added a D drive, but there was a delay in processing that was not
pleasing. With a single 512MB C drive image created with bximage, DOS
performance is great.
>
>I tried another tack. I can boot DOS on the floppy, and this gives a great
>DOS prompt. Cannot access the NTFS HD. So I changed the HD setup, and gave
>myself a 2 Gb FAT partition, but DOS wouldn't see that. Thought it might not.
>So, I tried DR-DOS, and this copes better with BIG HDs, and this does give
>me a DOS with the 2 Gb HD, and when I boot up into W7 I can still see the
>HD so that's more usefull.
primary created by MS-DOS's fdisk. If you start with a fresh drive, create a
DOS partition <=2GB as the primary, install DOS and then install an operating
system using the free space on the drive, you can multi-boot DOS with any
operating sytem. You just need a boot loader. I use LILO for this and when I
need to manage the boot sector of the drive, I use a linux live CD/DVD. LILO
uses configuration files that have documented syntax and even supports
graphical menus.
If you have an existing operating system and are looking to adding a real
bootable DOS to it, the easiest way I have done this is by adding another
physical drive, installing DOS onto it, making the drive bootable, and using
LILO menu to point to both operating sytems. The LILO created boot sector
still has to be on the BIOS boot drive. That is, unless you dont mind
switching the bootable drive in the BIOS, which I don't like to do personally.
The most perferrable for me has been to use MS-DOS under DOSBox or VirtualBox
and then run an MS-DOS server drive share and connect to that share from
Windows 7 or Vista. To get networking under DOSBox, you'll need a revision of
it with NE2000 support and WinPcap, or VirtualBox bridged network setup.
>
>When I tried to install 386Max, this went through the initial motions OK
>but when I tried to continue with MAXIMIZE the system locks up.
with MS-DOS?
I know that when running QEMM under MS-DOS 6.22 under DOSBox that stealth mode
didn't work because there was an INT that wasn't supported under DOSBox, but
it was able to complete, just without the stealth switch and it did optimize
memory nicely.
Charles
Auric__
May 14, 2012, 2:23:26 AM5/14/12
to
Rod Pemberton wrote:
> By CL, do you mean "command-line"? (yes...)
cl.exe is Microsoft's C compiler:
> By CL, do you mean "command-line"? (yes...)
C:\DOStools\MSCC\bin>cl
Microsoft (R) C Optimizing Compiler Version 5.10
Copyright (c) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights
reserved.
usage: cl [ option... ] filename... [ -link linkoption... ]
--
It's like dealing with children.
Robert AH Prins
May 14, 2012, 3:48:13 AM5/14/12
to
download Oracle's Virtalbox and use that to run DOS in a pure virtual
environment.
There are many flavours of DOS around on the internet, although some
might be a bit of work to install them. I'm using a legal version of
IBM's PC DOS 2000, and that works flawlessly, once you manage to install
it by tweaking the images that are included on the CD ROM, VB requires
them to be exactly 1,474,560 bytes, which means you need a hex editor (I
used HxD) to add a load of x'00's to the end of each image file.
Robert
--
Robert AH Prins
robert(a)prino(d)org
Geoff Barnard
May 14, 2012, 10:47:15 AM5/14/12
to
Further to messages, thanks for comments.
Just to clarify, yes the CL I mentioned should be CL.EXE which is the name
MS seem to give all their C compiler variants. It's the main prog for
the compiler, and I suspect that it may well call itself (at least once)
which may cause problems for stub loaders?
I understood that there were other DPMI progs, but I was thinking that DPMI
was a standard and that DPMI was DPMI. Maybe that is not so, and different
DPMI may work slightly differently, and as someone suggested different
processes might need the 'correct' DPMI interface. Certainly 386Max does
the job, and the compiler worked fine without 386Max at the DOS prompt of
Windows XP, so that is OK. The DPMI systems I've been trying just now say
on the screen that they are providing DMPI, with more DPMI memory than I know
what to do with, but CL.EXE complains 'DPMI not available'!!
I'll look into Oracle's VirtualBox and see what that does.
Thanks again, but questions still running!
Geoff
Just to clarify, yes the CL I mentioned should be CL.EXE which is the name
MS seem to give all their C compiler variants. It's the main prog for
the compiler, and I suspect that it may well call itself (at least once)
which may cause problems for stub loaders?
I understood that there were other DPMI progs, but I was thinking that DPMI
was a standard and that DPMI was DPMI. Maybe that is not so, and different
DPMI may work slightly differently, and as someone suggested different
processes might need the 'correct' DPMI interface. Certainly 386Max does
the job, and the compiler worked fine without 386Max at the DOS prompt of
Windows XP, so that is OK. The DPMI systems I've been trying just now say
on the screen that they are providing DMPI, with more DPMI memory than I know
what to do with, but CL.EXE complains 'DPMI not available'!!
I'll look into Oracle's VirtualBox and see what that does.
Thanks again, but questions still running!
Geoff
Herbert Kleebauer
May 14, 2012, 2:07:54 PM5/14/12
to
On 14.05.2012 16:47, Geoff Barnard wrote:
> I've had to get a new laptop, as the old SONY died. I was fine with that
> one, it had a built in floppy, and XP did some useful things.
> I've had to get a new laptop, as the old SONY died. I was fine with that
> one, it had a built in floppy, and XP did some useful things.
> I'll look into Oracle's VirtualBox and see what that does.
If it worked with XP on the old laptop you can install Windows XP
Mode on Windows 7 (Professional or Ultimate)
http://www.microsoft.com/windows/virtual-pc/default.aspx
This is a Windows Virtual PC with pre-installed XP on a virtual disk.
If you have only the Home version, you have to install Windows Virtual PC
http://www.microsoft.com/windows/virtual-pc/download.aspx
and then install XP yourself (you need a XP license).
I have just installed Windows Virtual PC and Win98 on a laptop (Windows 7
Home Premium). It is bit slow because the processor doesn't have
hardware virtualization and in opposite to XP you can access the
Win98 virtual disk from Win7 only when the Virtual PC is not running.
You have network support in Win98 and also can boot to DOS 7 only.
But there is a problem with the German keyboard: the AltGr key
doesn't work so you have to enter some keys (@[]\) using <ALT><NUM>.
Rugxulo
May 14, 2012, 8:10:00 PM5/14/12
to
Hi,
On May 13, 5:10 pm, "Geoff Barnard" <ge...@jgb17not.co.uk> wrote:
>
> Maybe I'm digging myself a deeper hole each time?
How so? I doubt it, compatibility is hard on anything, esp. across
machines as things just change too fast.
> I've had to get a new laptop, as the old SONY died. I was fine with that
> one, it had a built in floppy, and XP did some useful things.
A lot of XP machines seem to be "dying". I hate that. Yes, XP worked
better for DOS stuff than any Windows since then.
> The new one has no floppy, although I've got a USB one. It's got W7 mind
> you.
Ditto, I also have a USB floppy drive that works on my Win7
machine(s).
> I could do with having W7, as I've got a number of issues I need to check
> out with that, but the immediate problem is to run DOS progs, and most
> important to be mobile with my MS C7 compiler setup, Libs etc.
I take it that you aren't using the 32-bit version of Win7? The NTVDM
is buggy, but it's still there (mine are only 64-bit, blech, so I
don't have even that). The 32 MB DPMI limit is still there, but you
can "fix" that via a registry setting.
> On my main desktop PC there's no problem as that's a Pentium booting into
> DOS, and using 386Max which includes all reqs for the C7 stuff, in fact
> 386Max was supplied with the compiler.
What exact version of 386Max and compiler are we talking about? Note
that I'm just trying to iron out the details as I don't know anything
about those two products and have never used them.
> I spent some time playing with DosBox, and this seemed to get me nowhere
> with the DPMI. I find it appears very slow, OK I understand it's emulating
> a DOS prompt but it still seems slow.
DOSBox is a nice emulator, but it's (officially) "only for games", and
it requires a 1+ Ghz host machine just for fast 486 speeds. And yes,
it has bugs, I noticed one old 286 pmode DOS program (UCB Logo) didn't
work there. DJGPP (386+) stuff should run fine, though, but still
needs CWSDPMI or similar.
> I tried another tack. I can boot DOS on the floppy, and this gives a great
> DOS prompt. Cannot access the NTFS HD.
There are (were?) some third-party NTFS tools atop DOS, but they were
slow, SFN only, read-only, buggy, etc. Not reliable, IMO, but I didn't
test too hard as it was unimportant to me. To be honest, NTFS is
hidden behind proprietary walls, moreso because they want security to
be important, and accessing that via DOS would almost defeat the
purpose, I suppose.
> So I changed the HD setup, and gave
> myself a 2 Gb FAT partition, but DOS wouldn't see that.
As mentioned, make sure it was a primary, active FAT partition. I
think MS-DOS only allows it to be on the very first part of the drive
*and* first partition. Whether LBA is supported or not depends on your
version (MS-DOS 7+). DR-DOS 7.03 is vaguely more flexible in where you
install it, but it doesn't support LBA nor FAT32. The best most
flexible (that I've tried) is FreeDOS, both FAT32 and LBA are
supported there. (There are some server scripting bullcraps that have
IBM PC-DOS with alleged FAT32 support, but I've not bothered trying).
> Thought it might not.
> So, I tried DR-DOS, and this copes better with BIG HDs, and this does give
> me a DOS with the 2 Gb HD, and when I boot up into W7 I can still see the
> HD so that's more usefull.
FreeDOS supports FAT32 partitions (theoretically) up to 2 TB, but your
BIOS may or may not support that. I have a 4 GB FAT32 partition here,
but the individual file size is still (for FreeDOS) limited to 2 GB.
> When I tried to install 386Max, this went through the initial motions OK
> but when I tried to continue with MAXIMIZE the system locks up.
386Max is something like combination memory manager / EMM386 / DPMI? I
don't know. I think DPMIONE is loosely based upon it. And the
important point to mention here is that DPMIONE is GPLv3 nowadays
(though not actively developed, IIRC). So you could?? try updating to
it, but I personally doubt that will (directly) fix your problems. It
might?? be better to try simpler things first.
"
DPMIONE is, to my knowledge, the first publicly available standalone
DPMI 1.0 host. This program is an outgrowth of the DPMI 1.0 host which
first appeared in 386MAX from Qualitas, Inc. in 1992. As such, it has
undergone extensive testing in that commercial product before being
ported to this standalone program.
"
http://www.sudleyplace.com/dpmione/
How much RAM does your host computer have? I've noticed (in native
FreeDOS) that a lot of memory managers, extenders, DPMI hosts, etc.
don't exactly work perfectly with so much RAM. They all get confused
in one way or another in rare corner cases (though everything "more or
less" can be made to work well). There's a bunch of different DOS
extenders and DPMI hosts.
> 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.
DPMI 0.9 is the popular (286) variant used by Windows 3.0 on up. There
was DPMI 1.0 (386 variant), but it was more complicated and "mostly"
ignored (esp. since Windows didn't support it except for like one or
two calls, e.g. FPU or whatever). OS/2 supposedly supports 0.95 (not a
real version but their own way of doing halfway between the two
standards).
DPMI is awesome and extended the life of DOS by many years. But keep
in mind that they are "old" standards, hence they haven't exacty been
well-supported or updated lately (to say the least).
FYI, "DPMI" is not the same as a DOS extender. OpenWatcom uses
"extenders" to implement easier access to DOS calls behind the scenes.
DJGPP uses "pure" DPMI, i.e. only what is available from the standard,
no "extended int 21h API", and CWSDPMI only supports the 32-bit 0.9
part (plus one or two extras from 1.0), hence no 16-bit stuff (a la
BP7) nor extras are available. That may or may not be enough for your
app, it depends on what it wants. (E.g. The original DOS/4GW version
of Doom won't run under CWSDPMI verbatim, last I checked.)
> I've tried the JEMM process, this seems to work great and does a lot of
> what 386Max would do and again says I've now got DMPI. I test prog coming
> with djgpp says there's DPMI. A test prog coming with the HX system says
> DPMI is OK. But CL will NOT run. BLINKER will run fine, and I think that
> needs DPMI as well??
DJGPP v2 comes with GO32-V2.EXE, so you can run that to tell you how
much DPMI is (allegedly) available. Of course, that totally depends on
the DPMI host (CWSDPMI or PMODETSR or whatever), usually CWSDPMI auto-
loaded.
HX also has ..\TEST\DPMI.EXE to show some stats. A blind guess would
be for you to run "HDPMI16.EXE -r", then "HDPMI32.EXE -r", then try
your app. Hopefully then it will work no matter what (but dunno
without more info).
> Maybe I'm almost there, but CL is looking for something else?
Maybe. Depends on how much raw DPMI it needs or what specific standard
or if it relies on non-standard int 21h extensions.
> Does anyone have any suggestions? I've been looking for any prog that
> might 'test' DPMI and confirm that it is there, GO32 with djgpp says it IS.
But that probably runs CWSDPMI via the stub. You'll have to manually
run something else resident first to not rely on CWSDPMI.
> Anyone any ideas why 386Max might not work - the manual does refer to a
> lockup at the same point but is suggesting changing settings but my lockup
> is immed before anything else is set??
Old software and new machines don't always play nice. Lots of little
bugs and corner cases with big RAM machines.
> Feeling I'm very nearly there - could be something silly is missing. Maybe
> I cannot see the wood for a partic tree that's stuck in my face??
It's not as easy as other OSes that only have "one" (built-in) memory
management system.
> Any suggestions gratefully received.
>
> Geoff Barnard
... On to the next message (combined for simplicity)! :-)
On May 14, 9:47 am, "Geoff Barnard" <ge...@jgb17.co.uk> wrote:
> Further to messages, thanks for comments.
>
> Just to clarify, yes the CL I mentioned should be CL.EXE which is the name
> MS seem to give all their C compiler variants. It's the main prog for
> the compiler, and I suspect that it may well call itself (at least once)
> which may cause problems for stub loaders?
Make sure \HX\BIN is in your %PATH%. Also try this first:
set HDPMI=32
set DPMILDR=8
> I understood that there were other DPMI progs, but I was thinking that DPMI
> was a standard and that DPMI was DPMI.
DPMI can run atop 286 pmode or 386 pmode. And that's just for 0.9
(most popular). Anything using 1.0 is rarer but still possible (and
some people often implemented tiny bits from that too). OpenWatcom is
not a "pure" DPMI environment, hence it still needs an extender for
its apps (unlike DJGPPv2 which is 32-bit DPMI only, hence you don't
need or use CWSDPMI.EXE at all when under NTVDM or DOSEMU).
> Maybe that is not so, and different
> DPMI may work slightly differently, and as someone suggested different
> processes might need the 'correct' DPMI interface.
There is a test if the DPMI host supports 32-bit or not. Usually apps
check that and fail if not supported. Similarly for 16-bit apps, since
most DPMI hosts usually don't support 16-bit, they will just bomb out.
Hence you'll need BP7's RTM+DPMI16BI (or HDPMI16 or 386Max or DPMIONE
or whatever) if you want to run those, esp. in pure DOS.
> Certainly 386Max does
> the job, and the compiler worked fine without 386Max at the DOS prompt of
> Windows XP, so that is OK.
WinXP only supports DPMI 0.9, but they've deprecated it, and they
don't seem to fix any bugs anymore. It's very ancient code for them,
and Win64 lacks NTVDM at all. Back in the day, Win 3.0 was the first
to support DPMI 0.9 in 1990, and they never changed much since then.
The 16-bit pmode Windows .EXEs back then actually used DPMI behind the
scenes, I think!
> The DPMI systems I've been trying just now say
> on the screen that they are providing DMPI, with more DPMI memory than I know
> what to do with, but CL.EXE complains 'DPMI not available'!!
XP lies. Vista and Win7 really badly lie. The total amount is almost
useless as many don't report accurate numbers (or host cpu or ...). If
it can't find what it's looking for, it won't work. Even *if* you have
everything properly set up, it may not work due to bugs or
incompatibilities. Sorry.
Though I'm not saying give up, it can probably be worked around or
patched, but it will just take a bit of investigating (as my minimal
experience has shown).
> I'll look into Oracle's VirtualBox and see what that does.
VirtualBox works, more or less, but without VT-X it's buggy and very
very slow. If at all possible, if your computer supports VT-X, you'll
be fine. Otherwise, I dunno. I multi-boot between FreeDOS, Linux
(DOSEMU) and Win64 + VirtualBox + VT-X and sometimes use DOSBox. But
there is no perfect answer. Perhaps QEMU or BOCHS would work better,
sometimes they have (different) bugs and successes.
> Thanks again, but questions still running!
>
> Geoff
Good luck! And feel free to keep us updated on your status.
On May 13, 5:10 pm, "Geoff Barnard" <ge...@jgb17not.co.uk> wrote:
>
> Maybe I'm digging myself a deeper hole each time?
machines as things just change too fast.
> I've had to get a new laptop, as the old SONY died. I was fine with that
> one, it had a built in floppy, and XP did some useful things.
better for DOS stuff than any Windows since then.
> The new one has no floppy, although I've got a USB one. It's got W7 mind
> you.
machine(s).
> I could do with having W7, as I've got a number of issues I need to check
> out with that, but the immediate problem is to run DOS progs, and most
> important to be mobile with my MS C7 compiler setup, Libs etc.
is buggy, but it's still there (mine are only 64-bit, blech, so I
don't have even that). The 32 MB DPMI limit is still there, but you
can "fix" that via a registry setting.
> On my main desktop PC there's no problem as that's a Pentium booting into
> DOS, and using 386Max which includes all reqs for the C7 stuff, in fact
> 386Max was supplied with the compiler.
that I'm just trying to iron out the details as I don't know anything
about those two products and have never used them.
> I spent some time playing with DosBox, and this seemed to get me nowhere
> with the DPMI. I find it appears very slow, OK I understand it's emulating
> a DOS prompt but it still seems slow.
it requires a 1+ Ghz host machine just for fast 486 speeds. And yes,
it has bugs, I noticed one old 286 pmode DOS program (UCB Logo) didn't
work there. DJGPP (386+) stuff should run fine, though, but still
needs CWSDPMI or similar.
> I tried another tack. I can boot DOS on the floppy, and this gives a great
> DOS prompt. Cannot access the NTFS HD.
slow, SFN only, read-only, buggy, etc. Not reliable, IMO, but I didn't
test too hard as it was unimportant to me. To be honest, NTFS is
hidden behind proprietary walls, moreso because they want security to
be important, and accessing that via DOS would almost defeat the
purpose, I suppose.
> So I changed the HD setup, and gave
> myself a 2 Gb FAT partition, but DOS wouldn't see that.
think MS-DOS only allows it to be on the very first part of the drive
*and* first partition. Whether LBA is supported or not depends on your
version (MS-DOS 7+). DR-DOS 7.03 is vaguely more flexible in where you
install it, but it doesn't support LBA nor FAT32. The best most
flexible (that I've tried) is FreeDOS, both FAT32 and LBA are
supported there. (There are some server scripting bullcraps that have
IBM PC-DOS with alleged FAT32 support, but I've not bothered trying).
> Thought it might not.
> So, I tried DR-DOS, and this copes better with BIG HDs, and this does give
> me a DOS with the 2 Gb HD, and when I boot up into W7 I can still see the
> HD so that's more usefull.
BIOS may or may not support that. I have a 4 GB FAT32 partition here,
but the individual file size is still (for FreeDOS) limited to 2 GB.
> When I tried to install 386Max, this went through the initial motions OK
> but when I tried to continue with MAXIMIZE the system locks up.
don't know. I think DPMIONE is loosely based upon it. And the
important point to mention here is that DPMIONE is GPLv3 nowadays
(though not actively developed, IIRC). So you could?? try updating to
it, but I personally doubt that will (directly) fix your problems. It
might?? be better to try simpler things first.
"
DPMIONE is, to my knowledge, the first publicly available standalone
DPMI 1.0 host. This program is an outgrowth of the DPMI 1.0 host which
first appeared in 386MAX from Qualitas, Inc. in 1992. As such, it has
undergone extensive testing in that commercial product before being
ported to this standalone program.
"
http://www.sudleyplace.com/dpmione/
How much RAM does your host computer have? I've noticed (in native
FreeDOS) that a lot of memory managers, extenders, DPMI hosts, etc.
don't exactly work perfectly with so much RAM. They all get confused
in one way or another in rare corner cases (though everything "more or
less" can be made to work well). There's a bunch of different DOS
extenders and DPMI hosts.
> 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.
was DPMI 1.0 (386 variant), but it was more complicated and "mostly"
ignored (esp. since Windows didn't support it except for like one or
two calls, e.g. FPU or whatever). OS/2 supposedly supports 0.95 (not a
real version but their own way of doing halfway between the two
standards).
DPMI is awesome and extended the life of DOS by many years. But keep
in mind that they are "old" standards, hence they haven't exacty been
well-supported or updated lately (to say the least).
FYI, "DPMI" is not the same as a DOS extender. OpenWatcom uses
"extenders" to implement easier access to DOS calls behind the scenes.
DJGPP uses "pure" DPMI, i.e. only what is available from the standard,
no "extended int 21h API", and CWSDPMI only supports the 32-bit 0.9
part (plus one or two extras from 1.0), hence no 16-bit stuff (a la
BP7) nor extras are available. That may or may not be enough for your
app, it depends on what it wants. (E.g. The original DOS/4GW version
of Doom won't run under CWSDPMI verbatim, last I checked.)
> I've tried the JEMM process, this seems to work great and does a lot of
> what 386Max would do and again says I've now got DMPI. I test prog coming
> with djgpp says there's DPMI. A test prog coming with the HX system says
> DPMI is OK. But CL will NOT run. BLINKER will run fine, and I think that
> needs DPMI as well??
much DPMI is (allegedly) available. Of course, that totally depends on
the DPMI host (CWSDPMI or PMODETSR or whatever), usually CWSDPMI auto-
loaded.
HX also has ..\TEST\DPMI.EXE to show some stats. A blind guess would
be for you to run "HDPMI16.EXE -r", then "HDPMI32.EXE -r", then try
your app. Hopefully then it will work no matter what (but dunno
without more info).
> Maybe I'm almost there, but CL is looking for something else?
or if it relies on non-standard int 21h extensions.
> Does anyone have any suggestions? I've been looking for any prog that
> might 'test' DPMI and confirm that it is there, GO32 with djgpp says it IS.
run something else resident first to not rely on CWSDPMI.
> Anyone any ideas why 386Max might not work - the manual does refer to a
> lockup at the same point but is suggesting changing settings but my lockup
> is immed before anything else is set??
bugs and corner cases with big RAM machines.
> Feeling I'm very nearly there - could be something silly is missing. Maybe
> I cannot see the wood for a partic tree that's stuck in my face??
management system.
> Any suggestions gratefully received.
>
> Geoff Barnard
On May 14, 9:47 am, "Geoff Barnard" <ge...@jgb17.co.uk> wrote:
> Further to messages, thanks for comments.
>
> Just to clarify, yes the CL I mentioned should be CL.EXE which is the name
> MS seem to give all their C compiler variants. It's the main prog for
> the compiler, and I suspect that it may well call itself (at least once)
> which may cause problems for stub loaders?
set HDPMI=32
set DPMILDR=8
> I understood that there were other DPMI progs, but I was thinking that DPMI
> was a standard and that DPMI was DPMI.
(most popular). Anything using 1.0 is rarer but still possible (and
some people often implemented tiny bits from that too). OpenWatcom is
not a "pure" DPMI environment, hence it still needs an extender for
its apps (unlike DJGPPv2 which is 32-bit DPMI only, hence you don't
need or use CWSDPMI.EXE at all when under NTVDM or DOSEMU).
> Maybe that is not so, and different
> DPMI may work slightly differently, and as someone suggested different
> processes might need the 'correct' DPMI interface.
check that and fail if not supported. Similarly for 16-bit apps, since
most DPMI hosts usually don't support 16-bit, they will just bomb out.
Hence you'll need BP7's RTM+DPMI16BI (or HDPMI16 or 386Max or DPMIONE
or whatever) if you want to run those, esp. in pure DOS.
> Certainly 386Max does
> the job, and the compiler worked fine without 386Max at the DOS prompt of
> Windows XP, so that is OK.
don't seem to fix any bugs anymore. It's very ancient code for them,
and Win64 lacks NTVDM at all. Back in the day, Win 3.0 was the first
to support DPMI 0.9 in 1990, and they never changed much since then.
The 16-bit pmode Windows .EXEs back then actually used DPMI behind the
scenes, I think!
> The DPMI systems I've been trying just now say
> on the screen that they are providing DMPI, with more DPMI memory than I know
> what to do with, but CL.EXE complains 'DPMI not available'!!
useless as many don't report accurate numbers (or host cpu or ...). If
it can't find what it's looking for, it won't work. Even *if* you have
everything properly set up, it may not work due to bugs or
incompatibilities. Sorry.
Though I'm not saying give up, it can probably be worked around or
patched, but it will just take a bit of investigating (as my minimal
experience has shown).
> I'll look into Oracle's VirtualBox and see what that does.
very slow. If at all possible, if your computer supports VT-X, you'll
be fine. Otherwise, I dunno. I multi-boot between FreeDOS, Linux
(DOSEMU) and Win64 + VirtualBox + VT-X and sometimes use DOSBox. But
there is no perfect answer. Perhaps QEMU or BOCHS would work better,
sometimes they have (different) bugs and successes.
> Thanks again, but questions still running!
>
> Geoff
Geoff Barnard
May 15, 2012, 6:40:29 PM5/15/12
to
Further to messages..
I sent an email to Japheth connected with both the JEMM (emm variant)
and the HX process (DPMI process) and got it sorted out.
I was missing something, and assuming other things.
With the JEMM process installed, there is in fact NO DPMI active, so
messages I was getting to show DPMI were something else (the prog
giving the message was talking about something else, not the main
process).
So I DO need to run the separate DPMI process, but I kept trying the
TSR version as I thought I needed to do that (as CL.EXE calls other
things, I understood). But, the TSR version seems NOT to work on my
machine, whereas if I run the non-TSR variant and then IMMED run CL
then CHEERS it works fine and my compile & link runs fine. I was
doing the compile & link from a .BAT file, and this was doing
something else inbetween (a little prog to compare file dates) and
this was causing a problem.
Now I'm OK, all sorted!
I was pretty close all along. No need for Virtual anything.
Thanks for messages.
Geoff Barnard, Guisborough, England
I sent an email to Japheth connected with both the JEMM (emm variant)
and the HX process (DPMI process) and got it sorted out.
I was missing something, and assuming other things.
With the JEMM process installed, there is in fact NO DPMI active, so
messages I was getting to show DPMI were something else (the prog
giving the message was talking about something else, not the main
process).
So I DO need to run the separate DPMI process, but I kept trying the
TSR version as I thought I needed to do that (as CL.EXE calls other
things, I understood). But, the TSR version seems NOT to work on my
machine, whereas if I run the non-TSR variant and then IMMED run CL
then CHEERS it works fine and my compile & link runs fine. I was
doing the compile & link from a .BAT file, and this was doing
something else inbetween (a little prog to compare file dates) and
this was causing a problem.
Now I'm OK, all sorted!
I was pretty close all along. No need for Virtual anything.
Thanks for messages.
Geoff Barnard, Guisborough, England
0 new messages