www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/11/05/04:57:57

From: sos AT prospect DOT com DOT ru (Sergey Okhapkin)
Subject: RE: dll initialization
5 Nov 1998 04:57:57 -0800 :
Message-ID: <01BE088E.7128A560.cygnus.cygwin32.developers@sos>
To: "'Mumit Khan'" <khan AT xraylith DOT wisc DOT edu>
Cc: "'cygwin32-developers AT cygnus DOT com'" <cygwin32-developers AT cygnus DOT com>

Mumit Khan wrote:
> I'm confused as to the circumstances when this is happening. Are the
> applications non-cygwin?
>

Both the applicaton and dlls are cygwin-compiled.

> These changes only affect (in theory of course) user DLLs that are
> *not* cygwin DLLs, but something else (mingw crtdll/msvc or VC++
> msvc).
>
> Cygwin user DLLs should be specifying __cygwin_entry_dll AT 12 as the
> entry point which will initialize user_data properly and call user
> _DllMain AT 12 if any.

The dlls are initialized with DECLARE_CYGWIN_DLL. When system loads the 
application, entry points of dlls are called first. At this time user_data 
is NULL and dll_dllcrt0 performs partial initialization of cygwin1.dll. 
After that, system passes a control to application's startup code and 
cygwin1.dll performs self-initialiozing once more!

If the application does fork(), child's and parent's memories are 
non-coherent.

--
Sergey Okhapkin, http://www.lexa.ru/sos
Piscataway, NJ


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019