Derek Lesho dlesho@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.