[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: RFC - Winelib constructor init problem
From:       Gavriel State <gav () transgaming ! com>
Date:       2000-08-31 6:07:52
[Download RAW message or body]

Jeremy White wrote:
> 
> Alexandre Julliard wrote:
> > This is certainly doable with .so dlls, but it probably won't work
> > right with static linking (though I'm not sure if we care about that).
> > And of course you won't have access to the command-line when
> > initializing the dlls, so options like -display, -dll, -desktop
> > won't be supported.
> 
>     Good point.  I favor this option over the others, because I believe
> it to be the more correct one.  (Empirically MFC works with
> only GDI, Kernel, and User, but your point remains valid - my solution
> is not complete).
> 
>     If we were to change to have each DLL initialize itself
> from its constructor, is argc/argv processing the only flaw
> with this approach?  (I ask because a brief review of the glibc
> code indicates that argc/argv are processed prior to
> traversing the ctors list, so they should be available to us).

We're looking into a similar issue now - some libGL implementations 
call pthreads functions in their constructors, leading to headaches
because the pthreads wrapper functions rely on threading having 
been initialized by that point.  

Dredgeing my memory for what we had been working on at Corel reminded
me that we had overcome the argc/argv issue by relying on glibc __environ
global.  Basically, you can extract argc/argv from that and pass it
on to PROCESS_InitWinelib from any constructor you like, since glibc 
should already have it initialized.

-Gav

-- 
Gavriel State
CEO
TransGaming Technologies Inc.
gav@transgaming.com

[prev in list] [next in list] [prev in thread] [next in thread]