Subject: Re: accessing cygwin functions from non-cygwin app
From: Soren A <[email-masked]>
To: [email-masked]
Date: Wed, 27 Nov 2002 14:30:16 +0000 (UTC)

"Jan Beulich" <[email-masked]> wrote around 26 Nov 2002
news:[email-masked]: 

> All I intended was translating a coupld of filenames from cygwin to
> Win32 notation in an otherwise Win32-only app. I quickly realized that
> cygwin1.dll does not do all the necessary initialization on its own,
> i.e. from DllMain. Instead it appears that I am expected to explicitly
> call one or more functions inside the DLL to perform
> this initialization. However, whatever I tried (dll_crt0, dll_dllcrt0)
> didn't work (i.e. crashed due to insufficient prior initialization),
> but cygwin_attach_dll is neither exported from the DLL nor would it,
> from its use inside the sources, appear to be meant for the case I'm
> dealing with (where a main executaböle directly attaches to
> cygwin1.dll). And even if this is the function to use, then I have a
> problem using it as the application cannot be expected to have access
> to the perprocess class (nor is the app a C++ app, and neither is it
> being built with gcc) or other cygwin sources, and it also cannot link
> against libcygwin.a. 

I don't understand most of this, but I thought I'd just mention that I
found using the Cygwin API to get converted pathnames pretty simple and
straightforward to do, when I wrote the Cygwin Perl module I posted
about a while back. It "just worked". It links against libcygwin.a. 

I am guessing that foregoing meant that the o.p. is trying to call
cygwin functions using that MS equivalent of the dlopen() if I am not
still totally in the dark. (whatitcalled). 

   Bet that didn't help,
        Soren A
-- 
Yes, it's really Sören, not Soren.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/