This is the mail archive of the
mailing list for the Cygwin project.
Re: Named shared memory area in cygwin1.dll
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Philip Houghton <phoughton at broadcom dot com>
- Cc: cygwin at cygwin dot com
- Date: Fri, 10 Oct 2003 20:14:48 -0400 (EDT)
- Subject: Re: Named shared memory area in cygwin1.dll
- References: <24CDBA67F085904999751B3C4F9E8C0B5E2384@nt-rmna-0740.ca.broadcom.com>
- Reply-to: cygwin at cygwin dot com
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
> 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 expected version.
> 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
> 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
> Phil Houghton.
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?
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
|\ _,,,---,,_ email@example.com
ZZZzz /,`.-'`' -. ;-;;,_ firstname.lastname@example.org
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html