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