Why are the 32- and 64-bit cygwin1.dlls incompatible?

[Larry Hall (Cygwin)]

On 8/26/2013 9:51 AM, Christopher Faylor wrote:
> On Mon, Aug 26, 2013 at 11:04:06AM +0200, Corinna Vinschen wrote:
>> On Aug 25 13:26, Christopher Faylor wrote:
>>> On Sun, Aug 25, 2013 at 11:05:06AM -0400, Earnie Boyd wrote:
>>>> On Fri, Aug 23, 2013 at 3:16 PM, Christopher Faylor wrote:
>>>>> I was having a private chat with Corinna about this.
>>>>>
>>>>> Her doubts above mirror mine.  I wonder if this will add to the traffic
>>>> >from people who, e.g., expect their java apps to understand Cygwin
>>>>> ptys.  Now we will have people who don't understand why their 32-bit
>>>>> screen doesn't work under 64-bit Cygwin mintty.
>>>>>
>>>>> The original error message was certainly not clear but maybe we need to
>>>>> have something like:
>>>>>
>>>>> "Can't run 32-bit Cygwin programs in a 64-bit Cygwin environment"
>>>>>
>>>>> and vice versa with a, as you say, (ugh) way to turn this on and off.
>>>
>>>> What about CYGWIN=32bitCygwinExec or some such?
>>>
>>> Yes, we were talking about a CYGWIN environment variable.  It would
>>> probably be something like "arch_mismatch".  However, you're jumping to
>>> implementation when it isn't even clear if this is something that we
>>> want to do.
>>
>> We shouldn't overburden the CYGWIN env var with lots of tiny, nagging
>> settings which are just as easy to keep in all the time.  Letting the
>> 32 bit version of Cygwin run 64 bit apps...
>>
>>>> And what about the other direction?
>>>
>>> Apparently "vice versa" is not a universally understood term.
>>
>> ...and vice versa doesn't cost us anything.  We add a FAQ people can be
>> pointed to and that's it.
>
> When I said "vice versa", I meant that we might need the same clear
> warning for 64-bit programs running on 32-bit platforms.  I'm still not
> clear on why this requires so much clarification.  But that's all right.
> No need to enlighten me.  I'll just chalk this up to the Cygwin mailing
> list confusion vortex.
>
> You know I'm not a big fan of adding options to the CYGWIN environment
> variable but I'm less of a fan of having people whine about something
> not working, indignantly telling them to read the FAQ, and then having
> them whine that there is no workaround.
>
> This could all be a non-issue.  I was just trying to brainstorm and
> think ahead.  But there's always that pesky vortex.

Indeed.  I can feel the vortex tugging at my brain. ;-)

I'm wondering if we going to go the interop route with the CYGWIN
environment variable switch and such if it doesn't make sense
to have the option be off by default but "detection" be on.  In
this case, the user would be warned about what's going on and
could be pointed to more info on how to turn on interop if that's
desirable.  I'm only proposing this in hopes that it would help avoid
lots of confusion about why things do and don't work in interop mode.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple