This is the mail archive of the
mailing list for the Cygwin project.
Re: Named shared memory area in cygwin1.dll
On Fri, Oct 10, 2003 at 08:14:48PM -0400, Igor Pechtchanski wrote:
>On Fri, 10 Oct 2003, Philip Houghton wrote:
>>Why does every version of the cygwin1.dll use the same name for its
>>shared memory area? Doesn't this imply that the shared memory area is
>>compatible between different versions of the dll, when in reality it
>>isn't? I believe each version of cygwin1.dll will map its own unique
>>definition onto this memory area, so if two processes run using
>>different versions of the dll, then they will in all likelihood trash
>>the shared memory area for the other, presumably in rather horrible and
>>unpredictable ways. Given that there is no compatibility between
>>versions for the shared memory area, why not instead make the shared
>>memory name unique for every version of the dll, for example by
>>including the version number in the name? If the memory areas were
>>uniquely named for different versions of the dll, then processes using
>>different dll versions could run independently using separate global
>>memory. Okay they wouldn't be able to communicate with each other, but
>>this would be a much more benign failure mode than random trampling of
>>the global memory space. Furthermore, many programs don't need to
>>communicate with other processes, so this loss of functionality for
>>them is quite acceptable. For applications requiring proper global
>>communication, the only solution is to ensure everyone uses the same
>>version of the cygwin1.dll. For those applications that don't care,
>>naming the shared memory space uniquely will allow them to function
>>correctly when different dll versions are used.
>>In an ideal world all applications would use the same version of the
>>cygwin1.dll. However, the success of cygwin makes this almost
>>impossible in practice, as many OEM tools ship with a particular
>>version of the cygwin1.dll. I use several GNU based OEM compiler
>>chains, which only work with a limited range of cygwin1.dll versions.
>>Of course none of them use the same version! As I also typically build
>>from a bash shell, then over time the installed cygwin1.dll version
>>advances each time the installation is upgraded. The compiler tool
>>chains don't necessarily advance at the same speed, typically they
>>remain stationary for long periods of time. Eventually a critical
>>point is reached where the installed version of cygwin1.dll is so
>>different from the one the compiler tool was developed against that it
>>no longer works properly. At this point everything potentially breaks.
>>I can't let the compiler run with its own version of the cygwin1.dll
>>and the bash shell with its own newer version, because of the shared
>>memory region conflict. Neither can I force the compiler to use the
>>newer dll nor the bash shell to use the older one. The only choices I
>>appear to have are i) go back to an older installation of cygwin (not
>>very easy because the public mirrors and the setup program only allow
>>for the latest cygwin to be installed) ii) try and convince the OEM
>>tool vendor to support an older version of their tool with the latest
>>version of cygwin1.dll. The second option fails completely when
>>multiple OEM tools are involved.
>>Apologies if this has been discussed at length before. I searched the
>>cygwin email archives and found some material that touched fleetingly
>>on this subject (see suggestion by Sam Robb
>>http://cygwin.com/ml/cygwin/2003-02/msg01679.html), but the argument
>>was tangential to the main thread of the email (GPL violation) and
>>wasn't made in the same way as above. The reply was along the lines of
>>"I don't want to..." (see Chris Faylor,
>>To differentiate my arguments from that discussion.
>>1) Contrary to Sam's suggestion, I'm only proposing that the name space
>>be uniquely named, not the cywin1.dll itself. There is no guarantee
>>that the shared memory region is interoperable between different
>>versions of cygwin, so why not isolate them by using unique names.
>>Keeping the cygwin1.dll name constant makes sense because often a
>>program will work with a large range of cygwin1.dll versions. The
>>search path can be used to make sure any given application finds its
>>2) In fairness to Chris, his objection to Sam's suggestion was more
>>than 'I don't want to...' it was also 'there is no need to....' because
>>"... I haven't seen any rationale for keeping two cygwins on the
>>system". However, I think there are very good reasons for keeping
>>multiple versions of cygwin1.dll on the system, as I argued above.
>>Cygwin's own success, means that many OEM tools rely on cygwin1.dll and
>>ship their tools with it. Inevitably different vendors will ship with
>>different, potentially incompatible versions of cygwin1.dll. Even more
>>inevitable, is they won't re-release their tools every time a new
>>version of cygwin is released, but cygwin users will likely upgrade
>>frequently. So I don't see how this situation can be avoided, which
>>means some kind of isolation between different versions of cygwin1.dll
>>is required and multiple versions of cygwin must be able to coexist
>>(albeit in a limited manner).
>>Another non cygwin email thread also makes a similar suggestion, but
>>without really justifying why its necessary
>>Granted it will mean work, but this is a great tool and this problem
>>only exists because it has been so successful.
>>appreciate anyone's thoughts
>The tools using cygwin1.dll should be released under GPL or another
>open-source license, so they must also distribute the sources of the
>DLL. Why not recompile the cygwin1.dll versions that they use and
>change the shared memory region name?
Or just delete the old versions and use the newer ones.
>BTW, if you use "--enable-debugging", the shared region id string will
>contain the date of the build...
>>PS has anyone tried binary editing the cgywin1.dll to change the shared
>>memory name as a temporary work around?
>Have you? Just search the DLL for "cygwin1S3" and replace by your
Lets not suggest to thousands of people that they just grope around
inside the cygwin DLL and edit things.
For the record, cygwin is supposed to detect different versions using
the same shared memory region and complain if it detects that situation.
If it doesn't that's a bug. I'll fix the bug if I see it. I haven't
seen it, however.
If something like a compiler tool fails to operate correctly if used
with a newer version of cygwin, that is also a bug. That is not
supposed to be the case and I would be very suprised if it actually
occurs. I know that the GNUpro tools, for instance will work fine with
newer net-release versions of cygwin, although, I'm not sure why you'd
want to do that since it would invalidate your support contract.
The bottom line is that it is not the responsibility of the cygwin net
release to accommodate commercial releases. If you have a problem with
a commercial release that uses the cygwin DLL, contact your vendor.
Lets put this discussion to rest. We've been over this ground many times
before and there is nothing new to discuss here. We are not changing
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html