[Dosemu-devel]Re: int15 and external himem.sys

[Stas S. <st...@ak...>]

Hi.

Eric Auer wrote:
> but on the other hand builtin HIMEM functionality in DOSEMU
> saves some RAM compared to loading a real HIMEM.SYS file, so
> I would not completely remove it. Maybe make it more configurable?
I already made it more configurable:
with the current CVS you can finally
set $_xms=(off) and that will even
boot up:)

> Bonus: I am told that MS HIMEM "allocates" part of the HMA for itself,
> which is hopefully compatible to FreeDOS and other kernels. This allows
> MS HIMEM to be much smaller than the 2k which FreeDOS HIMEM would take.
I didn't know the himem of FreeDOS
takes 2k. This is IMHO not too much,
but can surely be reduced if right
now it doesn't use HMA.

> But the DOSEMU builtin XMS driver takes no DOS RAM or HMA space at all :-).
Well, in a near future I don't think
the built-in driver to be removed
anyway.
You propose to leave it forever though,
because himem of FreeDOS takes more
mem than it should. I think it might be
better to improve the himem.sys instead
and not keep the duplicating functionality.
The functionality that is rather complex
and disabled by default, will rot. Noone
will test it, and there will be the
useless bug reports. That's why I prefer
to not keep the things duplicated, and
improve only one thing instead - that
saves the efforts.

> which require the A20 to be open. In DOSEMU, you can even use black magic
> to make the "check if A20 open" very fast - and you do not have to check
Yes, extremely fast. In dosemu it is
just a matter of an "if(a20)" check.

> if the A20 state actually changed
the A20 in dosemu is purely virtual.
It is being emulated with the mremap()
syscall on a shared memory.

>> It turned out that Win98/DOS uses
>> int15 for moving ext memory blocks
>> even if the XMS driver is present.
> ... as probably others.
Probably not. DOS kernel is a special
thing - it can reasonably assume that
the himem.sys is not yet loaded. But
as soon as the config.sys is passed,
noone can do any assumptions about the
himem's presence.

> Who knows other int 15 users
> except himem itself?
There is a "switch to prot. mode"
functionality of int15. Lets hope at
least this is not used!

>> functionality in place, Win98/DOS
>> still doesn't work properly with our
>> XMS driver (unless I explicitly disable
>> the a20 functionality in xms.c).
>  Any idea about that?
Not yet. In fact I was very surprised
when found dosemu completely useless
for running Win98/DOS. It was always
rumoured that dosemu can run any DOS.
I was asserting that at work, and when
my work-mate said dosemu simply crashes
with Win98/DOS, apart the fact the
start-up splash screen of Win98 was
garbled under xdosemu, I was confused a
lot (and he switched to QEMU).
What I think about disabling the a20
functionality, is that in this case
the DOS simply utilizes fall-back code,
it probably simply falls to the XMS-less
operationing, and that works properly.

> Your int 15 block copy function looks good and preserves
> a20 state, so what could cause the remaining problems?
Something unrelated to int15 I think.
At least that DOS doesn't seem to use
int15 after the config.sys is parsed in
case the himem is there, so this shouldnt
conflict.

>> is attached. I can run Win3.1 with the
>> native himem.sys now.
>  You mean Win3.10 in /S (286) mode?
No, I mean WinOS2-patched Win3.1 in
386-extended mode (same is true for Win3.11).

> Maybe even with FreeDOS kernel?
Maybe not:) Well, I am using dosemu in
a "minimalistic" mode - I only use the
dosemu.bin with my own startup scripts
and it boots from my native DOS partition
which has a PC-DOS installed.

> How well did it run with builtin DOSEMU XMS drivers?
Same as with the external himem. But you
need a rather recent dosemus for that anyway.
Older ones are incapable of running Win3.1
(I know you use something old), and perhaps
also FreeDOS is incapable, which is a shame.

> No, builtin XMS
> support should stay available for those who want it.
 > Works very nice and saves some RAM
But also has a lot of code that noone will
care to test if the external himem would
be an afficial preference. So I'd better go
for improving the himem.sys of the FreeDOS
in the long terms. In the short terms I agree
the built-in XMS should stay.

> You can add an option which allows to disable the builtin XMS driver, though.
I've done that yesterday. There was such an
option, it just didn't work. But the disabled
by default functionality usually adds more
problems than solves, so I view that as a
temporary measure before the alternatives
are mature.