Subject: Re: Initialising gnuwin DLLs
From: [email-masked] (Mikey)

14 Feb 1998 13:20:47 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [email-masked], [email-masked]

On Wed, 4 Feb 1998 16:39:12 +1100, you wrote:

>On 03-Feb-1998, Mikey <[email-masked]> wrote:
>> 
>> Code for dll's written under cygwin32, that
>> use the cygwin.dll libc services must initialize struct _reent.
>> 
>> Msvc apps that want to link in these dll's would
>> have to 
>> (A) start the link with cygwin's crt0.o (to correctly initialize libc)
>> (B) link with libcygwin.a themselves (currently not possible except when using my patched ld.exe)
>
>Why is step (B) necessary?  Is that just to satisfy some symbol references
>in crt0.o?

If you don't link the .exe with crt0.o/libcygwin.a none of the  struct _reent's will ever get
initialized, there is no main() (or WinMain() ) in a user dll to pass to cygwin_crt0.
and main() (WinMain) is hard coded into cygwin.dll's startup code.

>
>> (C) call into each user dll to initialize it's copy of
>> struct _reent with the values of the exe's copy of
>> struct _reent.
>
>Step (C) is not necessary if you initialize it in dll_entry().

I see what you mean, the comments in Makefile.DLLs 0.6
about initializing the _impure_ptr's from the main program misled me
I wondered why I was never able to get it to work :).
Do you think those could be changed to reflect
the current setup? I'm sure they have confused others.
See my other post to the list today for more about reloc dll's

>
>> I thought for a while about retrofitting B18 with
>> a crt0.o and dllcrt0.o that would handle this automatically.
>> (yes you have to go through these same hoops
>> when linking straight cygwin32 apps if you want to
>> use cygwin.dll libc services in user dll's ;^)
>
>Well, steps (A) and (B) are automatic for cygwin32 apps, and since step (C)
>is not necessary, that doesn't leave any left-over hoops.

but Mathew wasn't trying to write a cygwin32 app, he wanted to
use a cygwin32 .dll (presumably that he had written) 
from a vc++ compiled app, probably to have the access to the posix 
functions exported from cygwin.dll, and since you can't
mix calls to cygwin.dll and msvcrt.dll, he would
need to link everything with libcygwin.a.
The only way that I know to mix vc++ .obj's and .lib files with gnu .o's and .a's
is to use the patched ld that I posted to ftp.deninc.com/pub/ports/sdk

CAVEAT
	return codes ( and even params ) from some cygwin.dll 
functions are different than those returned by the same named 
functions in msvcrt.dll, Mathew you will need to check these 
over carefully.

>
>> >Could you not can you not 
>> >intialise _reent from the DLL code - e.g in the
>> >PROCESS_ATTACH routine - to initialise the Cygwin DLL from
>> >our new DLL?
>> 
>> Nope thought about that, the dll would have to know the name of the
>> .exe to get a handle to it, and have a callback function linked in to the .exe
>> to get the correct values for the exe's _reent passed back to it.
>> it wouldn't be that hard to write for special circumstances, but
>> to me it looked like a mess to use as a general solution.
>
>That's not necessary: as Sergei pointed out to me, the DLL can access
>the EXE's reent data via `__imp_reent_data' using the usual dynamic
>linking mechanism.  See the code from Makefile.DLLs in my other post.

If I understand correctly then the only changes to existing vc++ .dll code
that would really need to be made, to link with libcygwin.a are to

( 1 ) add a .c file to the dll with just 

#ifdef __CYGWIN32__
void *_impure_ptr;
#endif

in it

( 2 ) in the file that contains DllMain make sure to #include <stdio.h>
/* stdio.h already contains extern struct _reent *_impure_ptr; */

(3 ) change

BOOL WINAPI DllMain(HANDLE hDll, DWORD dwReason, LPVOID lpReserved)
{

to

#ifdef __CYGWIN32__
extern struct _reent *__imp_reent_data;
#endif
BOOL WINAPI DllMain(HANDLE hDll, DWORD dwReason, LPVOID lpReserved)
{
#ifdef __CYGWIN32__ 
_impure_ptr=__imp_reent_data;
#endif

if linking against the original B18 cygwin.dll/libcygwin.a you MUST
give a --image-base other than 0x10000000 even to relocatable
dll's, B18's cygwin.dll won't get relocated NO MATTER WHAT.

Is that about it?

=====================================================
Linux a platform built by, and for users, standing on
the firm legs of reliability, and speed.

Microsoft Windows, a platform without a leg to stand on.

([email-masked])
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".