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: RFC: Cygwin 64 bit?


On Jun 27 20:11, JonY wrote:
> On 6/27/2011 20:00, Ryan Johnson wrote:
> > On 26/06/2011 8:52 PM, JonY wrote:
> >> On 6/27/2011 01:59, Corinna Vinschen wrote:
> >>> Right, but that wasn't what I meant.  Sorry for being unclear.  I was
> >>> talking about the name of the Cygwin DLL.  For instance, if we decide
> >>> that it must reside in the /bin directory, it must have a different name
> >>> than the 32 bit dll, for instance, cygwin64-1.dll.  If we decide that
> >>> all 64 bit applications and DLLs reside in a parallel directory, it
> >>> could have the same name, for instance, /bin64/cygwin1.dll.
> >>>
> >>> But let's not go into too much detail yet.
> >>>
> >> I was thinking that we have them totally separated, so we don't need to
> >> deal with DLL name clashes. Eg C:\Cygwin for 32bit and C:\Cygwin64 for
> >> 64bit. No need to invent bin32 or bin64.
> > ++
> > 
> > We'll probably have to tweak %PATH% per-app, though -- 64-bit apps would
> > need the Cygwin64 first and Cygwin second, with that reversed for 32-bit
> > apps.
> > 
> 
> How does that happen for per-app?

I'm wondering that too.  I don't see any reason to change that at all.
On a 64 bit system,m the 64 bit binary path comes first, then the 32
bit binary path.  On a 32 bit system, there won't be any 64 bit path.
Assuming we won't go single bin dir anyway.

> >>>>> - Create a x86_64-pc-cygwin cross toolchain.
> >>>> Yeah, I suppose newlib has to be ported first.
> >>> Right, I forgot about that one.  But newlib works rather well for many
> >>> systems, so that shouldn't be much of a problem.
> >>>
> >> There's that hairy LP64 vs LLP64 issue, personally, I'd prefer the LLP64
> >> route since Cygwin is a translation layer and will need to communicate
> >> with Windows at the backend, but I suspect many more will want the LP64
> >> route for Posix software compatibility.
> >>
> >> I suppose there could be a minimalist Cygwin fork of the win32api to
> >> make it LP64 compatible. Maybe a thunk/translator layer will be easier.
> > I suspect we'll come out ahead in the end by following Linux and doing
> > the translator -- the number of native windows apps compiled with
> > cygwin-gcc (and which can't use mingw-gcc) seems a rather small fraction
> > of the total, and posix apps could become a royal pain to compile on
> > cygwin if sizeof(long) != sizeof(void*).
> > 
> > 
> 
> So, some sort of thunk server/client thing in between the Cygwin DLL and
> system DLL?

What is that good for?  Cygwin apps are POSIX apps, Cygwin DLLs are
POSIX libs.  They only interact with the Cygwin DLL.  If they also
use Win32 API, they are on their own and they better use Win32 types
like DWORD, etc.  I don't see any need to make this even a bit more
complicated than necessary.  Apart from that, the only non-POSIX
DLL is the Cygwin DLL itself.  If it doesn't interact cleanly with
the Win32 API it goes boom and we fix.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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]