Mail Archives: cygwin-developers/1998/12/30/19:22:25
On Wed, Dec 30, 1998 at 08:39:01PM -0600, Mumit Khan wrote:
>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.
>
>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.
I don't believe that signal handling should be a problem. I don't think
that the signal thread can't be initialized in the DLL initialization
code though. It relies on other things in the DLL having been initialized
previously.
For signals to work, then the process has to have a cygwin pid. To
have a cygwin pid means that the cygwin shared memory has to be aquired
and properly initialized.
All of these rely on a working malloc. It doesn't have to be the malloc
in cygwin necessarily, and, in fact, it probably shouldn't be the cygwin
malloc. That means that the hooks that are already in cygwin for using
a different malloc will have to be exploited. That will be tricky.
The other thing that will be required would be the `fd' support. That
shouldn't be too hard. What about tty support? That may not be difficult
either.
Hmm. I just scanned through dll_crt0_1. That seems to be about it.
So, except for fork, most of the cygwin functionality should be
possible.
-chris
- Raw text -