From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: Re: dll initialization
5 Nov 1998 17:12:56 -0800
Message-ID: <9811060020.AA08168.cygnus.cygwin32.developers@modi.xraylith.wisc.edu>
References: <01BE08E7 DOT FC460F30 AT sos>
To: Sergey Okhapkin <sos AT prospect DOT com DOT ru>
Cc: "cygwin32-developers AT cygnus DOT com" <cygwin32-developers AT cygnus DOT com>,
        "'DJ Delorie'" <dj AT delorie DOT com>

Sergey Okhapkin <sos AT prospect DOT com DOT ru> writes:
> DJ Delorie wrote:
> > Sergey Okhapkin wrote:
> > > The dlls are initialized with DECLARE_CYGWIN_DLL. When system loads the
> > > application, entry points of dlls are called first. At this time user_dat
> a
> > 
> > Does cygcheck show this?  It should show the DLLs in the order that
> > Windows initializes them.  I think calling a function in one DLL
> 
> F:\Inprise\vbroker\examples\account>cygcheck xterm.exe
> Found: E:\usr\X11R6.4\bin\xterm.exe
> E:\usr\X11R6.4\bin\xterm.exe
>   E:\usr\X11R6.4\bin\libICE.dll
>     E:\usr\H-i386-cygwin32\bin\cygwin1.dll

				 ^^^^^^^

And here's where the problem starts! I've had the time to look at the
problem in more detail, and Sergey is right about the double
initialization. Unfortunately, the crt startup is intermixed with DLL
startup and that's basically gives us one of two choices at present:
  
  - only support cygwin dlls from cygwin apps and junk my patch
  - support both, but it's going to be buggy as well ;-)

I'm out of my depth here, so someone else will have to figure out how the
innards can be "initialized" multiple times without running into this
problem. We *have* to fix this in the long run, so might as well start
now.

  1. xterm.exe
    2. libICE.dll
      3. cygwin1.dll

In step 2, libICE's dll startup gets called, which possibly looks like the
following:
  
  OS_Loader
  -> __cygwin_dll_entry AT 12
    -> cygwin_attach_dll
      -> cygwin_crt0_common	<<< not relevant in this case, right?
      -> dll_dllcrt0		<<< beginning of problem.
	 [ user_data is NULL here. Normally for cygwin apps, it's ok since
	   when the app starts, it's crt code will kick in cygwin again
	   and everything will get initialized. ]

This form of initialization just doesn't seem correct, especially the
assumption that there is an application CRT startup code that's going
to eventually initialize the Cygwin system. A better choice is to
initialize Cygwin as soon as the OS Loaders calls its Dll entry the first
time, and have the CRT startup *assume* (after checking for a few things
of course) that it's been initialized by the OS and hook into the existing
system somehow.

btw Sergey, I did test my changes before submitting them, but obviously
didn't realize this problem (ie., me test cases ran just fine, but they
were rather simple test apps that loaded a whole bunch of cygwin and
non-cygwin DLLs from cygwin and non-cygwin apps). My apologies for the 
time you've probably had to waste tracking this down.

Regards,
Mumit