This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Avoid collisions between parallel installations of Cygwin


Corinna wrote:
> So, wouldn't it be nice if every Cygwin DLL on the system would add some
> system-wide available information where it can be easily found?
> 
> Let's simply assume as you did, that the Windows registry is the right
> place to do this.  Assuming further the DLL creates a 64 bit key value
> (heard that before?) from its installation path which is used for the
> object names.  It could now simply create a new registry entry
> 
>   [HKLM|HKCU](*)\Software\Cygwin\location\$installation_key,
>   type REG_STRING, content = $installation_root.
> 
> (*) depending on user rights, obviosuly.
> 
> Cygcheck could fetch this information and print it.  Even without
> cygcheck it's easy to examine the registry and check if there are
> multiple Cygwin DLLs installed.  All past and present installation
> paths can be fetched from the registry.

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
think).

This makes it easier to have a "portable" cygwin -- say, on a thumb
drive -- that leaves no trace on the system.  If a feature like you
describe is added to cygwin, AND assuming I'm correct about current
cygwin behavior, I think its a good idea to be able to disable this
behavior.  And a CYGWIN variable is almost certainly too "late" to do
so, and insufficient besides.  Since setting a global environment
variable requires leaving traces on the system, you're left with
cygwin.bat -- but that means you can't directly launch e.g. mintty by
double-clicking it from explorer on your thumb drive.

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...

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...

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]