Monthly Archives: May 2007

Last time I talked about the clipboard in connection with how it works with Citrix.  This time I am going to dive more into how certain aspects work and actually reveal a problem with how the clipboard virtual channel driver handles registered formats.

There are several types of clipboard data available.  The types basically fall into three categories.

• Standard Clipboard Data Formats
• Private Local Clipboard Data Formats
• Private Global Clipboard Data Formats

Standard and Private Local Clipboard Data Formats do not present a problem for Citrix.  Standard is not a problem since the clipboard format numbers are well known and are guaranteed to be the same between the client and server.  The Private Local Data Formats are only good within one program and therefore are not transferred to other programs (or to the opposite side).  However, the Private Global Clipboard Data Formats present a problem.  They are identified by a name (a string) that must be registered with Windows to get the session unique clipboard data format number.  The problem is that this number is not guaranteed to be the same between any two sessions (local or remote).  The protocol for the clipboard in ICA never allowed for this.

With the Citrix clipboard code, it needs to know ahead of time which registered formats are going to be used so that it can register them and send the numbers down to the client (with the names) so that the client knows how to translate clipboard format numbers between server and client.  The problem is that it would be impossible to anticipate all the possible format names.

Why is this important?

Without the extended support for registered format names, the Citrix clipboard is effectively limited to Standard and a limited set of registered format numbers.  This is bad for the sake of compatibility and severely limits the effectiveness of the Citrix clipboard.  A potential workaround is to add desired registered formats to the registry so that the clipboard driver will know about more formats and work more like local applications when it comes to transfers.

An example of this is found in a recent support document about the registered format “HTML Format”.

http://support.citrix.com/article/entry.jspa?entryID=12395

This trick would apply to any format you want to see supported.  If you want to actually figure out what formats you would like to support, go find a clipboard viewer like this one. Go to your favourite program and cut or copy something.  Once it is in the clipboard, go run the clipboard viewer (cbdump in this case) to determine the supported formats.  Don’t worry about the ones that start with CF_ since they are standard.  Worry about the ones that have interesting names like “HTML Format” and “Ole Private Data”.  Once you have an interesting set, use the registry trick to add these formats.  You will need admin access to the CPS machine to insert these keys/values.  Once added, you will most likely need to logoff everyone to get the benefits.  If someone is on the machine, the clipboard driver (VCLIPBD.DLL) will be in use by the Citrix Shell (WFSHELL) and will not be aware of the changes made to the registry.  The check for registry entries is only done at the load time of the clipboard driver.
I’ve played with this on PortICA and some amazing things start to happen.  Things that have always a pain to cut and paste are beginning to clear up.  Web browser based copies are now actually readable in other programs like Word.  Windows is starting to act more like it was meant to with regards to the clipboard.  This makes sense since the clipboard needs more advanced private formats to provide the best quality to the other consumers.

It would be much more ideal to handle the registered formats on the fly but that requires a clipboard protocol change which is currently beyond the scope of the PortICA project.  I’d love to see this work start soon than later but I’m also guessing that the clipboard is not the highest thing on the list of things to do for the next release.

Based on recent developments in PortICA, we will support more formats built into the driver (previously there was only three entries, now there is twenty two) and it now can learn which private formats are being used and apply them to the next session.  It can only update the client once at the start the of the session currently.

It was very rewarding to work on this old problem and now I fully understand why cut and paste doesn’t always do what I want between client and server.

There is still more potential detail to come for the Citrix Clipboard.  Not sure when but there will be a part III.

The Clipboard feature within CPS has existed in the earliest WinFrame going back to 1995.  I remember Marc Bloomfield working on this from even before this time.  It was one of the first virtual channel features that was new to WinFrame.  Many of the virtual channels were direct descendants of WinView.  I still remember seeing it working for the first time.  Very exciting at the time!

