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>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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