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

>   Yes, that's an offer to write such a tool, although not in the next couple
> of weeks.

After reading this thread again thus morning, I'm still a bit puzzled.

What's clear to me is that the Cygwin DLL is supposed to write its
fingerprint (key+path) to the registry, along the lines of what Larry
suggested in the first place.

What's also clear is that cygcheck is supposed to show the existing
entries, and that it ideally should allow to remove unused ones.

I'm going to implement that in the next couple of days.  I'm just left
wondering what is supposed to happen to old entries which don't point
to an actual DLL:

- Should cygcheck show them (with a remark "orphaned") or should
  cygcheck not show orphaned entries at all?

- Should cygcheck remove old entries as it goes along (implies not
  printing them at all), or should it only remove old entries if
  the user uses some "--clean" option?

What I also didn't get is the result of the other two points.

- Do we still need a way to switch off using the installation key
  in object names?  If so, using a resource as proposed by Chuck?
  If so, what about putting the functionality to change the resource
  setting into cygcheck?

- Do we still need a means to switch off the fingerprint creation?
  This one, I'm not so sure about.  If we really have an interest in the
  fingerprint, we can't have an interest to provide an easy way to avoid
  it.  It should at least require to rebuild the DLL, shouldn't it?


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]