This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.
> >
> 
> 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 device
  bash: no job control in this shell

  $


Corinna

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

Attachment: pgplJoo2e1QOs.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]