From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: Re: *Why* use cygwin.dll from non-cygwin apps?
30 Dec 1998 18:52:07 -0800
Message-ID: <199812310239.UAA28639.cygnus.cygwin32.developers@modi.xraylith.wisc.edu>
References: <199812302128 DOT QAA07899 AT envy DOT delorie DOT com>
To: DJ Delorie <dj AT delorie DOT com>
Cc: cygwin32-developers AT cygnus DOT com

DJ Delorie <dj AT delorie DOT com> writes:
> 
> What kinds of things to people expect to work when using the cygwin
> dll in a non-cygwin application?  For example, I'd expect the path
> converters to work (converting posix paths to win32 paths), but I
> wouldn't expect fork to work (fork needs to know a *lot* about the
> application).
> 
> So, I need to know what things are expected to work so I know where to
> focus on and what to test.

Let's first figure out who actually needs to use Cygwin DLLs in non-cygwin
apps. The first few are obvious -- Java JNI, Netscape plugin, Matlab mex,
S-plus (stat package) module, etc. There are the usual in-house software
that loads foreign modules at run time, but these fall in the same general
category as say a Java JNI, we've already covered that. What else? 

Now, the question is what type of capabilities does Cygwin provide such
that folks would use Cygwin over say Mingw for their loadable code? I 
would venture that it's mostly simple POSIX (perhaps with a bit of 
BSD/SVR4 etc that prevalent in Unix world) code, and that is not too 
hard to support once the bugs are worked out. What about signal 
handling? Can we expect signal handling to work? I would put sub-process 
management, especially fork etc, aside for just as DJ suggests.

Mumit