-------------------- AmigaOS 3.1.4.(1) project -----------------------

Changes for release 45.1 (23.6.2017)

- Reading and writing clips into the clipboard was Forbid-locked,
  with possible drastic consequences on the multitasking. This
  was changed to a semaphore. Furthermore, this might have
  caused several race conditions in multiple places because the
  device also used semaphores to protect some other critical
  elements such as the clip hook list.

- Writing with an io->io_Offset beyond the end of the clip was
  documented to extend the clip with zeros. This was, however,
  incorrect in case the clip was off-loaded to disk. Results
  where handler-dependent and may or may not have extended the
  clip at all.

- In case the clip was swapped out, and the clipboard was re-
  opened, swapping in did not test for low-memory configurations,
  unlike the write command.

- The clipboard always assumed that the clip written is in IFF
  format. While documented, this is still a fragile design as
  the clipboard always assumed that bytes 4 to 7 contained the
  length of the clip.

- The clipboard device supports now NSDCMD_QUERY.

- Note that even though the clipboard.device was documented to
  support CMD_RESET, it actually never did. It just returned
  with an error. This did not change.

- The clipboard hook was also called if after a CBD_POST the
  same command was issued again to change the receiver of a
  post request. However, the state of the clip does then not
  change, hence there is no need for the hook in first place.

- Some combinations of commands, e.g. a WRITE after a POST
  might have locked up the clip completely, i.e. no further
  operation was possible and the state did not progress at all.

- The clip hook was also called in case the clip did not contain
  valid data because the clipboard device run out of RAM or
  disk space in the middle.

- If IORequests from multiple tasks arrived at the same time,
  it might have happened that the clipboard device became confused
  and did not process them correctly in the sense that the
  actual stage the clipboard device moved to did not correspond
  to the request submitted.

- While CBD_CURRENTWRITEID works as designed, its output may
  not be as useful as one may wish because the device can process
  a clip at any time, and hence may return information that
  becomes obsolete as soon as some other task tries to use it.

- The clipboard.device specified that seeking behind the end
  of the file while writing inserts zeros between the current
  end position and the seek target. This was not the case if
  the clip was swapped out to disk, it rather depended on
  file system internals what happened - most likely data was
  written in the wrong place.

Changes for 45.2 (25.6.2017)

- There was still a race condition in the code. In case task 1
  left a clipboard unit just while task 2 has queued a request,
  task 2 would not get the unit, but task 1 would no longer
  process the request. Now task 1 first drops the clipboard
  unit, then unlocks the queue so task 2 has a chance to enter
  the processing loop while task 1 is leaving it.

Changes for 45.3 (8.7.2018)

- NSCMD_DEVICEQUERY did not set nsdqr_SizeAvailable correctly.

---------------------------- AmigaOS 3.2 project ---------------------

Changes for 45.4 (17.9.2019):

- If io_Length on a CMD_READ was so large that an integer
  overflow occurred in the offset computation, the clipboard
  did not actually recorded the EOF condition at all.