On May 13, 5:10 pm, "Geoff Barnard" <ge...@jgb17not.co.uk
> 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
Ditto, I also have a USB floppy drive that works on my Win7
> 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.
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
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-
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
> 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
> 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:
> 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
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!
Good luck! And feel free to keep us updated on your status.