Hi, thanks for figuring out the problem :-). > Good for you, you win a chocolate chip cookie. IF there is a free XMS > block less than 4K in size, and IF that XMS block is listed first in the > free handles, and IF that XMS block has a non-4K alignment such that (4 - > alignment modulo 4 ) > block size, THEN there will be an underflow with > EMM386 2.01 when allocating a new XMS block for EMS/VCPI.
> The RAMDISK you use happens to do this very thing with XMS. After > allocating the RAMDISK area, it leaves behind a 1K block at an odd > address. Don't know why, but it doesn't matter. I think this is because it allocates "size of largest free block minus (size of ramdisk plus 1 kilobyte)" of XMS before actually allocating the XMS for the ramdisk, probably to force the ramdisk to be on the "right end" of the memory range. > I'll upload a 2.02 fix in a few days. It is not critical for the large > majority of users who won't encounter the problem. Thanks. Could you, instead of sending a cookie, include RDTSC emulation in that version? I think I would be overstretching my luck if I asked for "display a warning if int 2f.4309 is not supported and memory pool sharing is supposed to initialize"? Even if I predict that this warning will help to avoid stupid user questions like "I used FD EMM386 with the HIMEM of MS Win3.1 and now I have only 128k of EMS free?" ;-) ...? Thanks :-)). PS: I assume you deliberately put the IDT and a good amount of stack space into DOS-accessible RAM to ease debugging? Otherwise you could save something like 0.5 + 0.2 kB of DOS RAM footprint (current: 3.3k). Eric ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
