August 2004 - Wine-Devel - list.winehq.org

Re: [Darwine] Re: Wine Emulation: Swapping functions

by Robert Shearman

Jim White wrote: > Mike Hearn wrote: > >>> I think you are going in the wrong direction with this; the right way >>> IMO is to compile Wine for x86 and run the whole Wine+app under the >>> CPU emulator. Otherwise you'll have to write wrappers for each of the >>> 15,000 APIs. >> >> >> Certainly dealing with the syscalls alone is a lot easier than >> flipping on every Windows API. You may wish to talk to TransGaming. >> They've actually *done* what you guys are trying to do, and run x86 >> software/games on a Mac. IIRC they found it unworkable (due to >> endianness conversion) even when using virtualization software more >> advanced than QEMU, however they were focussing on games where >> performance is critical. So maybe it doesn't matter to you guys. > > > I agree that flipping the syscalls is a much more promising approach > than the WIN32 API. I'm also thinking that there is bound to be some > relevant code around aleady (perhaps even in QEMU). > > While the current phase of the Darwine effort is concerned with making > something that works, naturally performance is an important issue. In > fact one of the architectural motivations for Darwine is that it will > be able to achieve much higher performance than approaches that > virtualize the OS (in addition to the objectives of not having to run > Windows). The only way you will be able to use the Wine libraries compiled natively while running x86 executables will be to extend the current spec format so that it works similar to IDL files. You will also need to do generate wrapper code for each COM interface too. Also, there are limitations in what you can specify (and quirks such as off-by-one errors in Windows). Perhaps you would be able to special case these and be left with a manageable task, or perhaps not. There is also the fact that the wrapper code for leaf functions may take longer to execute than the code itself. To get good performance out you will probably need to compile these types of functions (such as string manipulation functions in kernel32, shlwapi, user32) as x86. Good luck with solving these issues (although I think the estimate of getting most programs that run on Wine working in 1 year that you stated in your interview is very ambitious). Rob

Aug. 25, 2004

Re: Other W->A crosscalls

by Robert Shearman

