Jeremy White <[EMAIL PROTECTED]> writes:
> Specifically, I have added a special constructor inside libwine.so
> which initializes most of Wine (by calling PROCESS_InitWine;
> see my prior patch). Since this constructor fires prior to
> the MFC constructors, the MFC constructors are able to work.
>
> The basic concept, is, IMHO sound. I would like Wine more
> or less fully functional as soon as libwine.so is done loading.
The main problem is that this will only initialize libwine.so, not all
the other dlls that MFC depends on. In order to do this correctly
you'll need to have the init code of all dlls run from constructors.
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.
> 2. GNU ld does not (AFAIK) allow me to specify
> constructor order. Ideally, I want my new constructor
> to be the *last* constructor fired. Right now, I've
> arranged this by jimmying the parameter order passed
> to the linker, but this could cause problems.
There is no real reason (except modularity) to have multiple
constructors inside libwine.so; if the order is important you can have
your constructor call the other functions explicitly.
--
Alexandre Julliard
[EMAIL PROTECTED]
