Visual Studio 2010 use a compiler that supports only C89, which
only supports declaring variable at top of a local scope. Moving
scope variable to the top of function should solve this problem.
The second step of raw transfer is to transfer the format data itself.
This has been already implemented in XFreeRDP before, but several
tweaks are required for it to work correctly.
The idea of raw data transfer is to request for _FREERDP_RAW clipboard
format while putting the actual formatId into _FREERDP_CLIPRDR property
where the requested data is expected to arrive to. Then the clipboard
owner will check for the real formatId and deliver the expected data.
This stays true, but the check is performed in a more straightforward
way, and CF_RAW format (numerically equal to zero) is not considered
an unknown destination format when performing (identity) conversions
with wClipboard. This is not an issue because wClipboard will allow
only identity conversion for CF_RAW, it will fail if something else
is going to be converted into CF_RAW.
The first part of raw transfer sequence is to transfer the format
list of the session A into the session B. Then we will be able to
request/reply with raw data using proper format IDs.
xf_cliprdr_server_format_list() of the session A now exposes the
raw server format list. As soon as the list is received, it is
serialized and put into _FREERDP_CLIPRDR_FORMATS property.
xf_cliprdr_get_requested_targets() of the session B now checks
whether the clipboard owner is a FreeRDP session with enabled
raw transfer capability. If it is, the raw format list is simply
extracted from _FREERDP_CLIPRDR_FORMATS of the clipboard owner.
Otherwise, the format list is populated from the usual TARGETS
clipboard format.
Some time ago there was a property _FREERDP_CLIPRDR_ID which was indended
to indicate that an XFreeRDP window owns a clipboard. This was necessary
for raw transfers. This property was used by xf_cliprdr_is_self_owned()
function. However, raw transfer support was broken and the meaning of
xf_cliprdr_is_self_owned() gradually changed into checking whether
the *current* window owns the clipboard, not just any XFreeRDP window.
Thus _FREERDP_CLIPRDR_ID was removed in a4580923e7 (xfreerdp/clipr:
fix self owned test and hardening).
However, now we are going to fix raw transfers and we need that property.
This patch reintroduces a similar property "_FREERDP_CLIPRDR_RAW" which
indicates that a window is an XFreeRDP window with enabled raw transfer.
It is currently used by xf_cliprdr_server_format_data_request() to
correctly request format data from another XFreeRDP instance via raw
transfer protocol.
This property can be queried from the clipboard owner with the function
xf_cliprdr_is_raw_transfer_available() and can be enabled or disabled
on the current window by xf_cliprdr_set_raw_transfer_enabled().
Disabling raw transfers will be necesary to correctly implement file
transfers in the future. However, currently raw transfers are always
enabled.
xf_cliprdr_send_data_response() is consistently called with NULL
data pointer as a way to report errors, but it was not setting
the msgFlags field accordingly.
Sometimes Windows sends strings with excess null terminating bytes.
For example, when one copies digits from calc.exe. At the same time,
some local applications freak out when they encounter null bytes
(at least LibreOffice is known to be replacing them with '#').
According to the specification of UTF8_STRING format [1], the string
data must not contain any trailing null bytes. So they all should be
trimmed, not only the last one.
Also, if the trailing null byte is not present, the length should not
be adjusted. For example, Firefox is actually sending "HTML Format"
without a null byte while Internet Explorer adds one. The spec for
text/html format [2] says nothing about the teminating null byte, so
we are free to remove it, but at least we should not mistakingly
delete '>' character of "</html>" tag when it is the last character.
[1] http://www.pps.univ-paris-diderot.fr/~jch/software/UTF8_STRING/UTF8_STRING.text
[2] https://www.ietf.org/rfc/rfc2854.txt