The idea was fairly straightforward.  It was thought that it should be possible to be able to cut from one side (server or client) and paste to the other side.  It sounded easy but how it works is a bit more involved.

The Clipboard has been around in Windows since Windows 1.0 in 1985.  I’m certain that the Mac had it before that and also sure that the idea could even predate the Xerox PARC systems.  The point is that the clipboard is key to supporting any cut/copy/paste operations.

There are some basic rules about clipboards that should always be followed on Windows.  First of all, all things in the clipboard are controlled by the user.  In other words, the program has no rights to add or remove anything unless the user has indicated that it should be done.  In a way, the clipboard is seen as a way station for data to be transferred either within the program or outside the program.

Second of all, the clipboard should only contain one item as a whole.  In the whole it can have many sub-elements but in no way should it allow for multiple different chunks of content to be inserted into the clipboard at the same time. It is possible to have a blob that contains many sub-elements but not to have many pieces at once.
The basic operation of the clipboard is that when a user issues a cut or copy, the program will take the selected data and submit it to the clipboard.  The format of the data is dependent on what the program supports and whether it is a known format or a new registered format (considered private).  It is legal to submit the data in multiple formats to the same clipboard.  In fact, it is encouraged to do this so that other programs can actually read the data in the formats they are used to.

As an example of this, if you cut a selection of text from a word processor, the text will be stored in at least two different formats.  One will be considered basic text and the other rich text format.  The basic text rendition will only have the text whereas the rich text format (RTF) will have the formatting and potentially the possibility of doing pictures.  In Microsoft’s world of doing clipboard, there are plenty of options of how to handle these requests.

The most simple model is this:

User does cut/copy
Program clears current clipboard
Program sets new data into clipboard

User does paste
Program gets data from clipboard

The interesting fact is that when the program to set clipboard data (SetClipboardData) it is allowed to do as many sets as it wants for as many formats as it wants.  When it does the set, it needs to allocate a chunk of global memory that it will never touch again.  It becomes Windows responsibility to free the memory when the next program issues the clear clipboard call (EmptyClipboard).  The global block of memory contains all the data needed for that format and it makes it easy to transfer to other programs.  It is kind of like taking a picture of data and then making it publicly available to other programs that understand that format.

There is a model of doing delayed rendering whereby you can delay putting data into the clipboard.  This is done to avoid wasteful use of memory for large clipboard items.  The idea calls for specifying that a format exists in the clipboard but not actually specifying the data.   When another program goes to get the clipboard data, Windows will notify the clipboard owner that it needs to give the memory contents now.  This is done by calling SetClipboardData during the WM_RENDERFORMAT message processing.  This is just a simple example of how it would be handled since there are two other possible window notifications with WM_RENDERFORMATALL and WM_DESTROYCLIPBOARD.

The delayed rendering turns out to be a very important technique for supporting Citrix ICA clipboard support.  Without this aspect, it would be necessary to download all the clipboard data every time the clipboard data changed.  The essential design calls for only downloading the information when the programs request it.  So, if the user cuts something on the server, it will only be transferred to the client if the user pastes on the client after the cut.  If this was not true, the cut/copy operations on each side would need to be duplicated on the opposite machine.  This would be bad since not all cut/copy operations are destined to be located on the other machine.  There would be much wasted bandwidth and more than likely the data would interfere with more important data like keyboard/mouse/video traffic.

The ICA protocol that handles the clipboard data is fairly simple.  There is only nine packet types that are used for the clipboard.  Of these, four are used for initialization.

The client and server negotiate what they can support by working together.  This includes the public and private formats.  Once negotiated, these are the only formats allowed to be transferred between sides. The clipboard driver uses the virtual channel as a conduit for the clipboard data.  Once a format is requested, the transfer will be split into multiple pieces if the transfer is bigger than what an ICA packet can handle.
In the next installment I will focus on the registered (private) formats and how it currently works with our clipboard driver.  I will also cover some of the things discovered while working on PortICA related to the clipboard.