I agree that there is some controversy about EMM386 versus JEMM386
and JEMMEX... Basically the former had a focus on careful testing,
while the latter has a focus on "if it is cool for Japheth, it is
also likely to be enjoyed by other users". So the J drivers indeed
are more modern and fancy, yes :) On the other hand, they may have
less fool-proof default settings or even need advanced settings to
behave reasonably well in a one size fits all environment like the
one of Alain: He tries to give one complete working system to his
customers, which have a lot of variety in their hardware and have
no big experience in fine-tuning config or autoexec.
You know that I often say "if it does not work, try again without
EMM driver". This is not meant to blame the driver quality, but I
do think that it is hard for drivers to automatically do the right
thing with EMS and in particular UMB and alas I have to agree with
Alain that the old drivers tried harder to stay safe than J ones.
Also, modern hardware and firmware makes it hard to play safe with
UMB regions, too many unsafe areas are not tagged as such any more.
In a related topic, there are many ways to deal with the infamous
A20 and if you ask me, most software would just work with drivers
that first carefully try a few methods to switch it on, verify it
is on, then ignore further requests to switch it off. :-p A start
would be a config sys kernel option to make sure that only enable
but not disable requests are sent, but of course HIMEM, XMGR or
similar could also enforce this as described above. Would make a
good setting for one size fits all projects, I hope :-)
Finally, I agree with two more things from Rugxulo: If you X=all-
the-useful-UMB-space, why load EMM drivers at all? Most software
is happy with XMS if no EMS is available, so the main job of EMM
drivers today is to provide UMB space and if you have none, not
much use is left for them. On the other hand, EMM drivers can be
a very nice work-around for shaky A20: While EMM drivers are on,
the physical A20 is usually left enabled and the A20 activity to
be seen by DOS is just a simulation created by page table writes.
The second thing to agree with is that a discussion of the ins
and outs is more useful than just a warning - what went wrong?
What should change? Which experiences do the others here have?
What were the bugs in non-J-EMM386 which should be fixed in J?
>> On 2 new machines (last+this month) I had problems with X=TEST,
>> I made it work with
>> EMM386 NOEMS X=C000-EFFF NODISABLEA20 NOVDS /VERBOSE
>> this was apparently due to some periferal in UMB not detected
The NOVDS and NODISABLEA20 options are both different topics than
the "avoid risky UMB areas" NOEMS X=C000-EFFF ones, so it would
be helpful to know which of the three ingredients were important.