On Sat, Mar 09, 2013 at 01:40:00AM +0000, Graham wrote: > On 08/03/13 22:40, Francois Gouget wrote: > > On Fri, 8 Mar 2013, Marcus Meissner wrote: > > [...] > >> "real NOVICE" and using LD_PRELOAD or "hotpatching" does not fit together > >> for me...? > >> > >> - wine uses it own elfloader, which might cause issues. > > Really? I thought it used the standard elf loader hence the need for > > tricks to get the native libraries to load in the right place. What it > > does have however is its own PE loader. Not sure if it's relevant here. > > > > the functions i detoured in kernel32.dll.so were LoadLibrary and > FreeLibrary, the question still remains how its even possible, this > should be a fairly straight-forward thing to answer for you developers, > i would had thought. If its too much to understand , please say :/ > > i put code which detours LoadLibrary and FreeLibrary in kernel32.dll.so > , but the code only runs at a later certain time after program execution > ... ( trigger is actually a certain library loaded, i detect it in dlsym > ) ... But in wine 1.4.1 the program crashes at a time earlier than the > triggered detour, understand?? This don't seem physically possible, any > explanation?
In loader/preloader.c is our own pre-elf-loader, which handles the specific address space layouts we use. All the library loading is very magic even to me and I have to understand it anew every time ;) Why not just patch the Wine source itself and build a specific Wine version for your problem? This makes it easier and avoids need of preloading tricks. You probably also want to patch LdrLoadDll in ntdll. Ciao, Marcus