At 02:58 PM 2/20/2005 +0100, Eric Auer wrote:
> Similar to the way Disney's Aladdin program does on >32M of XMS, > causing Aladdin to fail on higher memory machines unless HIMEM's /MAX > option is used or external XMS allocations are made...
Leads to a popular problem: Where exactly (I think we use fbc0 kbytes, 64 MBy - (1024+64 kBy base+HMA)) do programs which understand both XMS 2 and XMS 3 usually expect the limit to be? The fbc0 is exactly the biggest plausible value for a system which really has 64 MB RAM and no "memory hole" (of 384k in the UMB area), so it looks nice, but I guess not all MEM style tools get their calculations right / realize that they should use XMS 3. Whatever. Several tools turned out to be plain buggy. No our prob.
If the XMS 2.0 signed check bug occurs in more programs than Aladdin, it might be useful to introduce a /2MAX32 option in HIMEM. I hate the *nix approach of having 600 options and suboptions for a utility, but if problem is common, a simple correcting parameter makes sense to help out users. HIMEM's current /MAX=32M option limits actual memory to 32M instead of only reported memory and kills out >32M XMS 3.0 as well, which is very much overkill for what is needed.
I don't know of any other DOS program which has this interpretation bug so it may not be necessary. Certainly we don't want to generally limit the XMS 2.0 free memory call to 32M, since it halves the 63M maximum for those programs which use the returned amount properly. And there are definitely XMS 2.0-using programs which do that.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
