Hi, Disclaimer: I've never done any direct EMS programming. I wish I was more help here, but alas ....
On Mon, Oct 19, 2015 at 12:08 PM, Bret Johnson <bretj...@juno.com> wrote: > > If you read the EMS v4 spec carefully > (http://www.phatcode.net/res/218/files/limems40.txt), it doesn't actually > say that the EMMXXXX0 name is required. It's mentioned in the appendices > that provide two examples of how to test for EMS. How the text is worded in > the appendices merely IMPLIES that the name should be EMMXXXX0, but the > specification never actually says that it MUST be. I don't think I've ever > seen an earlier version of the spec, and the earlier versions may say > something completely different. This old archive only seems to have EMS v4 specs: ftp://ftp.lanet.lv/pub/mirror/x2ftp/msdos/programming/specs/00index.html Wikipedia has some info: https://en.wikipedia.org/wiki/Expanded_memory#EMS Even old Simtel mirrors have some stuff: ftp://ftp.sunet.se/pub/simtelnet/msdos/memutil/00_index.txt And here's some info from MS itself: https://support.microsoft.com/en-us/kb/78557 > Also, if you scan RBIL for "EMMX", you find references to at least three > other names that are associated with EMM's: 386MAX$$, QMMXXXX0, & EMMQXXX0. > I don't actually know if any of those are legitimate alternative names or > not, but because they are associated with EMM's in RBIL don't think you can > simply ignore them. IIRC, the "EMMQXXX0" one is from the (rare?) NOVCPI option. The others are probably non-standard / uncommon. > In the appendices, it also talks about when you can and can't use the Device > Name method and MUST use the INT 67h method that I outlined briefly (but is > fully described in the specification). Plus, the Device Name method is > actually bigger and slower than the INT 67h method. So, the Device Name > method is bigger, slower, less reliable, and less universal/portable than > the INT 67h method, so I personally see no value in ever using it at all, > and in my programs I don't. EMS is quite obsolete, even in DOS circles. I'm not saying it's "bad", but there are "better" ways to do things (e.g. DPMI). Especially since DPMI surpassed VCPI, which was an EMS superset, there's often little choice (or else try to support all memory methods, which is harder and error-prone but probably a good idea, if at all possible, which is what a lot of DOS extenders did). > However, as discussed in RBIL, the EMMXXXX0 name is required for EMM's that > are compatible with Windows. An EMM "transforms" itself and works > differently when Windows starts so that Windows can handle the EMS instead > of the EMM doing it, and then must revert back to normal when Windows closes > (this is for older versions of Windows that could be shut down without > rebooting). I think M$ was the only one who ever made an EMM that was fully > compatible with Windows. I know Qualitas tried to make one and was fairly > successful, but am not sure exactly how far that got. The days of people having hardware EMS are long long gone. Most people only rarely run EMM386, usually only for games (e.g. Blackthorne) or to utilize UMBs to save low memory. But if you expect EMS to work well under (modern, 32-bit) Windows, you're in for a lot of pain. http://www.bttr-software.de/forum/board_entry.php?id=11970#p11970 http://www.bttr-software.de/forum/board_entry.php?id=12368 Even back in Win 3.1 days, VCPI was pretty much ignored ("standard mode" only) in lieu of DPMI. It became de facto that most apps should (optionally, at minimum) support DPMI, and they did. DPMI was very popular (e.g. DJGPP), but Windows (especially NTVDM) was too buggy later on (even for DPMI !), and it wasn't a priority for MS to fix it. I'm basically saying that DPMI is preferred over EMS/VCPI or XMS (or raw or whatever else, int15h ??). I know that's fairly obvious, but you can use whatever you want, just saying ... none of it is as easy as it sounds. :-( P.S. The old EMX extender (last updated circa 2001) was a hybrid DOS + OS/2 tool. Thus it could run in EMS/VCPI (or DPMI with RSX). Actually, I think it had some inherent (EMS?) limit of 1 GB of RAM, hence on this particular (multi-gig RAM) machine, I have to "set EMX=c:\utils\rsx.exe" or else it will crash/reboot the machine. Thus I must always enable DPMI before running any EMX-compiled program. One notable program that used this (until 2010) is ancient RAR(X) 3.93 for DOS. ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
