This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Eliminate cygwin_getshared?


> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com]
> Sent: Tuesday, September 11, 2001 10:18 AM
> To: cygwin-developers@cygwin.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]