On Fri, 29 Oct 2004 10:34:51 -0700 (PDT), Walt Ogburn <reuben@xxxxxxxxxxxxxxxx> wrote: > Hi Mark, > > Be careful, there is also Wine's port.h in fst/include. > > I tried copying current versions of the borrowed wine files, and cleaning > up the resulting problems (mostly just headers that need to be found in > the right place since fst's directory structure is not the same as > Wine's). It still seg faults in the same way. As you pointed out, this > wouldn't explain why the memory patch made such a big difference. Very interesting. If you have a moment and wouldn't mind zipping up what you did and sending it to me off list it might be helpful in my understanding of how to do this sort of work. > > Now look in fst/libwinelib.c. This is the meat of the hack that allows > fst to use wine in the way it does. I don't think this is a "normal" > winelib application, as those shouldn't use wineserver (right?). In > libwinelib.c you will find that all kinds of things from virtual.c are > called: > > GET_SYMBOL (ntallocatevm, ntdll, "NtAllocateVirtualMemory"); > GET_SYMBOL (ntfreevm, ntdll, "NtFreeVirtualMemory"); > GET_SYMBOL (ntprotectvm, ntdll, "NtProtectVirtualMemory"); > GET_SYMBOL (acquirepeblock, ntdll, "RtlAcquirePebLock"); > GET_SYMBOL (releasepeblock, ntdll, "RtlReleasePebLock"); > > The change in behavior of these functions probably nukes the delicate > operation of kludging fst into wineserver. > > - Walter > Yep - this is the sort of thing I thought I'd find. Thanks for the help. Looking for thing like WineLoadLibrary make it more clear how fst is talking to Wine. So, two things come to mind for me: 1) Something changed about how these functions operate. Maybe the way fst calls them causes them to die, or maybe wha they return when called causes fst or jack_fst to die. 2) Because both sides of this communication path appear to use port.h, library.h, thread.h, pthread.h, etc, then some change in one of those files is causing problems since fst has an old version. Maybe the solution is just bringing the .h files up to date so the right numbers go back and forth in the calls and returns? (I.e. - maybe all of Alexandre's work is correct but the two sides are just miscommunicating?) BTW - I'm looking around I found that Wine has two files in different locations with the same name: /home/mark/CODE/WINE/wine-20041019/dlls/kernel/pthread.c /home/mark/CODE/WINE/wine-20041019/loader/pthread.c Is this a good idea? Or is it required for some reason. This caused me some confusion since I had to figure out which one to copy. Thanks for all your help. This stuff is interesting, if not way over my head. <sound of drowning ...> - Mark _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
