delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |