DOS extender problem

[Gunther]

The attached archive contains a 32 bit Protected Mode example (DPMI based). It's assembled with TASM, but it should also work with jWasm and MASM. I've used TLINK, but another linker will probably do the job. Please check the batch file for building the running EXE.

The program checks the available extended memory, allocates that amount of memory, fills the memory with values and reads the values back for printing at the text screen. That's all.

But the behaviour is a bit strange. It works fine under Windows XP, the XP emulation under VirtualPC, and under DOSBox 0.74. But under plain DOS are some problems. With Borlands DPMI host 32RTM.EXE it works fine; but that host manages only 64 MB of extended memory.

The HX DOS extender by Andreas (Japheth) doesn't allow to allocate the available memory and fails, but works fine under DOSBox with a small amount of memory.

CW Sandmann's extender (CWSDPMI) has a similar behaviour, but allows the allocation and then simply hangs, but works fine under DOSBox.

I've no idea what's going on here. Perhaps it has to do with the large amount of installed RAM and the sources of those extenders are a few years old. Or has the DPMI client to lock the memory before using it?

Could someone test the application under other configurations? Who knows a good extender which is working under plain DOS?

Gunther

[japheth]

I tried with hdpmi32 and it seems to work ( I interrupted because the available memory of 3.5 GB took an eternity to be "read )

With "hdpmi32 -x" one can restrict the memory usage to 256 MB and this time I had enough patience to run it until it ended voluntarily.

[Gunther]

Andreas,

I tried with hdpmi32 and it seems to work ( I interrupted because the available memory of 3.5 GB took an eternity to be "read )

With "hdpmi32 -x" one can restrict the memory usage to 256 MB and this time I had enough patience to run it until it ended voluntarily.

yes, with 3.5 GB RAM it'll take a while. But hdpmi32 failed by the allocation of RAM (at least with my configuration - only HIMEM.SYS installed). What's wrong?

Gunther

[Magnum]

Forgive your enemies, but never forget their names.

I find that not worrying about their names results in more peace for myself.

Guten Nacht,
                      Andy

[japheth]

But hdpmi32 failed by the allocation of RAM (at least with my configuration - only HIMEM.SYS installed). What's wrong?

Impossible to tell with the current information.

First step: run tool DPMI.EXE ( should be located in HX\TEST ). It has a -m cmdline switch, which makes it allocate the largest memory block. If this works, then there's a bug in your program. If it fails, there's an "unusual" memory configuration on your machine.

[MichaelW]

System1, Windows XP SP3 512 MB, 15MB, OK

System2: Windows XP SP3 512 MB, 8MB, OK

System3: Windows ME 256 MB, 253MB, OK

System3: MS-DOS 6.22, 256 MB, HDPMI, 254MB, OK
Read back starts at ~~0 and ends at 268156924.

System3: MS-DOS 6.22, 2506 MB, CWSDPMI, 255MB, OK
Read back starts at ~~260000000 and ends at 535822332.

[Gunther]

Michael,

thank you for your tests. It's a great help.  :t

Gunther

[Gunther]

Hi Andreas,

Impossible to tell with the current information.

First step: run tool DPMI.EXE ( should be located in HX\TEST ). It has a -m cmdline switch, which makes it allocate the largest memory block. If this works, then there's a bug in your program. If it fails, there's an "unusual" memory configuration on your machine.

I had a few interesting debugging sessions. I'm sure that my program works properly. HDPMI32 works properly, for example, under DOSBox 0.74 with limited memory. On the other hand, there are problems under plain DOS with HIMEM.SYS installed. Function 500h (Get Free Memory Information) returns for the largest available free block in bytes: 3724304384. But it's impossible to allocate that memory block. The largest block to allocate has a size of 3710524288 bytes. The allocation of 3711048576 bytes failed.

I've changed the source. The application allocates now only half of the free block. Starting with line 215 in EX.ASM I've added comments for testing the allocation behaviour. Please let me know what else you would need for an error report.

Gunther

[Magnum]

Gunther,

It worked on XP Sp3 fine and ran fast. 15 Mb

4 Gb Ram, but Windows only shows 3 even though BIOS sees it. :-(

Andy

[Gunther]

Andy,

It worked on XP Sp3 fine and ran fast. 15 Mb

yes, of course. XP has a lousy DOS emulation and it gives me 15 MB extended memory - not a byte more. The Win98 DOS emulation was much better. OS/2 had an excellent DOS emulation, but that's over.

4 Gb Ram, but Windows only shows 3 even though BIOS sees it. :-(

Andy

I think that has to do with the Windows memory management. An application can have 2 GB RAM, not more. There are several tricks described via the web to overcome that limitations. You'll have to patch some registry entries etc. But I can't remember the source.

I've solved the problem in that way. We had a thread in the old forum. I made an USB stick with the described HP tool and can start a native real mode DOS from that drive (my BIOS allows the start from USB drives). That DOS has some limitations; it can't "see" my modern DVD drive and has no USB support, becasuse I'm to lazy to write the appropriate drivers. But for testing purposes it is okay.

Gunther

[GoneFishing]

4 Gb Ram, but Windows only shows 3 even though BIOS sees it. :-(

It seems you've encountered a 3 GB barrier .

[dedndave]

you can alter your boot.ini file to make it see 4
but, i doubt there is any big advantage to it
in fact, the disadvantages may outweigh the advantages

[Magnum]

Even though my XP is 32 bit, PAE is enabled.

I have the hardware for a 64 bit o.s.

Tried using  /3Gb in boot.ini with no luck.

[japheth]

Please let me know what else you would need for an error report.

Hello Gunther,

you'll need to tell more details about the XMS status. My guess is that your machine has one or two "memory holes", caused by ACPI, which then results in scattered XMS memory blocks.

Attached is tool XMSSTAT ( binary + source, was included in jemm ), which will display the XMS status.

[FORTRANS]

yes, of course. XP has a lousy DOS emulation and it gives me 15 MB extended memory - not a byte more. The Win98 DOS emulation was much better. OS/2 had an excellent DOS emulation, but that's over.

Hi,

   Well, mostly.  As a curiosity, OS/2 has been updated and is being
sold as eComstation.

http://www.ecomstation.com/

Aside from being interesting, and it works, I am not sure why
most people would care.  I use an old OS/2 Warp system more
than the eCs system I have.

Regards,

Steve N.