* Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit
[not found] ` <12fea3e3-92ae-2a33-81ea-808bdcc20f2a@maxrnd.com>
@ 2021-10-27 9:01 ` Thomas Wolff
2021-10-27 9:52 ` Corinna Vinschen
0 siblings, 1 reply; 2+ messages in thread
From: Thomas Wolff @ 2021-10-27 9:01 UTC (permalink / raw)
To: cygwin-developers
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
^ permalink raw reply [flat|nested] 2+ messages in thread