Hi Aitor, on your question "why cannot you DEVLOAD HIMEM or EMM386", which is similar to Bernd asking "why is there no HIMEM that can be loaded from the prompt?"...
The FreeDOS kernel checks after each DEVICE[HIGH]= command whether XMS services started to become available. If so, and if DOS=HIGH, then the kernel moves itself to the HMA. This cannot be done at a later moment, and it can only be done because devices do not use the full memory management and kernel functionality in the same way as programs do, IMHO. Moving DOS to the HMA causes a fundamental change in memory layout and in some interfaces (for DOS=HIGH, some wrappers are activated, as it is assumed that non-kernel programs can get confused about ffff:???? style pointers, so all such pointers are hidden from userland with the wrappers except for some "undocumented" functions). So if you DEVLOAD HIMEM, it would be too late to move the kernel and BUFFERS to HMA. On the other hand, if SHOULD be possible to DEVLOAD HIMEM for the mere purpose of providing XMS. However, there MIGHT be problems with A20 handling. If you DEVLOAD HIMEM, then the first thing to do should probably be to force the A20 to on, as the kernel will not notice that A20 control has suddenly become available, as explained above. Only while the A20 is on, XMS access works properly. If you load HIMEM as DEVICE, the kernel will take over A20 decisions: It will try to turn the A20 off on EXEC (a kludge to make programs run which would otherwise require LOADFIX) and will ask HIMEM to turn A20 on at the first int 21 call after that. HOWEVER, FreeDOS EMM386 will ignore all requests to turn A20 off, so as soon as you load EMM386, you need LOADFIX again... Plus if neither EMM386 nor HIMEM are loaded, you WOULD need LOADFIX, but then the first 64kb will usually be in use by the kernel, so loadfix is not ACTUALLY needed. LOADFIX is a tool to avoid underflows with pointer normalization in some stupid stubs like MS EXEPACK, it forces programs to load outside the first 64k. Next question, why cannot you DEVLOAD EMM386? Good question. I assume that this is because the kernel is not ready for the related big changes in memory allocation structure anymore after config sys DEVICE processing has completed. You would need some EMM386 which adjusts everything by itself, then it might work. For example Quarterdeck has a tool which can, at any moment, link the a000:???? VGA memory region to the low memory. A similar tool could allow you to add UMBs to the running system at any time. Note that EMM386 hooks the XMS processing, so programs which had started to use XMS before EMM386 got loaded could get confused by possible modifications made by EMM386 (although modifications are usually limited to "block attempts to disable A20, and start to provide UMBs"). You can read umb_init(void) in the kernel sources to see what the kernel does to activate UMBs and link them to the memory change. The kernel calls umb_init right after it (optionally, controlled by SWITCHES=/E...) moves the EBDA/XBDA BIOS data area, in PreConfig2(void), but also in LoadDevice (i.e. after each DEVICE line, the kernel tries if it can activate the UMBs). So for both EMM386 and HIMEM: If you load them with anything else than a DEVICE= line, then you will have to do all the "Hey, HMA / UMBs just showed up, let's initialize them!" work which is normally done by the kernel manually. This may or may not be possible in a generic way, depending on whether only official documented data structures are affected. If something undocumented is affected, then DEVLOADing HIMEM or EMM386 will only work if DEVLOAD, HIMEM or EMM386 themselves know EXACTLY how to link their services into the kernel context. I assume that the MS "prompt-loadable HIMEM alternative" XMSMGR will not run very well with FreeDOS kernel. The minimal solution would be to create a power-DEVLOAD variant that can do enough interaction with HIMEM about A20 negotiations to load HIMEM to have at least XMS available. Note that this would NOT mean that DOS=HIGH can be activated from the prompt. Not even FreeCOM's XMS Swap is able to be activated later - it can only activate if XMS is available BEFORE you start FreeCOM, for good reasons. PS: Why is this on FreeDOS-user? Feels a lot like FreeDOS-devel, moving the thread there... Eric ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
