Hi Michael, good news :-). > Version 2.0 of EMM386 supports sharing of extended memory between EMS, XMS, > and VCPI from a common pool...
> 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. Wow. Who pays you for that? X-). Actually I noticed that the crash-on-286 LSS in the SY2PACK exe/sys compressor stub is at the very end of the compressed himem/emm386, so I would offer to do a binary patch to make the stub 286 compatible. Of course that would also require a small amount of code reshuffling in himem/emm386 itself, because at the moment there are 386 commands used BEFORE testing whether a 386 CPU is present, even in un- compressed himem and emm386. As himem/emm386 themselves are open source, I could even help with the reshuffling... > The /? option is supported for HIMEM and EMM386. Yes, BUT: You still forgot to compile with FORSYS defined, so prf.c still outputs to BIOS instead of to (redirectable) DOS. Note that the output-to- DOS code has a simple but fatal bug if you compile it on non-Turbo-C. Patch available on request. Anyway, the help screens are nice, and I can grab them from DOSEMU window even in their un-redirectable current form, if somebody wants to update the HTMLHELP or similar resources. > 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. I do wish. Int 15, function 87, "copy extended memory", takes a structure at ES:SI (and a word count from CX) as input. Because EMM386 uses a macro / define to access the ES of the caller, and because many previous EMM386 versions had another stack layout than needed by that define at that very moment, many previous EMM386 versions accidentally read the structure from DS:SI. This caused crashes for all cases where int 15.87 got called with DS not being equal to ES. Only few programs use int 15.87 at all, but the best known victim of the problem was FDXMS / FDXXMS (the other XMS manager of FD). > 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. Sounds interesting. So, to the users on this list: Please re-test whatever program you have found to be troubled with EMM386, whether the update does fix your problem. You can also look at Bugzilla at freedos.org and test some programs which others have reported to be problematic. > 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. In other words, EMM386 has no built-in XMS engine, it still allocates XMS from HIMEM, but now uses int 2f.4309 (get handle table) to cooperate with HIMEM more closely? I believe it would not be too hard to do a fixed XMS allocation if int 2f.4309 is not supported (i.e. more or less switch to "old style"). As far as I understand, explicitly specifying EMM=... does select that behaviour? I would suggest that "if int 2f.4309 not supported, then hint people about EMM= and abort loading" or "if int 2f.4309 not supported, then allocate a default amount of memory, e.g. max 32 MB but at most half of the free XMS, instead". Maybe that is already the case :-). > MD> Since the EMS and VCPI allocators are now decoupled, I reduced maximum > MD> available EMS to "industry-standard" 32M. [Arkady asks:] > Isn't it possible to _increase_ available EMS memory through options Same question from me, does EMM= accept values bigger than 32M? Not that there are many EMS using programs which would gain anything from that... As long as a lot of VCPI memory is available... By the way, did you manage to speed up the VCPI allocator, given that VCPI is always allocated in tiny 4k chunks, so programs have to call the allocator very often if they want a lot of RAM. Of course, "sane" programs just allocate one big locked XMS chunk instead of using the VCPI alloc function, but not everybody is sane ;-). Thanks for working on EMM386 that much. Time for some testing everywhere now. Eric ------------------------------------------------------- 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 Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
