Clipboard size limit?

[asmaloney]

I'm guessing that this is a VMwareAddons issue...

If I select a bunch of text in Haiku running in VMWare, copy it, and paste it on the macOS side, only 65,436 characters are pasted (which looks like it's getting close to a special number 😄 ).

(Haiku was installed from the Haiku R1/Beta2 x86_64 image and everything is up-to-date.)

[adamfowleruk]

Some interesting size_t/long/ulong conversions going off in here:

VMwareAddons/enhanced_backdoor/VMWBackdoor.cpp

Line 351 in aed6f60

long i = text_length;

Shouldn't be the cause given the datatype sizes in play, but worth looking at generally... backdoor_call expects a ulong.

Failing that, need to look into the copy function link between Haiku and this plugin...

[adamfowleruk]

Called from within the AddonsTray C++ file here:

VMwareAddons/vmware_tray/VMWAddOnsTray.cpp

Line 179 in aed6f60

case B_CLIPBOARD_CHANGED:

This uses std::size_t too though. So unless the clipboard message from Haiku is limited in length (seems unlikely...) there must be a logic/datatype issue in one of the above functions.

[adamfowleruk]

Confirmed the bug occurs on Haiku Beta3 64 bit with Depot version of vmware addon (1.2.0-4) and Windows 10 host with VMware Workstation 16 Player. It copies 65221 characters only from Haiku to the Win10 host.

Also confirmed a similar bug copying from a Win10 host to a Haiku Beta3 guest, but it copies up to 216636 characters

[OscarL]

While trying to debug #12, I've added a syslog line to monitor the requested size used when calling VMW_BACK_SET_CLIP_LENGTH, and to see if it returned anything meaningfull in eax.

Then I tried to copy a >100 KB of text (from guest to host), the following lines appeared in syslog:

USER: VMWBackdoor::SetHostClipboard: frame.eax.word = 0 (requested size was: 136246)
USER: VMWBackdoor::SetHostClipboard: frame.eax.word = 0 (requested size was: 65436)

Where that second line is comming from?

When copying the lines above, I got:

USER: VMWBackdoor::SetHostClipboard: frame.eax.word = 0 (requested size was: 168)

which looks OK.

And after I again copied the >100 KB text, got:

USER: VMWBackdoor::SetHostClipboard: frame.eax.word = 0 (requested size was: 168)
USER: VMWBackdoor::SetHostClipboard: frame.eax.word = 0 (requested size was: 136246)

Which looks extra weird (the "repeated" 168).

After I pasted it on the host, I got again:

USER: VMWBackdoor::SetHostClipboard: frame.eax.word = 0 (requested size was: 65436)

Which sounds odd. Why SetHostClipboard() gets called after a paste on the host side?

[OscarL]

According to https://web.archive.org/web/20100610223425/http://chitchat.at.infoseek.co.jp/vmware/backdoor.html, at least in the host->guest direction, the cliboard size is limited to 65335 on older versions of VMware, and to 65336 on "WS4.5/GSX3.2 and later".

So, it seems that, as long as we use this "VM backdoor" mechanism for comunication, we're stuck with this limit.

Oh, well. Will at least do a PR for some code clean up around the clipboard logic.