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=dmCD7txlHnM2phFe4C6XmJlyxAHNI7Zq6JAK/qjm4WkjMugVp/fFg
	smlVdldaAWCP/cQn8c2n4mKZR0UmXSxEKFYEhXZuPXZLVUzcCs6jk3z9ZWiosmIC
	auO0sM8Wg8kqx9GKCs3UIu2Yf8vu/eXREhi0J1H45TPQpaoEBqr8FY=
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=sHdtwhdY7fGqwn7iVh5AW2q9c3w=; b=AFUBWhedF+HQSr3e3BIFn+XxLHRd
	ne1CQAaBsxsIf9gHzlsd573A9O9bPDJStr/uHwRu8xGDm06w5FGXwn7eYWX0Kd3E
	BX+9VHQ4RqkigHEHGrctVBXX3eYH7vwHfXsuJB/GxyjqLcplp23HubHDtZp4mVgs
	Va2fAKekVahIVNI=
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.5 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED autolearn=ham version=3.3.2
Date:	Fri, 23 Aug 2013 11:49:19 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Why are the 32- and 64-bit cygwin1.dlls incompatible?
Message-ID:	<20130823094919.GT2562@calimero.vinschen.de>
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>
MIME-Version:	1.0
In-Reply-To:	<CA+sc5mnedD0hOfzwTWYzy0QVhKC9gg-C68Nxfska-HG0HFOpLQ@mail.gmail.com>
User-Agent:	Mutt/1.5.21 (2010-09-15)
X-Virus-Found:	No

--OelmujB7rQAg+yu0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 22 16: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, and via a special parameter to the
> > CreateProcess call with the mysterious name "lpReserved2".
> >
> > One problem is the differences in basic datatypes, which results in
> > incompatible datastructures between 32 and 64 bit.  While this could be
> > worked around, this doesn't help for the shared memory stuff, which
> > depends on the installation path of the cygwin DLL.  The Cygwin DLL in
> > C:\cygwin1 would use a different name for the shared mem regions than
> > the Cygwin DLL installed into C:\cygwin2, independent of the target
> > architecture.  This is by design since Cygwin 1.7.  One effect:  No tty
> > sharing.
> >
>=20
> Since you know that the DLL regions are different what about execing
> the process as if it were a windows native process?  I know you loose
> the ability to do the parent/child relationship but it isn't any worse
> than spawning a native process.

Actually, Cygwin alread did that.  When checking the executable to run
for being a Cygwin process, executables with the wrong bitsize were
treated as non-Cygwin executables.

The actual problem was that we always propagate a child_info_spawn
structure to the child via STARTUPINFOW::lpReserved2, no matter what
kind of executable we execute.  The header of this structure is
identical on 32 and 64 bit, so the child process recognized it as a
child_info_spawn block, regardless of the target size of parent and
child.  But then the rest of this child_info_spawn differs a lot due to
different datasizes.

Since it neither makes sense to propagate the Cygwin-specific
child_info_spawn block to native processes, nor to Cygwin processes
with a different bitsize, I just disabled this, so you can now start
32 bit Cygwin processes from 64 bit Cygwin processes and vice versa,
starting with the snapshots I'm just generating.

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.  Here's a typical 32 bit bash started from 64 bit
tcsh in a 64 bit mintty, for instance:

  tcsh-64$ /cygdrive/c/cygwin/bin/bash -i
  bash: cannot set terminal process group (-1): Inappropriate ioctl for dev=
ice
  bash: no job control in this shell

  $


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--OelmujB7rQAg+yu0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSFzAfAAoJEPU2Bp2uRE+gS94P/jY+GneRaI59yEm176wESrV+
xc0ibNy6GZG7AItMlOZD/uhn7oBaox3LTKnTySgbKpCvT2bhg0ZgJhCjIUynN3yd
QauQgdhCGplrsFZH7KQRFaSPtcyy55BIKo+DkyExzg/5Qu4Rygx5l2x1V/rT8s8c
bvVy6nFXxPO/4p4uLIhpjrubP5oJni+N8ygquE/0ETY+UKPGdn3GAne9/3ruJS2F
TNjUbr+/pBGvat6O3J1uCy3yrgusEThyeXblBUCyMtDVVMg6KlWoWJjGktrUdeSD
gAH3csdzEtW+/TJBTsj+0Z7vmIOSdU/LSJ5IsIGocF/VAjIfsWlnjClcO3vcgKxo
3ld7sieFcYDQCZWR0IKapLe9IJBJ7nJlfycOQnQYiQtxVgN9pPg/W5VGKQBbcCq3
9tEPmXxoS0Jk9h+GQ/qxoPCy3w+VYdGqDdV+y3DkBmNUUuGgEd49ouM2mmQwieVL
vh/bVoxuiT61rGzwByiSWh/NWtJMzdJhyc4OLhKWMcXUeHBErUTe5lgzWViFvHNp
K2pgU4a+S849Qpjx8fVciKYKXEkhLUVg+vgx6eFQZDwRZTAAwErYgmL/za0QoBrf
lKcj11n/LYlPNFdOQmsOz0prpWKFJSAal8APGkqwdIk0sdEuhiQhcME7+pYwM4cj
eR9CBSeTJStqga7ruqlJ
=QYgH
-----END PGP SIGNATURE-----

--OelmujB7rQAg+yu0--

- Raw text -