At 12:01 AM 2/11/2005 +0100, Bernd Blaauw wrote:
Michael Devore schreef:I don't have a clue how this would work, but it sounds a terrible idea.
MS manages to pull it off (loading XMSMMGR.EXE), in order to load Smartdrv on a clean booted system. Nothing advanced further on (EMM386 ofcourse won't work if no HIMEM loaded in config.sys).
Should stay a 'hidden' feature if it would be implemented, as it's not for 'day-to-day use'.
XMS manager is not the sort of thing you stick in after other device drivers have loaded. There's little to no way to make sure you don't stomp on already loaded drivers. The XMS/HMA driver needs a clean memory map to operate. Same goes for turning XMS off after it's been turned on. Where do the drivers already loaded in extended memory go?
Only XMS access, HMA access is not necessary, as hardly any software other than DOS kernels use the HMA. You may assume a clean booted OS without drivers..just need to be able to load/enable XMS in config.sys
Something TDSK does might be the idea:
-load driver in config.sys
-resize amount of RAM that it has access to.
XMSDSK does the same, actually.
case of MEMTEST which appears to need bare metal access, the problem is that you can't expect it to ever co-exist with a memory manager in the same operating session.
Eric wrote a 'exe-wrapper' for Memtest+, allowing it to be loaded from commandline (and UPX the binary to save space). Unfortunately there's no warning 'Can't start, XMS driver was loaded!', just a crash.
What's wrong with that? Checking driver name is the right way to see if there is an loaded and active XMS driver. In fact, for EMS that's a documented EMS specification method to check for whether an EMS driver can be used by an application.
Other way is: if XMS is available, then an XMS driver was loaded and active. Something I assume the MEM program does. the mentioned XMSMMGR.EXE program does not have XMSXXXX0 signature, but something else, which means I would have to check for multiple names.
Simplest is: hey, a few KB of XMS are available, so XMS driver was loaded.
HIMEM.EXE /IS_THERE_ANY_XMS? if errorlevel 1 echo HIMEM or other XMS driver was not loaded! if not errorlevel 1 echo XMS driver loaded and active
EMS specification method? You mean the *2* names (something with an X turning into a Q when switching from 'NOEMS' to 'EMS') ?
No, not 2 names. The second name turns EMS off, because it doesn't match any more. NOEMS is literally NO EMS.
I'm sorry. I just don't see how this dynamic HIMEM idea would work or any need for it. XMSDSK's dynamically resizing memory issue is trivial in comparison. Trying to temporarily turn off HIMEM would be just a nasty process. HIMEM is not comparable to a simple device driver or TSR.
What _exactly_ do you want to do that makes you want to turn off XMS? I can't help but think there's a better way to handle whatever you want than gutting the XMS driver. We're programmers, we have the technology to make it better. We can rebuild the $6M FreeDOS.
------------------------------------------------------- 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
