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


On Oct 15 10:22, Charles Wilson wrote:
> 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...

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.

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


Corinna

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


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