The Citrix Clipboard (Part II)

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

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.


Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide

Posted in PortICA
3 comments on “The Citrix Clipboard (Part II)
  1. Simon Bramfitt says:

    This is delightful stuff Jeff.

    I can’t say that knowing this will actually help me address any of the problems I face today, but it certainly will help me make moer informed ehancement requests in the future.

    Please keep it up.


  2. Hi Jeff,

    I wrote an article explaining in pictures why cut’n’paste doesn’t work:

    There is also a tool I wrote to fix clipboard issues in ICA sessions (recently updated):

    Dmitry Vostokov

  3. The Blogospheric History of XenDesktop…

    There have been many good posts in the blogosphere about XenDesktop that I have bookmarked.  Since this site did not exist when all the posts were made,……

Comments are closed.

Follow Red Circle Blog on
%d bloggers like this: