[Wine]old Wine from CVS

Mark Knecht markknecht at gmail.com
Fri Oct 29 13:27:29 CDT 2004


On Fri, 29 Oct 2004 10:34:51 -0700 (PDT), Walt Ogburn
<reuben at ugcs.caltech.edu> 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



More information about the wine-users mailing list