RFC: Cygwin 64 bit?

Ryan Johnson ryan.johnson@cs.utoronto.ca
Tue Jun 28 21:36:00 GMT 2011

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 


More information about the Cygwin-developers mailing list