Feature request: please add support for Global EMM Import Specification (GEMMIS)

[volkertb]

Very few expanded memory managers have support for GEMMIS. That's unfortunate, because it is required for proper compatibility with Windows 3.x and Windows 9x. It's a standard/specification that allows proper memory management handover to Windows when it's started from DOS.

Adding GEMMIS support to Jemm386 and JemmEx would make them more flexible and versatile. Notably, it would allow FreeDOS to run Windows 3.x (even in 386 Enhanced Mode) out of the box.

DOSBox currently has a GEMMIS implementation, so its source code could be studied as a reference for implementing this in Jemm.

[Wengier]

I agree with adding support for GEMMIS too, which is pretty useful. As mentioned above DOSBox already has a GEMMIS implementation. In fact, you can see the changes in DOSBox's ems.cpp directly related to GEMMIS support here:

https://sourceforge.net/p/dosbox/code-0/2601/

The actual change for GEMMIS support is apparently smaller than one might think, so I think it can be done for JEMM386 too.

[volkertb]

@Baron-von-Riedesel How feasible do you think it would be to implement this in Jemm? In case the DOSBox commit that @Wengier linked to doesn't provide you with enough context, here is an old article from Dr. Dobb's Journal in which someone documented the specification in detail, after he reverse-engineered it himself, including code examples:

Dr. Dobb's _ Undocumented Corner _ September 01, 1994.pdf

The direct link to the article is https://www.drdobbs.com/windows/undocumented-corner/184409317, but for some reason, the layout on that site is messed up and makes it difficult to read. Also the print icon on that page is hidden in modern web browsers, unless you have the NoScript browser add-on enabled.

Anyway, from what I understand from the article, implementing this handover mechanism doesn't seem too complicated. But you can judge that far better than I can. What do you think?

[HyabusaBadge]

Hello.
It's a very interesting thread.
Is it possible to make FreeDOS EMM386.EXE compatible with GEMMIS?
I know FreeDOS EMM386.EXE is old and unmaintained. There is FreeDOS (98), which is a port of FreeDOS to the NEC PC-9800 series.
JEMM has not been ported, but FreeDOSEMM386.EXE has been ported.
I also think freedos' EMM386.EXE is a great resource for understanding GEMMIS.

[volkertb]

@HyabusaBadge It begs the question though, would it really be worth the effort implementing GEMMIS in the older EMM386 implementation? Wouldn't the effort be much better spent on porting JEMM to the NEC PC-9800 platform, as well as adding GEMMIS support to that? Perhaps the differences between FreeDOS for IBM PC clones and FreeDOS 98 are so small, that porting JEMM to the latter might be fairly trivial?

I know this is an open source project, and we shouldn't have any expectations, but I'm curious to hear from @Baron-von-Riedesel about his opinion on how challenging it would be to implement GEMMIS support, whether to JEMM or the older FreeDOS EMM386. And perhaps other people reading this have the expertise to help him with it?

I'm only just getting started with serious assembly language programming, dabbling with it during my spare time. Perhaps eventually, once I've gained enough experience with it, I'll be able to help with this, but until then, I believe this is beyond my skills.

[Baron-von-Riedesel]

I admit that I'm not very interested in this GEMMIS. I fail to see why it should be useful.

[bugnano]

Its usefulness would be that JEMM386/JEMMEX could be a 100% drop-in replacement for MS-DOS EMM386, in all its documented and undocumented cases (such as the ability to run Windows in 386-enhanced mode), which aligns with the goal of FreeDOS, that is to be a 100% drop-in replacement for MS-DOS

[Wengier]

Well said @bugnano! I wanted to use JEMM386 as a free replacement for EMM386 in MS-DOS, but for this reason alone it apparently cannot replace EMM386 which works with Windows 3.1 much better because of this support.

[volkertb]

I admit that I'm not very interested in this GEMMIS. I fail to see why it should be useful.

Well, first of all, I absolutely respect that JEMM is something you work on voluntarily and as a hobby. and it would be unreasonable and pointless to demand of you to implement this. JEMM already is a cool and useful project for many people as it is, and we're thankful that you've shared it with the world.

It all comes down to the lack of GEMMIS being a remaining unchecked box towards JEMM being a full replacement for EMM386 and QEMM386. Many people do want to play with Windows 3.x and Windows 9x. It would be great if Windows could work with FreeDOS and JEMM out of the box. Lack of GEMMIS support (I believe) is the one thing preventing that from working right now. (Anyone feel free to correct me if that's not to case!)

Yeah, Windows 3.x/9x might still work with FreeDOS if you rebooted without JEMM being loaded, but that's a bit of a hassle, espcially if you have to reboot again afterwards. GEMMIS support makes all of this much more seamless.

But if you don't feel inspired to work on this functionality, would you be open to accepting pull requests for this from others?

[Baron-von-Riedesel]

...would you be open to accepting pull requests for this from others?

My experiences - so far - with patches from unknown people are "mixed". So I'm rather sceptical.

[volkertb]

Would it really be that disruptive to add, though? Even if you don't care about the feature much, it's basically a control handover protocol, so it wouldn't require any drastic changes to the overall architecture of JEMM, right? I'm sure a lot of FreeDOS users would really appreciate this functionality.

[t9999clint]

Would this just fix Win 3.1? or would it fix other things too?
I would love it if I didn't have to use emm386 for a bunch of my TSRs like SoftMPU and stuff. Way to many unnecessary reboots. ADLiPT added a Jemm driver, but a lot of these TSRs either aren't actively worked on anymore or they don't want to bother learning a new API and "just use emm386" seems to be their only response.

Andreas, Regardless of your decision on this thanks for all your work on this an your other projects (I use most of them). I'm no programmer so I don't want to make unreasonable demands.

[volkertb]

@t9999clint GEMMIS is specifially for being able to start Windows 3.x (in its optimal 386 Enhanced Mode) and Windows 9x from (Free)DOS with JEMM loaded and returning back to DOS when you exit Windows. When you have an EMM loaded that puts DOS in the V86 mode supported by 386 CPUs, but doesn't support GEMMIS, you would have to reboot the computer without the EMM first before being able to start Windows (unless you're running Windows 3.x in Standard mode or Real mode, which gives you reduced functionality and performance). And then after exiting Windows, you'd have to reboot again, if you were to require the EMM for other DOS software.

GEMMIS is supported by both the standard EMM386 versions that come with later versions of MS-DOS, as well as by Quarterdeck's QEMM386. Microsoft only shared the specification with a select number of software companies, but it was later reverse-engineered and documented in the Dr. Dobb's Journal article that I shared in this earlier comment further above.

[t9999clint]

Oh, so it's just for Windows. Sorry for the pointless post then.
Does OS\2 need this as well?

On a sidenote I opened a feature request ticket with FreeDOS to add unloading of emm386 to make it easier to switch between jemm and emm386 (fdos version).
Has anyone put in a request for Gemmis support with the FDOS guys yet? I couldn't find a open ticket for one, but I am bad at looking up tickets with their weird system

[Baron-von-Riedesel]

GEMMIS is specifially for being able to start Windows 3.x (in its optimal 386 Enhanced Mode)

Yes, that's also what I know. And IIRC, Win3.1 in enhanced mode, isn't that limited to FAT16 and short filenames? What applications do actually need this ( and won't run in Win95/98?).