This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
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