Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Wed, 24 Oct 2001 10:31:54 -0400 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: Need name and functionality suggestions for a new utility Message-ID: <20011024103154.B15898@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20011024005137 DOT A29851 AT redhat DOT com> <3BD64F1E DOT 6010102 AT ece DOT gatech DOT edu> <20011024012942 DOT B14370 AT redhat DOT com> <195555408 DOT 20011024114353 AT logos-m DOT ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <195555408.20011024114353@logos-m.ru> User-Agent: Mutt/1.3.21i On Wed, Oct 24, 2001 at 11:43:53AM +0400, egor duda wrote: >Hi! > >Wednesday, 24 October, 2001 Christopher Faylor cgf AT redhat DOT com wrote: > >CF> On Wed, Oct 24, 2001 at 01:18:22AM -0400, Charles Wilson wrote: >>>Christopher Faylor wrote: >>>>Does anyone have an idea for a name? Or even an idea for more >>>>functionality for this utility? Now that I think of it, this utility >>>>should also change the shared memory id >>> >>>Can you DO that without adding hooks to cygwin1.dll? > >CF> No. You need to add some hooks. The cygheap changes that I made a while >CF> ago make this very easy, though. > >does your tweak works in such scenario? > > "cygwin-app-1" starts "non-cygwin-app-2" and it starts "cygwin-app-3" > >will cygwin-app-3 be properly "jailed"? Nope. It doesn't work with non-cygwin apps since that breaks the cygheap chain. chroot operates similarly. >i was supposing to write a patch to add (ahem) yet another CYGWIN env >variable option so one can write, e.g. >'set CYGWIN=profile:old_install' As you can probably surmise, the first suggestion for this was to use an environment variable. That would sort of work around the above scenario but it makes it very easy for a user to circumvent, too. I don't think it's useful. >CF> I had the hooks written and cygwin compiled. Then, sending this email >CF> started a whole flood of new ideas about what needed to be changed. > >CF> I think it might just be possible to allow two different cygwins to >CF> coexist without this as long as they share the mount table. I don't >CF> know if that's a good thing or not. > >CF> It means that instead of getting "shared memory mismatch" we'll be hearing >CF> about how the new version of cygwin doesn't fix their problems -- because >CF> they still have a cygwin1.dll in their windows/system directory. > >this can be easily revealed by cygcheck. Yeah, especially now that cygcheck will actually be able to run in this scenario. Previously, it would just crash with the "shared memory mismatch" error. Not too useful. Incidentally, in 1.3.4, I have changed this error to a multi-line message which gives explicit instructions. It will be interesting to see how my instructions are misinterpreted. cgf