@Sneakernets - here is the 0.9.2 beta 2 version. No major changes, just cleanup and some refactorization. It fails some of my tests and I struggle to know if it's because of the virtualization or if it would also fail on real hardware. I've included a test program. Would you mind running it on your PC and tell me what it says? The program performs a set of XMS copying tests and displays the results (OK/ERROR) for each.

I have released EXMS86 v0.9.2. EXMS86 does all kinds of little things that are supposed to be done by the EMS 4.0 cards, like far pointer normalization, segmentation of multiple-pages transfers and such (at the cost of slightly worse performances and increased memory footprint).

EXMS86 works perfectly now on my wonky virtual setup so hopefully it should work on hardware as well. I tested it with DOSMid, Wolf3D, FreeCOM, and my own custom suite of XMS tests.

mateusz.viste wrote on 2025-07-24, 10:12:

I think that such games are very unlikely to work on an 8086, because of the common assumption that "XMS = 386+".

XMS = 386+ would be a very strange assumption. But the assumption that any system that has an XMS driver contains a 286 processor seems reasonable, as the point of the Extended Memory Specification is to manage memory that is mapped into the processor space above 1MB, and such memory did not exist before the 286.

Using the XMS API like a RAM disk that can read and write blocks into a "black box" clearly makes sense for real-mode DOS software (and that's why EXMS86 works), but limiting XMS to that use is in no way specification compliant. Real XMS up to 16MB might for example be used for DMA transfers. I wonder whether any 286 game loaded Sound Blaster samples into XMS, and directly played them from XMS. At the moment, this sounds like a very clever idea to me, as this means that the samples are directly accessible for the DMA system and take up zero space in precious conventional memory.

mkarcher wrote on Yesterday, 21:30:

Using the XMS API like a RAM disk that can read and write blocks into a "black box" clearly makes sense for real-mode DOS software (and that's why EXMS86 works), but limiting XMS to that use is in no way specification compliant.

EXMS86 is compliant to the XMS 2.0 spec. It does not implement *all* of it, but that's not mandatory - the spec explicitly states that "Developers should keep in mind that some of the XMS API functions may not be implemented by all drivers and will return failure in all cases."
For example EXMS86 has no support for XMS functions related to HMA, UMB and A20. It also does not support the call "give me the physical location of the XMS memory allocated to my handle".

mkarcher wrote on Yesterday, 21:30:

Real XMS up to 16MB might for example be used for DMA transfers. I wonder whether any 286 game loaded Sound Blaster samples into XMS, and directly played them from XMS. At the moment, this sounds like a very clever idea to me, as this means that the samples are directly accessible for the DMA system and take up zero space in precious conventional memory.

Sounds plausible, yes, albeit there is one difficulty: DMA cannot cross 64K boundaries, so it would require a bit of heavy lifting to locate a proper place in the XMS space. It would also require to "lock" the XMS handle to ensure the driver will not relocate the data at some inconvenient time... but the spec says that "Locked blocks should be unlocked as soon as possible", so I wonder how that would play out in practice.