Reply 40 of 76, by LSS10999
wrote:That's why. Phil reported issues with UDVD/XDVD, SHSUCDX, and JEMM386 as being the main culprits of freedos's compatibility issues.
[EDIT] To be fair though, some of the compatibility reports I'm posting are from 2016 or older. XDVD2 and XHDD probably have improved lots since then.
I'm not sure about UDVD/XDVD, but UIDE when used with hard disk caching (now the XHDD part) could trigger system reboots when used with UMBPCI (which is in real mode), for programs that used Borland's 16-bit DPMI runtime (RTM). Tyrian 2000 (namely its setup program) was such example. The system reset doesn't occur when using JEMM386, but on the first 2 runs it'll exit with unhandled exceptions. On the 3rd run the program starts running correctly. What exactly caused this phenomenon is unknown, but it's possible that the first few unhandled exceptions were caused by the CPU registers being in invalid states which got corrected after a few times and allowed the program to start later on.
I do remember seeing suggestions (on BTTR) that by running HX's DPMI runtime before running the problematic programs would fix the issues such as system reboots, but I haven't tested personally. From the look of it, HX appeared to be able to correct misbehaviors of some programs, even on DOSBox.
Not sure if JEMM386 could possibly implement a port trapping capability that are compatible with the proprietary ones present in MS EMM386 (and very likely in QEMM) in the future, as both MS EMM386 and QEMM have problems with handling very large RAM (256MB or above) and can only be considered viable in period-correct builds.
Most of the issues typically don't occur when using first-party MS stuffs (MS-DOS, HIMEM, MS EMM386, SMARTDRV, MSCDEX, etc.), despite they consume much more RAM, regardless of system configurations (at least for SMARTDRV and MSCDEX, even when using with 3rd-party memory managers on a system with very large RAM, since you have to use one of those on such environments).
New DOS drivers implemented certain functionalities differently from the old ones using more optimized and efficient approaches that consume less RAM compared to the original ones, and this might be the cause of breakage with certain programs/runtimes that were made with original drivers (such as MS EMM386, SMARTDRV, MSCDEX) in mind, so patches or workarounds might be needed to get those problematic programs/runtimes working as they should.