Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit

[Thomas Wolff <towo@towo.net>]

Am 23.10.2021 um 07:35 schrieb Mark Geisert:
> Hi all,
>
> Corinna Vinschen wrote:
>> On Oct 11 08:11, Ken Brown wrote:
>>> On 10/11/2021 2:13 AM, Mark Geisert wrote:
>>>> It's just that after submitting the patch I realized that, if we 
>>>> really
>>>> are going to support both Cygwin archs (x86_64 and i686), there is 
>>>> still
>>>> the issue of different cygcb_t layouts between Cygwin versions being
>>>> ignored.
>>>>
>>>> Specifically, the fhandler_clipboard::fstat routine can't tell which
>>>> Cygwin environment has set the clipboard contents.  My original patch
>>>> takes care of 32-bit and 64-bit, providing both are running Cygwin >=
>>>> 3.3.0 (presumably).  What if it was a different version (pre 3.3.0) 
>>>> that
>>>> set the contents?
>>>
>>> I wonder if this is worth the trouble.  Right now we have a problem 
>>> in which
>>> data written to /dev/clipboard in one arch can't be read in the 
>>> other arch.
>>> The fix will appear in Cygwin 3.3.0.  Do we really have to try to 
>>> make the
>>> fix apply retroactively in case the user updates one arch but not 
>>> the other?
>>
>> Just to close this up prior to the 3.3.0 release...
>>
>> Given we never actually strived for 32<->64 bit interoperability, it's
>> hard to argue why this should be different for the clipboard stuff.
>>
>> Running 32 and 64 bit Cygwin versions in parallel doesn't actually make
>> much sense for most people anyway, unless they explicitely develop for
>> 32 and 64 bit systems under Cygwin.  From a productivity point of view
>> there's no good reason to run more than one arch.
>>
>> So I agree with Ken here.  It's probably not worth the trouble.
>
> Sorry, I've been sidetracked for a bit.  I can agree with Ken too.  
> The only circumstance I could think of where multiple internal format 
> support might be useful (to non-developers) was some user hanging on 
> to an older Cygwin because it was needed to support something else 
> (s/w or h/w) old and non-upgradeable. Doesn't seem very likely at this 
> point.
>
> I'll try to get the v2 patch out over this weekend.  Same end-result 
> for same environments as the v1 patch, but incorporating all the 
> comments I received.
>
> To that end, does Jon's suggestion of /usr/include/sys/cygwin.h seem 
> like the best location to define struct cygcb_t for use by both Cygwin 
> and cygutils package?
> Thanks much,
>
> ..mark

Mintty uses the Windows clipboard directly, so it does not face this 
problem so far. However, that results in a timestamp of 1st Dec 2006 for 
/dev/clipboard. In order to avoid a complete reimplementation of mintty 
clipboard handling ("never touch a running system"), would it be 
possible to set the cygwin timestamp only, without affecting the 
clipboard contents, maybe using a new cygwin API function? Like `touch 
/dev/clipboard` which does not work however.
Thanks for considering
Thomas