Hi Bernd, > Isn't XMS 3.0 used if available anyway? Or only if detected by a certain > program (which might lack a detection method for XMS 3.0 but not for 2.0). > A 'fast' 32bit register using XMS 3.0 implementation and slower 16bit > register using XMS 2.0 implementation is feasable?
To implement XMS 3.0, you need a 386. The interface uses different function numbers than XMS 2.0 for several functions, but the USUAL implementation is to have only a TRANSLATION for 2.0 calls to be able to internally use 3.0 code. So to have a HIMEM which supports 2.0 on 286, the 2.0 calls would no longer be allowed to use 3.0 code, and the resident size would increase a lot. It is really better to have a SEPARATE driver for 286 systems. > FDXMS286 is about 2.8KBin compressed form, and last updated in 2002. > So if an add-on to HIMEM would fit in this size... Again, FDXMS286 itself is the add-on, and it is good that it is a separate file. 99.9% of the users are happy with HIMEM and with its small size, and they have a 386 or newer system. I would really like to know from TOM what the minimal system requirements for the sy2pac sys/exe compressor stub are: HIMEM will crash - simply because it is sy2pac compressed - on 808x PCs, but as long as it gets far enough to display "sorry, 386 needed" and exit safely on *286* PCs, I do not care. However, if it crashes even on 286, then we have a problem. > Reasons for XMS, with regard to FreeDOS, are lack of UMBs (386-specific, > but that's something I'm sure you know better than me), > and thus a more heavy burden on conventional memory. a XMS driver can > provide access to HMA (for kernel) and XMS (for FreeCOM) to save about > 50 + 125 = 175KB of conventional memory. FreeCOM uses a pretty big amount of XMS... Whatever. I can tell you that you do NOT need a 386+ to have UMBs, but if you have EMM386, then you can MAP memory to create useable UMB areas. If you do not have it, then you have to program your motherboard hardware to do that (like UMBPCI does, but there are similar tools for pre-PCI systems as well). Otherwise, the UMB area would just be a hole in your address space. > If only FDXMS286 ( http://www.ludd.ltu.se/~ams/freedos/fdxms286/ )... > *which fixes have to be backported from HIMEM to FDXMS286. At least the > following, I think. > - A20 methods Michael introduced > - remove that annoying PC speaker beep if there's already a XMS driver... That sounds pretty feasible, in particular the latter. However, MartinS, the author of FD*XMS*, can better be reached on IRC.i7c.org (#fd-user or #freedos) than through this list. And he is generally NOT interested in cooperation with HIMEM project. He would rather write a new EMM386 I guess. That said, I did some new experiments with Bochs 2.2, FDXXMS 0.92 and the newest EMM386 1.15: The MEMCHECK option in EMM386 solves the first crash cause (int 15.87 with weird addresses, generating a PAGE FAULT in EMM386 which is handled with the WRONG stack frame, so you get a recursion which melts the protected mode stack by 2+2 bytes per iteration, finally crashing the whole system...). After that, I get a pretty interesting NEW kind of a crash: EMM386 shoots itself into the foot because the GO_PROTECTED code is executed again (unknown reason, probably jump to protectedmodecs:0?) and the LIDT causes a general protection error, making EMM386 want to kill the offending DOS program - but there is none yet (still in config sys), so EMM386 halts the system. Still not known why FDXXMS is EMM386-incompatible, but sure a good question. And the answer involves "EMM386 can crash on a page fault, while the INTENTION is to abort only the faulting EMS function and return to the calling DOS program" (as far as I understand). Not because EMM386 is expected to survive all kinds of misbehaving software, but because you always have to expect the worst, including an exception triggered by EMM386 itself, and at least show useful error messages. Luckily in THIS case the memcheck option solved the page fault which allows me to investigate further. Eric PS: Arkady tells that aPack 8086-compatible stub is very small, I would like to add that UPX 8086-compatible stub is only a few bytes bigger than the 286 stub, so everybody should remember to use only 8086-compatible stubs when packing FreeDOS programs. With the exception that 286-stubs are okay for HIMEM/EMM386 for me... ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
