Should show up in a few minutes.
Michael Devore wrote:
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx20.zip, EMM386/HIMEM mostly executable package, and emms20.zip, EMM386/HIMEM mostly source package.
Version 2.0 of EMM386 supports sharing of extended memory between EMS, XMS, and VCPI from a common pool. For most users this means no more need to specify EMM=xxxx in your EMM386 command, because the full amount of memory is available to all memory classes, more or less. Should you wish to limit memory for EMS/VCPI, you can still use the EMM= setting. Some programs may require this due to their failure to work with too much free memory.
Additionally, HIMEM supports the /X2MAX32 option which limits XMS 2.0 memory reported to 32767K, to work around a dumb bug in Disney's Aladdin game, and possibly others. Full XMS memory is still present.
EMM386 also has a couple of bug-fixes that will affect almost nobody.
Be aware that some 1500 lines of assembly language code were added in this version of EMM386, with another few hundred lines replaced or deleted. The actual code changes exceed that made for earlier VCPI support. Unnoticed (hopefully small) errors are virtually guaranteed. Please test applications and report any problems.
Various particulars ensue:
With the /X2MAX32 option of HIMEM, full XMS memory is still available for both XMS 2.0 and 3.0 functions, and is fully reported on XMS 3.0 functions, eliminating the previous need to literally reduce all available memory to <32M via HIMEM's MAX option get Aladdin to run.
The /? option is supported for HIMEM and EMM386. Running HIMEM and EMM386 at the command line will continue listing commands, as before, but will not complain if /? is present. Use of /? will henceforth be known as the Arkady gambit.
The EMS system handle 0 name is preset to SYSTEM. Also, memory for UMBs are allocated to that handle, rather than in a separate handle as before.
Since the EMS and VCPI allocators are now decoupled, I reduced maximum available EMS to "industry-standard" 32M. Mostly this was done because silly EMS-using programs became confused if more than 32M was available. Pumping it back up to 512M would be a small change, but probably unnecessary for anyone. VCPI can go to 4G, theoretically.
There is a fix to INT 15h, function 87 in EMM386, but I have forgotten the details. Eric Auer can supply them in exhaustive detail, should one wish.
EMS unmap page function 44h, bx = -1, has been broken for about a thousand years. It would map in garbage memory rather than original page frame memory, possibly leading to a crash. Apparently it's not very critical since nobody has noticed going back to the original EMM386 code.
On a very trivial note, EMM386 now supports common memory pool-sharing between EMS, XMS, and VCPI, if a HIMEM version which supports INT 2fh function 4309 is present (like recent FreeDOS versions). No more EMM=, usually. As a consequence, the former VCPI reserve was removed. As a further consequence, should you wish to use a nonstandard HIMEM without function 4309 support and do not specify an EMM= setting, there will be approximately zero memory available for EMS and VCPI. If you do that, you are 100% on your own.
EMM386's pool-sharing feature is a bit more sophisticated than originally planned. It will search out the closest match to 1.5M available in XMS free handles and use a matching handle to grow its memory allocations. If there is -- as is typical in a vanilla FreeDOS environment -- only one monolithic XMS handle containing all free memory, it will dynamically carve off a 1.5M slice as needed. If there are a litter of small amount of XMS handles of at least 32K size, EMM386 will vacuum them up before carving up bigger pieces.
Nor will EMM386 voraciously consume precious XMS handles, given how limited they are in number. After the first couple of 1.5M allocations, EMM386 starts doubling the allocation amount, assuming that an application is after big memory game. With the doubling feature used against a single XMS handle holding all free memory, no more than 13 handles need be consumed before the entire 4G address space is covered.
EMM386 will also return XMS blocks to the pool when they are no longer used by any EMS/VCPI allocation, where they may be used again by EMS or VCPI, or allocated via XMS API functions.
You should be aware that there is no free lunch and pool-sharing may increase memory allocation timing overhead by microseconds. This would be most noticeable when large blocks of EMS/VCPI are allocated, then freed, since EMM386 will be dipping into and out of the common memory pool as blocks come in and then go out of scope.
Hundreds of other small details and comments preempted in interest of time, space, and sanity...
Questions, comments, problems, let me know. I'll be around for a while as this settles down, then after a suitable break, may take a look at fixing CWSDPMI's faults or something entirely different.
-- I'm sorry my president's an idiot. I didn't vote for him.
------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Freedos-user mailing list Freedosfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/freedos-user