Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
To:	cygwin AT cygwin DOT com
X-Injected-Via-Gmane:	http://gmane.org/
Path:	not-for-mail
From:	Soren A <soren_andersen AT fastmail DOT fm>
Subject:	Re: accessing cygwin functions from non-cygwin app
Date:	Wed, 27 Nov 2002 14:30:16 +0000 (UTC)
Organization:	Occasionally Sporadically
Lines:	33
Message-ID:	<Xns92D3610CD537Asoren1Gmane@80.91.224.249>
References:	<sde35758 DOT 064 AT cpl-emea-mail1 DOT cpl DOT novell DOT com>
NNTP-Posting-Host:	ny-kenton2a-951.buf.adelphia.net
X-Trace:	main.gmane.org 1038407416 9181 24.51.95.183 (27 Nov 2002 14:30:16 GMT)
X-Complaints-To:	usenet AT main DOT gmane DOT org
NNTP-Posting-Date:	Wed, 27 Nov 2002 14:30:16 +0000 (UTC)
User-Agent:	Xnews/L5
X-Archive:	encrypt

"Jan Beulich" <JBeulich AT novell DOT com> wrote around 26 Nov 2002
news:sde35758 DOT 064 AT cpl-emea-mail1 DOT cpl DOT novell DOT com: 

> 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/

- Raw text -