This is the mail archive of the
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-developers at cygwin dot com
- Date: Thu, 15 Oct 2009 12:28:02 -0400
- Subject: Re: Avoid collisions between parallel installations of Cygwin
> On Oct 15 10:22, Charles Wilson wrote:
>> Hmm. I thought that one of the benefits -- perhaps serendipitous -- of
>> cygwin-1.7 was that it no longer required any registry access at all.
>> (Setup writes into the registry, but cygwin itself doesn't anymore. I
>> Requiring a recompile of the kernel in order to switch to "portable"
>> mode is also awkward.
>> Now /this/ seems to be a case for settings stored in the resources
>> section of the DLL, plus a special manipulation tool...
>> Of course, if current 1.7.0-xx still does write to the registry, even
>> though it no longer does vis a vis the mount table, then none of the
>> above applies...
> It does. Look out for [HKLM,HKCU]/SOFTWARE/Cygwin/Program Options
> Does it hurt? No. There's only one such entry per installation path.
> Your thumb drive, typically using the same drive letter every time
> it's used on a machine, will result in one entry.
OK. Then as the new proposed behavior doesn't do anything really "new"
-- what's two registry writes vs. one? -- then I withdraw my suggestion
(about turning off the "store installation location fingerprint in the
> Even after some installation orgies, the end result is, you have a small
> number N of entries. Cygwcheck can view the entries and check if the DLL
> in this path still exists. If not, ignore the entry, if yes, print the
> DLL path. And the Cygwni DLL itself does not need the entry for running.
> It's just a fingerprint which helps to track down all Cygwin DLLs on a
>> 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.
The only workable approach -- and here I'm back to talking about
"disable the magic installation path hashing for shared object names" --
for post-compile behavior modification that doesn't involve the registry
or resources, is cgf's original .cygwinrc file proposal, located next to
the cgywin1.dll and found via GetModulePath(NULL, ...). I also think
using the CYGWIN variable here is the wrong thing to do, because it's
typically global -- set in the system or user environment -- rather than
per-installation. And trying to use it in a per-installation manner
limits you to cygwin.bat (not even run2, which lets you set SOME
environment variables before launching the target, will allow you to set
CYGWIN, because run2 itself is a cygwin prog so it's too late).
So if you WANT to be able to turn of the "magic installation path
hashing for shared object names" behavior at all, even if enabled by
default, it really must be rooted in some object within that
installations' disk footprint. E.g. cygwin1.dll's resources (boo! hiss!
no!) or a separate *file* on disk read BY cygwin1.dll very early, not an
In regards to cgf's last message, cgf wrote:
> I saw Chuck's concerns about being able to turn off this [ed: storing
> the installation location fingerprint in the registry] behavior, and
> it would be nice if they were addressed.
I'm thinking a compile time flag
(-DNO_INSTALLATION_FINGERPRINT_IN_REGISTRY or somesuch) is the best we
could do, if we even do anything at all along the lines of "allow to
turn off this (installation fingerprint in registry) behavior".
Frankly I no longer think this is necessary, given that we already do at
least one write to the registry for 'Program Options'.