Re: Duplicate CygWin

["Cliff Hones" <cliff at aonix dot co dot uk>]

> There are no such things as sideways-compatible versions of Cygwin.
> It would be possible to build an *isolated* version of Cygwin. In this case,
> each Cygwin would view the other as just another native Win32 application.

I suspect there's a growing trend in packaging applications up with
a cut-down Cygwin to enable the naive user to get up and running
quickly.  [I've no justification for this statement, other than the
growing number of related problems being reported here, and the
fact that Cygwin's popularity is growing.]

In many cases these self-contained packages require very little in the
way of support from Cygwin - typically just the cygwin1.dll and maybe
a couple of mount points.  If it were not for the shared memory problem
these packages would probably happily coexist with each other, and with
a full Cygwin installation.

The stumbling block is the built-in shared memory name in Cygwin1.dll.
I'm sure I'm not alone in wondering how this problem could be addressed.
I would have thought that a very useful feature would be a mechanism to
enable the user and/or packager to easily control the shared memory name,
without having to resort to rebuilding the dll from source.  [Even though the
latter is not that difficult, it does require quite a learning curve.]

So, how could this be done?  I'm not clear enough on the internals to know
if this name has to be built into the dll at compile or link time, or
whether it could be more dynamic - so could for example be determined
from an environment variable or from a text file.  If the latter, could
the dll look for a config file in its own directory which could
specify the shared memory name, and possibly also other info such as the
registry root for mount info?  [Or indeed could the shared memory name be
incorporated in the registry key names?]  Even if the shared memory name
has to be hard-coded in cygwin1.dll, it should still be possible to
generate a utility which could find and patch the name.

Another possibility is that the memory name could be locked to the
dll name, so that renaming it xygwin1.dll really would decouple it from
the 'main' Cygwin installation.

I'm thinking that, with the growing number of Cygwin users, both
voluntary (but without in-depth knowledge), and involuntary (using
pre-packaged distributions) we should be working towards
a solution which will minimise the likely problems.

Of course, all info about how to do this should be available on the
Cygwin web pages, both to aid packagers (we really do want to help
them not to create problems), and to allow more knowledgable users
to combine and update their installations smoothly.

-- Cliff


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/