Hi,
Eric Auer escribió:
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.
<snip>
<a lot of stuff that I know very well>
<some suff about A20/ EXEPACK also removed, being redundant to me>
I know it perfectly well, I read thoroughly kernel sources time ago. But
this is NOT what I am asking.
Of course I know that if you could load HIMEM AFTER boot you can NOT
move (or at least easily) FD kernel up to HMA, etc. etc.
I assume that a user that would load HIMEM from commandline knows this
too. I wonder why can't you load and start up having XMS interface (and
using EMBs) after loading, even if you won't get the best profit of it
(that is, at boot-up).
My question is: WHAT is TECHNICALLY wrong with starting the XMS
interface AFTER boot? (if A20 keeps disabled or same state).
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.
Ok, this seems to be my reply, the other is just redundant :)
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.
Same if program-which-we-don't-know-about is loaded in CONFIG.SYS BEFORE
HIMEM and enables some A20 management. After all, XMS drivers are
CHAINED, EMM386 adds itself to the chain too.
Only while the A20 is on, XMS access works properly.
??
What does A20 and EMBs have to do? You could just keep A20 disabled and
have the ability to allocate/deallocate EMBs.
Of course, you won't get 100% of the XMS interface working, but you
don't have it either if you just load HIMEM (no UMB management
functions, for example).
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.
WHAT changes? Who says that I want to load Kernel to UMBs?? This is
independent to kernel, just suppose I just WANT to make UMBs available
at commandline.
Before you repeat once and once again the obvious: this wouldn't be the
most optimal situation, as you would like to have UMBs at boot time for
devices, kernel itself, etc.
But this is NOT my question. I am asking WHY it isn't technically
possible to do this? I assume you can, WIN386 shows this, but I was just
asking in case I am forgetting of something fundamental.
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").
?? More precise please.
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).
Again not related. I may have UMBs and kernel not know anything about
them. Perhaps I cannot LOADHIGH, but my program(s) can be intelligent
enough to allocate UMBs through XMS interface rather than calling DOS.
Anyway when loading Microsof Windows under MS-DOS you are forced to load
HIMEM, not EMM386. Perhaps MS-DOS has a back door to "mount" the new UMB
chain to the memory allocation scheme.
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.
No, I will not have to.
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.
IMHO, you just warn the user in the DEVLOAD documentation that HIMEM
should be loaded with the swich to keep the A20 off (I seem to remember
that there is such a switch).
Aitor
PS: I would prefer if you DIDN'T move this thread to private, please.
I'd like to know other's opinions too, if any.
Furthermore, I'd like it to be "the default option", specially if you
are later asking "post it if you like" :)
-------------------------------------------------------
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
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
