DOS ain't dead - Error in XMS specification?

ecm

Düsseldorf, Germany,
27.04.2019, 16:16

Error in XMS specification? (Developers)

While working on my symsnip collection, I encountered an error.

XMS 2.00 http://www.phatcode.net/res/219/files/xms20.txt

XMS 3.00 http://www.phatcode.net/res/219/files/xms30.txt

In the section titled "Move Extended Memory Block (Function 0Bh)" it reads:

> If the source and destination blocks overlap, only forward moves (i.e. where the source base is less than the destination base) are guaranteed to work properly.

RBIL 61 in the Int2F.4310 description of XMS functions also has wording to this effect.

The error is that forward moves (DF=UP, cld) work properly on overlapping destination and source when the *destination* is below the source. This is the other way around than what the specification lists. From what I can tell, drivers actually implement the forwards movement.

---
l

Oso2k

27.04.2019, 20:20

@ ecm

Error in XMS specification?

Post reply

> While working on my symsnip collection, I encountered an error.
>
> XMS 2.00 http://www.phatcode.net/res/219/files/xms20.txt
>
> XMS 3.00 http://www.phatcode.net/res/219/files/xms30.txt
>
> In the section titled "Move Extended Memory Block (Function 0Bh)" it
> reads:
>
> > If the source and destination blocks overlap, only forward moves (i.e.
> where the source base is less than the destination base) are guaranteed to
> work properly.
>
> RBIL 61 in the Int2F.4310 description of XMS functions also has wording to
> this effect.
>
> The error is that forward moves (DF=UP, cld) work properly on overlapping
> destination and source when the *destination* is below the source. This is
> the other way around than what the specification lists. From what I can
> tell, drivers actually implement the forwards movement.

I’m not sure why you’re considering the behavior you’re seeing is an error. If it works, great. But XMS 3.0 compliant XMMs are not required to ensure that it behaves the way that you are seeing. The spec does not say it will not work. My guess is that the XMM you are using has a double buffering 0Bh function which makes it safer in this case. I’m sure the concern was not requiring XMMs to have such implementations to save on code and memory space.

ecm

Düsseldorf, Germany,
27.04.2019, 21:40

@ Oso2k

Error in XMS specification?

Post reply

> I’m not sure why you’re considering the behavior you’re seeing is an error.

I'm not considering any of the behaviour an error, just the description. Forward moves in overlapping areas work when the destination is lower, not the other way around.

> If it works, great. But XMS 3.0 compliant XMMs are not required to ensure
> that it behaves the way that you are seeing. The spec does not say it will
> not work. My guess is that the XMM you are using has a double buffering
> 0Bh function which makes it safer in this case. I’m sure the concern was
> not requiring XMMs to have such implementations to save on code and memory
> space.

Nitpick: Double buffering isn't required to make backwards moves in overlapping areas work. Just moving from the back to the front, ie high addresses towards lower ones. (To implement moving within overlapping areas that has a lower source than destination, I do actually use a transfer buffer that temporarily holds a chunk of the data. But if a driver itself implements movement, no such buffering is needed.)

Actual reply: I'm not sure what you are talking about. The specification clearly states that only one direction of movement works in overlapping areas. If it is forwards (front to back, low to high) then the destination must be lower, no?

---
l