www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/09/10/21:46:27

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: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Eliminate cygwin_getshared?
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Tue, 11 Sep 2001 11:33:51 +1000
Message-ID: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F155@itdomain002.itdomain.net.au>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Eliminate cygwin_getshared?
Thread-Index: AcE6WK+ryvB/fu5bTCWsXyN8Xhiq6gACHUHg
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id VAA11992

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> Sent: Tuesday, September 11, 2001 10:18 AM
> To: cygwin-developers AT cygwin DOT com
> Subject: Eliminate cygwin_getshared?
> 
> 
> I was just perusing shared.cc and came across this ill-begotten
> function.  It's cygwin's answer to eliminating
> security-through-obscurity.
> 
> Is anyone aware of a use for this function?  I can't think of any
> reason to export a pointer to cygwin's shared memory area.

I can. That _might_ allow us to get cygipc to piggy back on cygwin
without becoming part of the kernel. It wouldn't be any more available
to your proprietary customers than it is now, but I don't see that being
an issue (it's a LGPL not GPL IIRC?).
 
> Even though it will potentially break backward compatibility, I'd
> like to eliminate it from the next release of cygwin.
> 
> Any comments?

Yes. I've been thinking about the daemon, and pthreads and the like, and
I'm wondering if we can split some of the non-core parts of cygwin off.
i.e. cygwin_clipboard.dll for fhandler_clipboard.

The idea being that if we are going to have a daemon and a main dll, if
we can modularise it a little more, we can potentially end up with much
somewhat smaller process sizes for applications that use only a bit of
the functionality. For example I don't use /dev/dsp at all, why not wait
until the device is opened, and then grab the code to manipulate it (if
it's not in the daemon that is).

However it may be best to start with a clean slate to do this, so it
could be orthogonal to your question :}

Rob

- Raw text -


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