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
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.
Andreas,
Quote from: japheth on July 11, 2013, 02:34:25 AM
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
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
Quote from: Gunther on July 11, 2013, 03:51:59 AM
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.
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.
Michael,
thank you for your tests. It's a great help. :t
Gunther
Hi Andreas,
Quote from: japheth on July 11, 2013, 02:49:48 PM
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
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
Andy,
Quote from: Magnum on July 24, 2013, 12:54:29 PM
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.
Quote from: Magnum on July 24, 2013, 12:54:29 PM
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. (http://www.masmforum.com/board/index.php?topic=14762.0) 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
Quote from: Magnum on July 24, 2013, 12:54:29 PM
4 Gb Ram, but Windows only shows 3 even though BIOS sees it. :-(
It seems you've encountered a 3 GB barrier (http://en.wikipedia.org/wiki/3_GB_barrier) .
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
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.
Quote from: Gunther on July 24, 2013, 01:41:15 AM
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.
Quote from: Gunther on July 24, 2013, 11:28:45 PM
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.
Andreas,
Quote from: japheth on July 25, 2013, 03:18:58 PM
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.
I'll check the XMS status and post the results.
Steve,
Quote from: FORTRANS on July 25, 2013, 10:04:37 PM
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.
Nothing offending, I've used Warp 3 and Warp 4 in the 90s for a long time and it was a good operating system with rock solid preemptive multitasking. The only point was the driver question for new hardware. And again, the DOS emulation was very good.
Gunther
Andreas,
that's what xmsstat brings.
XMS call address: 020A:00CF
XMS version: 3.0
HMA handled by XMS host, HMA is allocated
largest free memory block (v2) in kB: 65535, total free: 65535
largest free memory block (v3) in kB: 3627508, total free: 3640652
XMS handle table at FFFB:CC90, handle cnt/size=48/10
XMS handle array at FFFB:D58E
no handle region size(kB) locks flags
--------------------------------------------------------
1 D58E 00110000-00110FFF 4 1 02 used
2 D598 DD793000-DD796FFF 16 0 01 free
3 D5A2 DE07A000-DED3DFFF 13072 0 01 free
4 D5AC DEFF2000-DEFFFFFF 56 0 01 free
5 D5B6 00111000-DD78DFFF 3627508 0 01 free
--------------------------------------------------------
3640656
free handles: 43
no UMB handler installed
Gunther
Quote from: Gunther on July 26, 2013, 12:17:23 AM
that's what xmsstat brings.
Thanks! As I did suspect, there are a few "holes" in XMS memory. I edited your list a bit to make it more clear:
1 D58E 00110000-00110FFF 4 used
5 D5B6 00111000-DD78DFFF 3627508 free
DD78E000-DD792FFF 20 ACPI
2 D598 DD793000-DD796FFF 16 free
DD797000-DE079FFF 9100 ACPI?
3 D5A2 DE07A000-DED3DFFF 13072 free
DED3E000-DEFF1FFF 2768 ACPI?
4 D5AC DEFF2000-DEFFFFFF 56 free
I doubt that ACPI really needs 9100 or 2768 kB of memory, but somehow those memory ranges aren't free to use on your machine.
However, this is of course no excuse for hdpmi to fail. I checked the program source ( it has been a while since the last time ) and did indeed found a "quirk". Attached is a modified version of HDPMI32 which has a good probability to work with your original program.
If you can test it, please tell the results and if it works, I will add the modifications to the standard hdpmi included in HX.
Andreas,
it seems that you've found the little quirk. The program can now allocate the entire reported free memory block. Works fine. Thank you. :t
Gunther
Quote from: Gunther on July 26, 2013, 04:54:49 AM
it seems that you've found the little quirk. The program can now allocate the entire reported free memory block.
Thanks for the feedback!
HX has been updated with the modified HDPMI.
Hi Andreas,
Quote from: japheth on July 28, 2013, 03:58:54 AM
HX has been updated with the modified HDPMI.
that's good news; thank you for the fast bug fix and update.
Gunther