/dev/clipboard

[Robert Collins]

Success! I have a fully read/write /dev/clipboard that doesn't alter the
data at all(note 1). 
* seek() is implemented as rewind() for now.
* Competing process's should be atomic for clipboard access.
* Data written is available as soon as it is written
* Binary (non-text data types) data crashes cygwin on read (you can't
have everything :]).

Todo:
* Handle the core windows datatypes (ie translate dropped files into a
list of cygwin paths, DIBS into binary data..)
* Handle binary data (this involves registering a custom CYGWIN
clipboard format that is self-terminating. Unfortuneatly this means that
windows apps won't read the clipboard unless we handle delayed
rendering.. or always put a CF_TEXT|OEMTEXT version on the clipboard as
well.).
* Allow arbitrary seek() calls.
* Allow fstat() to return the current data size of the clipboard.
* Allow ls /dev to show clipboard
* Allow ls / to show /dev

Wishlist:
* Someone else to find a testkit for /dev/clipboard.
* Vi/Xterm etc etc etc to all support /dev/clipboard automagically.

Questions from me:
If we want to support delayed rendering for non-native datatypes (And
long term that's probably a good idea - if people start putting Mb's on
the clipboard, their memory usage might get quite high if cygwin allways
puts 3 copies on the clipboard :]) then I need to be able to process WM_
style messages. I'd like a pointer to getting those under cygwin. The
second issue with doing that is that the actual process that puts the
data on the clipboard will usually have quit with cygwin - so I'll be
looking at a daemon for handling delayed rendering - or something of the
kind. Obviously delayed rendering is a long term project though :]

I'm happy to send in a patch now, or get a few of the TODO's done
first... any other requests anyone?

(note 1: ascii 00's are lost currently (Binary data), but otherwise, cat
foo > /dev/clipboard && cat /dev/clipboard > foo2 && diff foo foo2 shows
no differences.).