Mail Archives: cygwin-developers/2001/10/24/10:30:59

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <>
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 <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Need name and functionality suggestions for a new utility
Message-ID: <>
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
In-Reply-To: <>
User-Agent: Mutt/1.3.21i

On Wed, Oct 24, 2001 at 11:43:53AM +0400, egor duda wrote:
>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.


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019