This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Thu, 15 Oct 2009 13:26:57 -0400
- Subject: Re: Avoid collisions between parallel installations of Cygwin
- References: <4AD74D92.3030500@cwilson.fastmail.fm>
- Reply-to: cygwin-developers at cygwin dot com
On Thu, Oct 15, 2009 at 12:28:02PM -0400, Charles Wilson wrote:
>BTW:
>>> 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.
We actually have a tool like this at work which finds a symbol and modifies
it. It can be done. I'll investigate more when I get back.
cgf