Hi FreeDOS devs, I understand that the EMM manager that currently ships with FreeDOS, JEMM, has several advantages over Microsoft's EMM386. Apparently it is more efficient in memory use and has some additional features and tweakable settings. And that's of course great.
However, there are two things that JEMM currently doesn't provide. Firstly, JEMM doesn't have a port trapping API that is compatible with Microsoft's EMM386 memory manager. Yes, JEMM can offer similar functionality using JEMM Loadable Modules (JLMs), but the programming model of JLM is considerably different than the API in EMM386, or even QEMM's QPI. Most notably, JEMM/JLM requires the port trap handler (the emulation code) to be written in 32-bit protected mode code, whereas the EMM386 and QEMM386 APIs allow such handler code to be written as 16-bit code. This is a problem particularly for the popular SoftMPU TSR. The SoftMPU developers don't want to take on the burden of having to develop and support a JEMM version, in parallel to their EMM386/QEMM386 version. They prefer to work with a common codebase. See the comment at https://www.vogons.org/viewtopic.php?p=332252#p332252 To provide some context about this tool: SoftMPU emulates the Roland MPU-401 MIDI interface, including its so-called "Intelligent Mode", on sound cards that support only the UART mode subset of MPU-401, and since more recently, also on the RS-232 serial port, using a MIDI adapter, such as the recently released MPU-232: https://www.serdashop.com/MPU-232 SoftMPU is a popular utility for retro gamers, and it sucks that this software, which is itself an open-source project, currently requires a proprietary/closed-source component (namely EMM386 or QEMM386) in order to work with FreeDOS. The second limitation of JEMM is its lack of support for the GEMMIS specification. This means that it is not compatible with Windows 3.x, at least when we want to run it in 386 Enhanced Mode. (This is actually a second piece of the puzzle, since FreeDOS also requires kernel patches for this to work, as detailed in the recent "video FreeDOS running Windows 3.1" thread in this mailing list.) The GEMMIS standard provides a means to seamlessly hand over control of memory management from the EMM manager to the Windows kernel, and vice versa when exiting back to DOS. It is supported by only a select number of EMM managers, notably by Microsoft's own EMM386 and QEMM. The maintainer of JEMM doesn't consider GEMMIS worth the effort to implement, unfortunately. See this discussion: https://github.com/Baron-von-Riedesel/Jemm/issues/5 Now granted, in the latter case (lack of GEMMIS support), you could argue that since Windows is itself proprietary/closed-source, it's not that big a deal having to rely on a closed-source EMM manager. But having to replace JEMM with EMM386 or some other closed-source alternative would make the overall system less free. And alternatively, switching back and forth between EMM managers with different boot profiles is a hassle. Also, isn't maximum compatibility with MS-DOS the ultimate goal of FreeDOS? Being as much of a drop-in replacement as possible? In that sense, Windows 3.x should be considered just another application to run from DOS. An extensive graphical shell, as opposed to the quasi-OS that Microsoft intended the DOS/Win3.1 combo to be. As an additional argument: it is possible that GEMMIS was adopted by software outside of Windows as well, namely in the demo scene. Apparently, in order to compete in the Assembly'95 demo contest, applicants were required to ensure that their entries would be able to coexist with 386 memory managers. The GEMMIS spec was floated as a possible solution for meeting that requirement. Whether any demos with GEMMIS support were actually developed, I don't know. But that might be worth investigating further. More info on that here: http://dgi_il.tripod.com/gemmis.txt But going back to my main point: there is no full open-source drop-in replacement for EMM386, as far as I know. The ideal solution would be for some developers to enhance JEMM in such a way that support for both these features (GEMMIS and the EMM386 port trapping API) could be added. Perhaps these features could themselves be implemented as JLMs? That would keep JEMM lean, and make these features optional, just for those who need it. I currently lack the experience to implement such support, at least on my own. But nevertheless, I would like to start a discussion about this here. Perhaps others here know of better alternative solutions. For instance, maybe my assumption that there currently is no open-source drop-in replacement for EMM386 (including the aforementioned features) is incorrect? Do any of you know of any such projects that could fit the bill? Thanks.
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
