DOS ain't dead

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

> 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.

> 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

> 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.

Just fixed this in my fork of emu2.

Quoting the long comment:

The overlap check was the wrong way around. It's likely because
it was incorrectly stated in the XMS specification.

Refer to https://www.bttr-software.de/forum/forum_entry.php?id=15907

Example:

  src < dst C=8
  SSSSOOOODDDD
  12345678
  ^ copy 1234 to OOOO
      ^ copy 1234 to DDDD

  src > dst C=8
  DDDDOOOOSSSS
      12345678
      ^ copy 1234 to DDDD
          ^ copy 5678 to OOOO

I did correct the check, but also disabled it and instead used memmove for every case. This simplifies the used code a lot. As it so happens, memcpy also worked on our Debian amd64 server, regardless of which way the overlap was, but I understand that this is not a well-behaved assumption.

---
l

Here's another piece of code explaining the overlap check for moving "down" (DF=1). If S < D and S + L > D then we are overlapping in the way requiring a backwards move.


        cmp ax, dx              ; source above destination ?
        ja .up                  ; yes, move up (forwards) -->
        je .return              ; same, no need to move -->
        push ax
        add ax, cx              ; (expected not to carry)
        cmp ax, dx              ; end of source is above destination ?
        pop ax
        ja .down                ; yes, move from top down -->
        ; Here, the end of source is below-or-equal the destination,
        ;  so they do not overlap. In this case we prefer moving up.

---
l

I'm guessing that the "reliability" may also depend on the amount of overlap. The overlap could be as small as 0 bytes (the source and destination are the same), and I don't know if there are alignment issues (like starting addresses must be Word-, DWord-, Paragraph, or Page--aligned).

At least theoretically, in a "well-written" app you wouldn't ever have any overlaps but that is, of course, unrealistic.

You are correct, though, that what's in the documentation (official or not) shouldn't be the exact opposite of reality.