RFC: Cygwin 64 bit?

[Ryan Johnson]

On 28/06/2011 4:42 PM, Corinna Vinschen wrote:
> On Jun 28 22:36, Thomas Wolff wrote:
>> Corinna wrote:
>>> The original idea to keep the DLLs in /bin was to allow running Cygwin
>>> applications from a non-Cygwin process without hassle.  A typical
>>> example is CMD.  You can simply chdir to C:\cygwin\bin and run `ls'.  If
>>> /lib contains all the DLLs, this will break unless C:\cygwin\lib is in
>>> %Path%.
>>>
>>> Also, you can't just create a bash shortcut on the desktop, unless you
>>> really know what you're doing (set the start directory in the shortcut
>>> to C:\cygwin\lib).  When moving the DLLs out of /bin, you add some new
>>> hurdle to using Cygwin.
>>>
>>> Without this problem, or if we decide to ignore this problem, I would be
>>> all for moving DLLs to /lib or /lib64.
>> Can't cygwin compilation ensure that the cygwin1.dll is always
>> loaded first so it could take care of this (if only by then adding
>> to the path)?
>> (I guess the answer may be no because Windows is juggling with the DLLs...)
> Yes, the answer is no.  At least it's very likely no.  Even if Cygwin is
> loaded first, I'm not aware that changing $PATH from within the DLL
> entry point will influence the Windows loader for this very process.
> Somehow this even sounds like a potential security problem.  Otherwise,
> for Cygwin distro DLLs it's pretty sure that the Cygwin DLL will be
> loaded first, since every subsequent DLL depends on it.
The answer is definitely "no." Windows can map dlls in any order it 
pleases, and is only semi-required to initialize them in dependency 
order (because dlls are often circular dependent anyway). In particular, 
dlls which suffer base address collisions tend to be loaded before 
cygwin1.dll

Ryan