Hi Tom, good point - after HIMEM / EMM386 are loaded, there is *usually* (unless you use some "keep N kilobytes of int 15 memory free" switch!) no int 15 memory left visible to other programs. However:
> EMM386 won't even load without HIMEM present. > thus noone is allowed to call int 15.87 when emm386 is loaded. I would not be that sure ;-). FDAPM uses int 15.87 to access the BIOS ACPI tables, which works 1. fine and 2. without the memcheck option (which you only need if you want to access a non-RAM area, e.g. a framebuffer, by int 15.87, while most framebuffer/...-accessing programs use protected mode and their own page tables anyway). While FDAPM might be an exception - use 4 GB access space but without running in protected mode all the time - some drivers with MMIO access *can* need memcheck option unless they run in protected mode (USB and PCI sound drivers often do run in protected mode...). The mere existence of the memcheck option tells us that int 15.87 is actually used by programs, and sometimes even to access non-RAM address space. Even if only normal RAM is accessed, such programs will want a non-buggy int 15.87 around. Eric PS: FDAPM is a com file, so DS=ES, so it works even with the buggy EMM386-internal int 15.87 X-). ------------------------------------------------------- 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
