DOS ain't dead

I've briefly mentioned this before but didn't quite understand it. Anyways, loading HDPMI32 with only XMS (no EMS) says, "Insufficient memory" for me, but only on DR-DOS! (I just tested by 486 to be sure, and it works fine with stock MS-DOS 6.22 HIMEM.SYS XMS v3 even with only 8 MB RAM total.) Previously I just did "if exist EMMXXXX0 lh hxldr32" to avoid the issue since it didn't work, but now I know how to make it work, apparently (set HDPMI=64 to avoid XMS v3).

This is what happens on my P166 (most likely because both HIMEM.SYS and EMM386.EXE from DR-DOS 7.03 lie about supporting XMS v3):


[ DR-DOS ] Fri  3-27-2009>set HDPMI=

[ DR-DOS ] Fri  3-27-2009>hdpmi32
HDPMI32: insufficient memory

[ DR-DOS ] Fri  3-27-2009>memid
XMS 3.0

[ DR-DOS ] Fri  3-27-2009>set HDPMI=64

[ DR-DOS ] Fri  3-27-2009>hdpmi32

[ DR-DOS ] Fri  3-27-2009>memid
DPMI 0.9 XMS 3.0

[ DR-DOS ] Fri  3-27-2009>v /v \drdos\himem.sys

himem    sys       14,766             Jan,07,1999   07:03:00am   A...

[ DR-DOS ] Fri  3-27-2009>scrndump xms3_hx.txt


Slightly silly that MS-DOS 6.22 (1993-4) is better than DR-DOS 7.03 (1998-9) in this regard. And for the record, I usually use JEMMEX, but when I (rarely) boot to XMS only via CONFIG.SYS option, I typically just use the stock one instead of HIMEMX, for whatever reason. Oh well, just felt like mentioning this since it always bugged me.

> Slightly silly that MS-DOS 6.22 (1993-4) is better than DR-DOS 7.03
> (1998-9) in this regard. And for the record, I usually use JEMMEX, but
> when I (rarely) boot to XMS only via CONFIG.SYS option, I typically just
> use the stock one instead of HIMEMX, for whatever reason.

I can't see any valid reason for preferring crappy DR.HIMEM.SYS over HIMEMX. So this seems to be a non-issue.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Slightly silly that MS-DOS 6.22 (1993-4) is better than DR-DOS 7.03
> > (1998-9) in this regard. And for the record, I usually use JEMMEX, but
> > when I (rarely) boot to XMS only via CONFIG.SYS option, I
> typically just
> > use the stock one instead of HIMEMX, for whatever reason.
>
> I can't see any valid reason for preferring crappy DR.HIMEM.SYS over
> HIMEMX. So this seems to be a non-issue.

In particular, I've heard that you have to use a better HIMEM if you want to use > 64 MB of RAM w/ DR-DOS (although still limited to 64 MB per process in /MULTI due to hardcoded limits).

Anyways, I didn't say it wasn't moot, just that it was fairly strange behavior. Maybe for best compatibility HX should try XMS 2.0 calls by default if the 3.0 ones fail.

> Anyways, I didn't say it wasn't moot, just that it was fairly strange
> behavior. Maybe for best compatibility HX should try XMS 2.0 calls by
> default if the 3.0 ones fail.

The most robust strategy probably is to generally use xms v2 calls whenever the block of memory to allocate is < 64 MB.

You can modify the source yourself, it's in pagemgr.asm, procedure allocxms.

---
MS-DOS forever!

> > Anyways, I didn't say it wasn't moot, just that it was fairly strange
> > behavior. Maybe for best compatibility HX should try XMS 2.0 calls by
> > default if the 3.0 ones fail.
>
> The most robust strategy probably is to generally use xms v2 calls
> whenever the block of memory to allocate is < 64 MB.
>
> You can modify the source yourself, it's in pagemgr.asm, procedure
> allocxms.

Why would I do that when I can take the lazy way out? (Besides, you know I suck at programming.)

1). use HIMEMX, or
2). "set HDPMI=64"

> Why would I do that when I can take the lazy way out? (Besides, you know I
> suck at programming.)

Because the broad and easy way is the way to hell.

---
MS-DOS forever!

> Because the broad and easy way is the way to hell.

Or you can just go to YouTube. Seems "Hell" is highly overrated (but was probably considered cool back in 1993).