CoRD is a Mac OS X remote desktop client for Microsoft Windows computers using the RDP protocol. It's easy to use, fast, and free for anyone to use or modify.
Here's a fix for a clipboard issue that has been annoying me for some time now:
Steps to reproduce:
On a windows machine (I tried 2008r2) connected to with CoRD, in a console window (the thing that hosts programs like cmd.exe and powershell.exe), select a rectangle of text (because clearly text comes in rectangles, according to the console window) and hit enter to send it to the clipboard. On your Mac, paste into e.g. TextEdit or Cocoa Emacs.
In another CoRD session, paste into some editor
Observed:
step 1: The copied text is pasted, but it is followed by random unicode characters (statistically you're likely to see Chinese ideograms often).
step 2: Either the same as step one, or the app being pasted into hangs for some time and rdpclip.exe on the target machine becomes very sad.
Analysis:
The clipboard data I've observed coming in from the windows machine to CoRD usually consists of the copied text followed by a U+0000. Together they exactly match the buffer length. However, the console window (and perhaps some other windows apps) sends the copied text followed by a U+0000 and then some arbitrary amount of garbage (looks like it mallocs an oversized buffer from the heap and doesn't wipe it. I've seen text that I didn't select and I've seen SIDs; I'm sure that's not at all a security risk).
The local windows clipboard seems to be fine with this. It pastes only up to the first U+0000 character. Interesting test: run two emacses on windows, type something like "hi [CTRL-Q][CTRL-@] there!" in one (CTRL-Q followed by CTRL-@ inserts a U+0000), then copy it to the other emacs (or notepad or whatever). The result will be "hi ". Copying within one emacs results in a copy of the whole string because emacs handles it without the system clipboard.
CoRD assumes that the buffer it receives is no larger than the text plus a terminating U+0000, so it happily puts the garbage part of the buffer on the Mac's clipboard.
Fix:
This fix only copies the text it receives from RDP up to the first U+0000, or it copies the entire buffer if the buffer contains no U+0000.
This fix breaks CoRD's ability to copy U+0000-containing text from Windows to Mac. The fact that you can't copy U+0000-containing text within Windows either makes that acceptable, IMHO.
hi
Here's a fix for a clipboard issue that has been annoying me for some time now:
Steps to reproduce:
Observed:
step 1: The copied text is pasted, but it is followed by random unicode characters (statistically you're likely to see Chinese ideograms often). step 2: Either the same as step one, or the app being pasted into hangs for some time and rdpclip.exe on the target machine becomes very sad.
Analysis:
The clipboard data I've observed coming in from the windows machine to CoRD usually consists of the copied text followed by a U+0000. Together they exactly match the buffer length. However, the console window (and perhaps some other windows apps) sends the copied text followed by a U+0000 and then some arbitrary amount of garbage (looks like it mallocs an oversized buffer from the heap and doesn't wipe it. I've seen text that I didn't select and I've seen SIDs; I'm sure that's not at all a security risk).
The local windows clipboard seems to be fine with this. It pastes only up to the first U+0000 character. Interesting test: run two emacses on windows, type something like "hi [CTRL-Q][CTRL-@] there!" in one (CTRL-Q followed by CTRL-@ inserts a U+0000), then copy it to the other emacs (or notepad or whatever). The result will be "hi ". Copying within one emacs results in a copy of the whole string because emacs handles it without the system clipboard.
CoRD assumes that the buffer it receives is no larger than the text plus a terminating U+0000, so it happily puts the garbage part of the buffer on the Mac's clipboard.
Fix:
This fix only copies the text it receives from RDP up to the first U+0000, or it copies the entire buffer if the buffer contains no U+0000.
This fix breaks CoRD's ability to copy U+0000-containing text from Windows to Mac. The fact that you can't copy U+0000-containing text within Windows either makes that acceptable, IMHO.