The MASM Forum

Miscellaneous => 16 bit DOS Programming => Topic started by: Gunther on July 11, 2013, 01:48:32 AM

Title: DOS extender problem
Post by: Gunther on July 11, 2013, 01:48:32 AM
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
Title: Re: DOS extender problem
Post by: 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.
Title: Re: DOS extender problem
Post by: Gunther on July 11, 2013, 03:51:59 AM
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
Title: Re: DOS extender problem
Post by: Magnum on July 11, 2013, 12:20:21 PM
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
Title: Re: DOS extender problem
Post by: japheth on July 11, 2013, 02:49:48 PM
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.
Title: Re: DOS extender problem
Post by: MichaelW on July 11, 2013, 03:58:54 PM
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.

Title: Re: DOS extender problem
Post by: Gunther on July 14, 2013, 09:36:25 AM
Michael,

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

Gunther
Title: Re: DOS extender problem
Post by: Gunther on July 24, 2013, 01:41:15 AM
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
Title: Re: DOS extender problem
Post by: Magnum on July 24, 2013, 12:54:29 PM
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
Title: Re: DOS extender problem
Post by: Gunther on July 24, 2013, 11:28:45 PM
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. (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
Title: Re: DOS extender problem
Post by: GoneFishing on July 24, 2013, 11:43:04 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) .
Title: Re: DOS extender problem
Post by: dedndave on July 25, 2013, 01:57:18 AM
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
Title: Re: DOS extender problem
Post by: Magnum on July 25, 2013, 10:39:42 AM
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.

Title: Re: DOS extender problem
Post by: japheth on July 25, 2013, 03:18:58 PM
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.
Title: Re: DOS extender problem
Post by: FORTRANS on July 25, 2013, 10:04:37 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.
Title: Re: DOS extender problem
Post by: Gunther on July 25, 2013, 11:50:18 PM
Andreas,

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,

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
Title: Re: DOS extender problem
Post by: Gunther on July 26, 2013, 12:17:23 AM
Andreas,

that's what xmsstat brings.

Code: [Select]
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
Title: Re: DOS extender problem
Post by: japheth on July 26, 2013, 01:06:58 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:

Code: [Select]
  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.
Title: Re: DOS extender problem
Post by: Gunther on July 26, 2013, 04:54:49 AM
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
Title: Re: DOS extender problem
Post by: japheth on July 28, 2013, 03:58:54 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.
Title: Re: DOS extender problem
Post by: Gunther on July 29, 2013, 12:13:44 AM
Hi Andreas,

HX has been updated with the modified HDPMI.

that's good news; thank you for the fast bug fix and update.

Gunther