PE Conversion

[Alexandre Julliard]

Derek Lesho <dlesho at codeweavers.com> writes:

> My impression is that there the __wine_init_unix_lib interface is a
> just an in-between step from the old host-format dlls to the 
> __wine_unix_call-using unix-split dlls.  Routing the unix library
> entry points through syscalls (well, just __wine_unix_call) will make
> it so that at some point all calls to unix code from PE will be
> through the syscall enter/exit interface, and we can just add the
> thunking code there.  Looking at the current code, it seems that ntdll
> will mandate unix libraries carry a second function pointer table 
> (__wine_unix_call_wow64_funcs) to expose to wow64 apps, and these
> should be what handle 32/64 bit differences in memory layout.  (So all
> the conversion here will have to be done explicitly, unlike the
> approach taken in Crossover that Ken described on here a few years
> ago).
>
> I'm less sure on this, but I think the reason there are two different
> steps for converting DLLs is that since __wine_init_unix_lib interface 
> merely exposes function pointers to the unix library entry points
> as-is to the PE, you don't have to worry about calling into PE code
> from the unix library yet, which may ease the transition.

Yes, exactly. __wine_init_unix_lib is an intermediate step that will go
away eventually. New code should ideally be using __wine_unix_call from
the start, if possible.

-- 
Alexandre Julliard
julliard at winehq.org