X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=GiymXJZYvh7ozjmvUHkxAm1zOOoTBRxlkBPYJFHYmi/X+Xu3Bw/+K
	sR+PhcQsC62wYu6VqX8yuybzLgS1qCynkTTlY5+8Z5VR7mP4TOL+aquOdrgg0kM3
	jkRr6dQYqj0pMXWhx8w6H03ep/n8lT4qZoJsYkplqe3Iiv+RHCHIUU=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=JXsMz6JUeBdLuHQvDDo9+kNeQiE=; b=CW1V4f6Tx19aYkXUETzOA26J4LTX
	mfCEegn8XFiXNPG9MULhqfFWONvIwALtisljMKj7FI7iQDhcucxLm4fKdtQLr2Fh
	55Ln+hGghpQHjaD/5Y/MaM45l6u0ho2+PA82fgcF/xICLJ+4F0gXLLdNruFWOxZH
	ncNTJuR9p9qrmSI=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.2
X-Mail-Handler:	Dyn Standard SMTP by Dyn
X-Report-Abuse-To:	abuse AT dyndns DOT com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User:	U2FsdGVkX1+MKDIf2eMPX2DTx8PmamtU
Date:	Fri, 23 Aug 2013 15:16:01 -0400
From:	Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?
Message-ID:	<20130823191601.GA1446@ednor.casa.cgf.cx>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<52162CA9 DOT 9080002 AT etr-usa DOT com> <20130822171419 DOT GQ2562 AT calimero DOT vinschen DOT de> <CA+sc5mnedD0hOfzwTWYzy0QVhKC9gg-C68Nxfska-HG0HFOpLQ AT mail DOT gmail DOT com> <20130823094919 DOT GT2562 AT calimero DOT vinschen DOT de> <52178ED2 DOT 4090806 AT etr-usa DOT com> <5217A8A2 DOT 7060700 AT cygwin DOT com>
MIME-Version:	1.0
In-Reply-To:	<5217A8A2.7060700@cygwin.com>
User-Agent:	Mutt/1.5.20 (2009-06-14)

On Fri, Aug 23, 2013 at 02:23:30PM -0400, Larry Hall (Cygwin) wrote:
>On 8/23/2013 12:33 PM, Warren Young wrote:
>
><snip>
>
>>> I just hope this won't lead to more confusion if 32 bit processes
>>> started from 64 bit (or vice versa) don't act as expected in some
>>> circumstances.
>>
>> Oh, it probably will, but a cygcheck dump will tell us when this is probably
>> happening, because both Cygwin bins will be in the PATH.
>
>Probably but I think we need to keep a close eye on how much this adds to
>the support load and user confusion.  If it is more than a small amount, I
>think it's worth considering a sunset clause on this or perhaps a switch
>(ugh) to turn this on for those that know, love, and want it. :-)

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.

FWIW, I just made some modifications to Corinna's previous change.  The
latest snapshot reverts the behavior of not passing Cygwin blocks to
windows programs since that can subtly break cygcheck and strace.
Instead the process block magic number for 32/64 bit cygwin processes
has changed so that they don't think that they've received information
from a cygwin process.  It should have the same effect as the previous
change, with less modifications to code flow and without breaking
longstanding Cygwin dll behavior.

cgf

--
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

- Raw text -