This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: problem with fork/exec in Cygwin DLL called from non-Cygwin E XE
- To: "'cygwin-developers at sourceware dot cygnus dot com'" <cygwin-developers at sourceware dot cygnus dot com>
- Subject: Re: problem with fork/exec in Cygwin DLL called from non-Cygwin E XE
- From: Chris Faylor <cgf at cygnus dot com>
- Date: Thu, 2 Mar 2000 13:32:41 -0500
- References: <779F20BCCE5AD31186A50008C75D99791716F3@SILLDN_MAIL1>
- Reply-To: cygwin-developers at sourceware dot cygnus dot com
On Thu, Mar 02, 2000 at 06:26:00PM -0000, Fifer, Eric wrote:
>"Chris Faylor" writes:
>>Since fork/exec are not aware of LoadLibrary calls, I am surprised that you
>>would see any success anywhere. dlopen() may work better.
>
>I was using LoadLibrary in an attempt to emulate whatever
>Excel is doing. The real goal is to be able to use
>fork/exec/etc from Cygwin-capable DLLs called from Excel.
I don't see how you can ever do something like that. fork, at least, relies
on being called when a process is starting up.
>>It doesn't know about
>>your use of LoadLibrary so it doesn't duplicate it. Then, the code tries
>to
>>jump into func() which doesn't exist.
>
>Hmm ...
>
>Do you think adding a cygwin_record_dll() hook would be
>too ugly?
No, not at all. I don't want to add to the current ugly dynamic DLL
handling code though. It seems incredibly complicated (to me) for
something that AFAICT should be relatively simple.
Both Mumit and I have banged on the code but neither of us have been
brave enough to streamline or simplify it.
cgf