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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=QF9HyF2zSTKnJxwYMCuaBy3EFQ8GC4xvdCr7035pnv5
	p8zOHXlVSbLc4bjsWzGgfUFcCTXZ8NOvNI1vYdc52ZEN1oWbGjO9/xA9gzJ+flL0
	n4CukTglP7LPLSufiWOJ8nzPWMhdAq+xQ8vcHmGTJwyV+wSkDOEzNXVQS0fHVI5g
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=yvG6uujnhdvSvl9oJY1a82PYSFs=; b=bStpvGcpo5IrDLUqt
	+ocl8E6la0VBHRiweUyR0qtmTjUekgB/5lV2c8rVrbJz0OkaWSU4oUjsj8fAnYIF
	Ef9lFgz0QICOFeyFvqlfC1IlO2AeyB/F9jDbAQQpFU1yza+dG+c1U1bSgQXAcT4q
	L0tjA6twsCb2iWFj1H5uTTWJJI=
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=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2
Message-ID:	<52167A63.6050906@etr-usa.com>
Date:	Thu, 22 Aug 2013 14:53:55 -0600
From:	Warren Young <warren AT etr-usa DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version:	1.0
To:	Cygwin-L <cygwin AT cygwin DOT com>
Subject:	Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?
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>
In-Reply-To:	<CA+sc5mnedD0hOfzwTWYzy0QVhKC9gg-C68Nxfska-HG0HFOpLQ@mail.gmail.com>

On 8/22/2013 14:46, Earnie Boyd wrote:
> On Thu, Aug 22, 2013 at 1:14 PM, Corinna Vinschen wrote:
>>
>> When execveing a Cygwin process, a lot of data is submitted via shared
>> memory, via data copying...
>
> Since you know that the DLL regions are different what about execing
> the process as if it were a windows native process?

That was my thought.

I assume this data sharing stuff occurs only for Cygwin-to-Cygwin 
exec()s, which is why -- as I recently learned -- cygwin1.dll already 
checks the DLL dependency graph of a process it's about to exec to see 
if it's a Cygwin process.

Couldn't it use this same info to detect that it's about to launch a 
Cygwin program of a different bitness, and fall back to the "native 
Windows program" case?  No attempt to interoperate, just launch it and 
hope for the best.  Fire and forget.

 >> Therefore, interaction between the 32 and 64 bit DLLs is not
 >> supported.

I'd expect it to behave no better than launching a native Win32 console 
program from Cygwin today.

The thing is, that's good enough for a lot of cases.

Consider Orpie, which isn't ported to Cygwin 64 yet because OCaml isn't. 
  Does it really do any kind of interop that would require a "native" 
Cygwin 64 port?

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