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, http://cygwin.com/ml/cygwin/2003-02/msg01682.html) 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 manner). Another non cygwin email thread also makes a similar suggestion, but without really justifying why its necessary http://archives.postgresql.org/pgadmin-hackers/2002-05/msg00016.php 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 thanks Phil Houghton. PS has anyone tried binary editing the cgywin1.dll to change the shared memory name as a temporary work around? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
