Hi everybody, 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. Regards, Eric ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
