Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx202.zip, EMM386/HIMEM mostly executable package, and emms202.zip, EMM386/HIMEM mostly source package. EMM386 Version 2.02 is a stable release with small bug fixes over version 2.01 and compatibility enhancements. It is a generally recommended upgrade, but not critical. EMM386 fixes an error which causes a tiny memory leak when allocating VCPI/EMS. It fixes a more serious bug where -- under rare circumstance -- EMM386 incorrectly believed it was out of memory. This was only known to happen with the Deskwork RAMdisk utility present, but it could possibly happen for other applications or environments. EMM386 will also warn if an old or out-dated HIMEM version is used which does not allow XMS/EMS/VCPI common pool sharing. Version 2.02 adds the new MAX= option to limit amount of available VCPI, and EMS if <32M. Use this with versions of DOS/32A which fail if more than 256M of VCPI is available. 2.02 also adds emulation support for the CPU RDTSC instruction in early Pentium and AMD chips. Blathering on... The memory leak bug would lead to temporary loss of 0-2% of allocated memory as unavailable for use due to invalid memory alignment skipping past 0-3 available pages of memory per block. The bug with DeskWork RAMdisk was due to an error where small free XMS blocks of <4K could, under certain circumstances of memory alignment, lead the EMS/VCPI allocator to believe there was no more free XMS to use, despite whatever free XMS blocks may exist. The RDTSC emulation is as described. Not much more to say about it. It appears to be an Intel faulty design in Pentium chips, aped by comparable AMD processors. Pentium Pro, II, and later chips do not have the problem. As a consequence of my not having an old chip, the modification is untested. If someone should decide on a whim, through curiosity, by mistake, or via basic stupidity, to use an out-dated or substandard XMS memory manager which does not support INT 2Fh function 4309h, thereby forcing EMM386 to turn off common pool-sharing, EMM386 will provide a startup warning message to the effect that the user should upgrade or use an explicit EMM= option sized allocation. EMM386 supports the MAX=#### option which allows limiting the available VCPI to the MAX setting. If less than 32M, it will also limit EMS. EMM386 is smart enough to throttle its doubling of XMS block allocations (currently 1.5M, 1.5M, 3M, 6M, 12M, etc) back down to a value under MAX. MAX usage will be accurate to within approximately 1.5M. As a vaguely amusing side-note, given the separate EMS and VPCI allocator, using up VCPI to MAX limits still allows EMS to separately use memory up to the MAX setting. The MAX option is mostly for extenders or programs which inexplicably throw a tantrum if allowed too much free VCPI memory. At least some versions of DOS/32A act this way. The RSX DOS extender used by RAR32 throws a tantrum in a slightly different way. If EMM386 is loaded, and more than 429M of memory is available EVEN IF almost all of memory is either left as XMS or taken from XMS to VCPI, then RSX will give an out of memory error. It will not do that if EMM386 is not loaded. This includes any EMM386 MAX setting or use of a fixed pool via the EMM= option (as far as I could test, anyway). You must use the /MAX=### option of HIMEM, not EMM386, to limit total memory to get around the problem. RAR32 sobs quietly to itself over such bizarre behavior in its forced coupling with RSX. This version is considered stable. No more than the normal complement of bugs are expected to exist. I will be available to fix those and answer the occasional inquiry, but otherwise am taking the summer off from anything that involves EMM386 and HIMEM. Should anyone desire new features or a novelization on the perils of VCPI, they need look towards another EMM386 related/interested developer type of person, place or thing.