"Jan Beulich" <[EMAIL PROTECTED]> wrote around 26 Nov 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> 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/