This is the mail archive of the cygwin-developers 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: Resurrect discussion: Mixing 32 and 64 bit distro


On Feb 12 11:26, Christopher Faylor wrote:
> On Tue, Feb 12, 2013 at 04:40:09PM +0100, Corinna Vinschen wrote:
> >On Feb 12 10:29, Earnie Boyd wrote:
> >> On Tue, Feb 12, 2013 at 8:40 AM, Corinna Vinschen wrote:
> >> > Hi guys,
> >> >
> >> >
> >> > I slept a bit bad tonight.
> >> >
> >> > As you may or may not remember, we had a discussion about how to go
> >> > forward with a 64 bit distro in 2011.
> >> >
> >> > In this discussion I held vehemently to the view that we have to create
> >> > the 64 bit distro in a way which allows to mix Cygwin 64 and 32 bit
> >> > applications freely.  My main point was that it may take a long time
> >> > until we get all the Cygwin 32 bit packages built for 64 bit, and
> >> > therefore have to provide a mix so that users can adopt the 64 bit
> >> > distro early without having to drop the tools they are using.
> >> >
> >> > But is that really so?  I'm not so sure anymore.  Maybe that problem
> >> > is exaggerated or overvalued.
> >> 
> >> Maybe overvalued.  Would an idea that 32bit executables use the 32bit
> >> runtime and 64bit executables use the 64bit runtime be bad?  So for
> >> the time being deliver both 32bit cygwin1.dll and cyg64w1.dll (I
> >> forget what you called it) and allow the executables to use the
> >> correct version?
> >
> >That wasn't the question.  Of course, if you mix the distros, you will
> >have to provide two DLLs, one for 32 and one for 64 bit.  The question
> >is, shall the 32 and 64 bit Cygwin DLLs interact or not.   Keep 32 and
> >64 bit distinct from each other or not.  Even if you just mix them into
> >one /bin, you have to keep the new cyg64 DLL prefix.  But then again
> >you would get the same result by having two distinct distros and add the
> >other /bin dir to $PATH, without the requirement to keep the cyg64
> >DLL prefix.
> 
> I think two distinct distros with no explicit understanding between the
> 32-bit and 64-bit is the sanest approach.  I hate the thought of lots of
> code in 64-bit Cygwin to specifically deal with 32-bit aps.

It's worse.  For a smooth operation you have to take both scenarios into
account, 32 bit processes starting 64 bit processes and vice versa.
That means, the same special code, just for the opposite target, has to
go int the 64 bit and the 32 bit DLL.

> Would it be possible to write some kind of "shim" 64-bit application
> which "did something" to run a 32-bit Cygwin for people who can't
> wait to have their favorite package ported to 64-bit?

I'm not exactly sure what such a shim would have to cover.  You don't
see much of a problem running 32 bit Cygwin processes from 64 bit
processes and vice versa in simple cases, But if you run a 32 bit
process from a 64 bit tcsh running in a 64 bit mintty, the 32 bit
process doesn't know it's running in a tty.  Same goes vice versa.
I don't know how we would fix that.  Also, the paths in the environment
are off, because they are converted to Windows and then back to POSIX,
but on the way Cygwin's root dir has changed.
In the first place the problem is that the processes don't use the same
shared memory, in the second it's the missing data from the cygheap.
I have the vague feeling that if you start to create such a shim,
you could just as well change the Cygwin DLL to handle the situation.


Corinna

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


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