On 09/03/13 06:03, Marcus Meissner wrote: > 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 Gracias.
That helps, cheers all. And Good Luck with the continuation of this awesome software