Avoid collisions between parallel installations of Cygwin

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Oct 16 10:55:00 GMT 2009


On Oct 16 11:13, Corinna Vinschen wrote:
> On Oct 15 20:57, Dave Korn wrote:
> > Charles Wilson wrote:
> > > Corinna wrote:
> > 
> > >>> One other thought: what about developing the cygwin DLL itself? Every
> > >>> time you build the DLL and use it without installing (say, in the test
> > >>> suite) you get yet another entry -- or an update to the existing entry
> > >>> in the registry corresponding to your customary cygwin DLL build
> > >>> directory -- in the registry?  That seems awkward.  Maybe (borrowing the
> > >>> idea above), the cygwin0.dll could be built with the special resources
> > >>> section indicating "portable" (e.g. don't touch the registry) use, and
> > >>> during 'make install' when cygwin1.dll is created the special tool could
> > >>> be used to modify that value...
> > > 
> > > Err...no.  I've thought about this some, and the "special tool" would be
> > > really really difficult. There's no API for writing resources to a
> > > separate image. You can LoadLibrary a DLL, and access an in-memory copy
> > > of its resources.  You might even be able to write to that memory
> > > location.  But you really can't modify the disk image using a public
> > > API.  So, you'd basically be left with a tool that must reverse-engineer
> > > the disk image after it is linked, locate the correct symbol, find the
> > > address...yuck. No thanks.
> > 
> >   Doesn't sound too hard.  http://www.pelib.com/
> 
> Here I'm wondering.  Isn't LoadLibraryEx with the flag
> LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE what we're looking for?  MSDN isn't
> exactly clear on this, but it appears that this is the call to modify
> the underlying image.

Well, not really, apparently.  However, can't we use the
BeginUpdateResource, UpdateResource and EndUpdateResource calls?


Corinna

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



More information about the Cygwin-developers mailing list