Vincent Béron wrote: >I played a bit with smatch and Wine (after reading >http://people.redhat.com/mstefani/wine/smatch/) to try to get over what >I mentionned in my last email (regarding winapi_check and cross-calls in >parenthesis). > >I attach the smatch script to generate the results I have. It's still >not perfect (the listview.c references are wrong, for example), but as >it's tied to gcc it can detect some calls which otherwise would not be >caught. For example, the calls to GetWindowLongA in header.c are in a >macro. > > If you retest with current CVS some of those GetWindowLongA calls may have disappeared. Rob

Aug. 25, 2004

Re: Wine Emulation: Swapping functions

by Pierre d'Herbemont

On 25 août 04, at 18:48, Alexandre Julliard wrote: > "Pierre d'Herbemont" <stegefin(a)free.fr> writes: > >> As a conclusion, would accept that we swap (using the regular way) the >> headers in order to load exe on a Big Endian host? (since the exe >> headers are Little Endian for each NT implementation) >> >> Pierre >> >> PS : the exe header is Little Endian even on a PowerPC NT exe, since >> the PowerPC NT implementation was actually running on Little Endian >> mode, so we won't be able to run PowerPC NT exe on Mac OS X. > > So why do you want to swap the headers, if you can't do anything with > the exe anyway? Because I plan to do something with it later. Pierre

Aug. 25, 2004

Other W->A crosscalls

by Vincent Béron

I played a bit with smatch and Wine (after reading http://people.redhat.com/mstefani/wine/smatch/) to try to get over what I mentionned in my last email (regarding winapi_check and cross-calls in parenthesis). I attach the smatch script to generate the results I have. It's still not perfect (the listview.c references are wrong, for example), but as it's tied to gcc it can detect some calls which otherwise would not be caught. For example, the calls to GetWindowLongA in header.c are in a macro. Not all of them are bugs: caution is needed when checking, although reducing the number of false positive would likely be welcome (either by modifying the script or patches). Vincent

Aug. 25, 2004

Re: Get rid of W->A calls : help me help ?

by James Hawkins

Hey Joris, I would be glad to write a howto for your and possibly others. I will get started on that soon. On 25 Aug 2004 11:43:57 -0400, Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote: > Le mer 25/08/2004 à 11:27, Joris Huizer a écrit : > [snip] > > Hi James, > > > > Yeah I would like that, thanks for suggesting :) > > I'll try and do a search on unicode functions and stuff but -- well, you > > have seen more of wine specific details ... > > > > Also, I think it'd be smart to put something like that online (like.. > > linking from the janitorial page to that one?) > > By the way... Is there some kind of overview of what parts is already > > being worked on; we don't want to do double work right ;) > > Already done work is grayed-out or simply removed from the janitorial > page. > > Also take note (François? Any perl hacker?) that the method used to find > the cross-calls (winapi_check) is not 100% proof. There are some valid C > statements which contain a cross-call which are not found. Look at > dlls/lzexpand/lzexpand_main.c GetExpandedNameW: > > INT WINAPI GetExpandedNameW( LPWSTR in, LPWSTR out ) > { > INT ret; > DWORD len = WideCharToMultiByte( CP_ACP, 0, in, -1, NULL, 0, NULL, > NULL ); > char *xin = HeapAlloc( GetProcessHeap(), 0, len ); > char *xout = HeapAlloc( GetProcessHeap(), 0, len+3 ); > WideCharToMultiByte( CP_ACP, 0, in, -1, xin, len, NULL, NULL ); > if ((ret = GetExpandedNameA( xin, xout )) > 0) > MultiByteToWideChar( CP_ACP, 0, xout, -1, out, strlenW(in)+4 ); > HeapFree( GetProcessHeap(), 0, xin ); > HeapFree( GetProcessHeap(), 0, xout ); > return ret; > } > > The A call is between parenthesis and winapi_check can't find it. > winapi_check would need to be modified to find those, as I'm sure that's > not the only one in the whole tree. > > Vincent > > -- James Hawkins

Aug. 25, 2004

Re: Don't compile winetest as part of the main build

by Alexandre Julliard

Mike Hearn <m.hearn(a)signal.qinetiq.com> writes: > Was this dropped? On my laptop (a 600mhz Pentium with 128mb of ram, so > not too pokey) attempting to build the winetest binary actually kills > the build dead. It ends up attempting to feed ~20mb of data to gas > which doesn't make it very happy. I guess I misphrased it - it's not > for slower machines, it's for machines with less memory. > > There's not much reason to run the entire winetest binary on Wine > itself, so why do we always build it ? Because code that doesn't get built rots very quickly. You can disable it in your tree, but the default should be to build it. -- Alexandre Julliard julliard(a)winehq.org

Aug. 25, 2004

Re: Don't fall back to OSS when Drivers=""

by Alexandre Julliard

Mike Hearn <m.hearn(a)signal.qinetiq.com> writes: > Ditto, was there something wrong with this one? Not sure I see the point, could you please elaborate on what you are trying to achieve here? -- Alexandre Julliard julliard(a)winehq.org

Aug. 25, 2004

Re: Wine Emulation: Swapping functions

by Alexandre Julliard

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > As a conclusion, would accept that we swap (using the regular way) the > headers in order to load exe on a Big Endian host? (since the exe > headers are Little Endian for each NT implementation) > > Pierre > > PS : the exe header is Little Endian even on a PowerPC NT exe, since > the PowerPC NT implementation was actually running on Little Endian > mode, so we won't be able to run PowerPC NT exe on Mac OS X. So why do you want to swap the headers, if you can't do anything with the exe anyway? -- Alexandre Julliard julliard(a)winehq.org

Aug. 25, 2004

Re: Get rid of W->A calls : help me help ?

by Vincent Béron

Le mer 25/08/2004 à 11:27, Joris Huizer a écrit : [snip] > Hi James, > > Yeah I would like that, thanks for suggesting :) > I'll try and do a search on unicode functions and stuff but -- well, you > have seen more of wine specific details ... > > Also, I think it'd be smart to put something like that online (like.. > linking from the janitorial page to that one?) > By the way... Is there some kind of overview of what parts is already > being worked on; we don't want to do double work right ;) Already done work is grayed-out or simply removed from the janitorial page. Also take note (François? Any perl hacker?) that the method used to find the cross-calls (winapi_check) is not 100% proof. There are some valid C statements which contain a cross-call which are not found. Look at dlls/lzexpand/lzexpand_main.c GetExpandedNameW: INT WINAPI GetExpandedNameW( LPWSTR in, LPWSTR out ) { INT ret; DWORD len = WideCharToMultiByte( CP_ACP, 0, in, -1, NULL, 0, NULL, NULL ); char *xin = HeapAlloc( GetProcessHeap(), 0, len ); char *xout = HeapAlloc( GetProcessHeap(), 0, len+3 ); WideCharToMultiByte( CP_ACP, 0, in, -1, xin, len, NULL, NULL ); if ((ret = GetExpandedNameA( xin, xout )) > 0) MultiByteToWideChar( CP_ACP, 0, xout, -1, out, strlenW(in)+4 ); HeapFree( GetProcessHeap(), 0, xin ); HeapFree( GetProcessHeap(), 0, xout ); return ret; } The A call is between parenthesis and winapi_check can't find it. winapi_check would need to be modified to find those, as I'm sure that's not the only one in the whole tree. Vincent

Aug. 25, 2004

Re: Get rid of W->A calls : help me help ?

by Joris Huizer

James Hawkins wrote: > Hey Joris, > > I started developing wine in exactly the same way you are > starting: working on the janitorial projects. My current project is > converting the crypt cross calls, and it is almost finished, but im > waiting for my CryptSetProviderExA patch to be committed before I send > the rest of my cross call cleanup patches. > > If you would like I can write a little howto concerning W->A cross > call cleanup and the like (unit tests). There are a bunch of little > nitpicky things you just have to know before you can really start > cracking in on it...a while back i tried to submit a cleanup patch > like 6 times and it was reject everytime because I didnt know the > details yet. So if you would like this information, let me know. > We're glad you're here to help with wine. > Hi James, Yeah I would like that, thanks for suggesting :) I'll try and do a search on unicode functions and stuff but -- well, you have seen more of wine specific details ... Also, I think it'd be smart to put something like that online (like.. linking from the janitorial page to that one?) By the way... Is there some kind of overview of what parts is already being worked on; we don't want to do double work right ;) - Joris

Aug. 25, 2004