Hi!

Hmmm you could try japheth.de jemm instead of
xmgr umbpci lowdma ;-). Or try himemx plus
jemm386, more classic than jemm, same page.

Problem is that devload asks DOS for the highest
location which has 64k, without checking how much
your driver really needs: It is sys, no exe header
so "needs own size plus unknown" where own size is
ca 4 kB in your case while only 3 kB stay in RAM.

As your 18 kB UMB is smaller than 64kB, devload
does not even try using it... Even 3.20rc not.
Basically devload has no idea how much RAM your
driver really needs, but it probably should have.



It could check exe headers, if present, and file
sizes. It should not try to alloc more than your
max free UMB size (now UMB always tries 64 kB)
and should know that less than the needed size
is not enough (now checks for 4 kB but that has
no effect as DOS will just fall back to low RAM).

Affected code: Area around "lowload:", value
0fffh versus "max avail UMB" and "min needed
for this driver" and SMALLESTDRIVER (oh well).

The current version only uses "attrib" to see
if your driver exists at all and "exec" to
actually load it - without checking the size.

If somebody wants to write a patch: I suggest
to patch around "Check whether file exists"
and "lowload:", with some variable in RAM
which stores the minimum RAM requirement as
found by checking the file size and, if exe,
header. And with some code which checks how
much UMB you could get, to avoid asking for
more. If needed > max UMB, use needed anyway,
to let DOS automatically fall back to low RAM.
If needed < max UMB, alloc max UMB, to give
the driver as much UMB as possible for init.

Eric



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to