February 2008 - Wine-devel - list.winehq.org

[feature requist] Glide API support
by Vincent Weber 05 Mar '08

05 Mar '08

Dear Wine devs, There are some games out there that were built with the Glide API. The Glide API is the graphics API of the 3dfx Voodoo cards and is basically a stripped down version of OpenGL. Could please consider adding support for the Glide API because I, and other have games that requires this API to be able to run under Wine. Now I know that there are Glide wrappers but they don't seem to work for a lot of people, including me, and Glide has been a very popular game API in the mid- to late 90's. Thanks in advance, Vincent Weber, weber dot vincent at gmail dot com

7 6

Regession tests
by Alistair Leslie-Hughes 04 Mar '08

04 Mar '08

Hi, Some of the regessions test are failing with errors in output file like msxml3:domdoc start dlls/msxml3/tests/domdoc.c 1.80 msxml3:domdoc done (-1073741819) Is this due to a Seg Fault? Best Regards Alistair Leslie-Hughes

2 3

Next big app(s) to try?
by Dan Kegel 03 Mar '08

03 Mar '08

Now that Adobe Photoshop CS2 is running kind of well (there are bugs that need fixing, but I'm trying to look ahead a bit), what big app(s) are worth focusing on next? Using http://wiki.winehq.org/LinuxApplicatonRequestSurvey, skipping Photoshop (which we should continue to fix up) and the ones that are either too hard, have native versions, or are probably something Codeweavers might already be doing, and adding in good old Framemaker (so close to working we might want to go for it just for the goodwill from all those tech writers), I think that leaves about seven big ticket apps, in rough order of popularity: http://wiki.winehq.org/AdobeDreamweaver iTunes http://wiki.winehq.org/AdobeIllustrator http://wiki.winehq.org/AdobeFlash http://wiki.winehq.org/AdobePremiere http://wiki.winehq.org/AdobeAcrobatPro http://wiki.winehq.org/AdobeFramemaker I've created wiki pages with trial download URLs for all but iTunes, and done a bunch of triage on them. Most of these could all use more triage and bugs filed. At some point the dust might settle, and it might become clearer which one(s) deserve to be focused on. I think Maarten is going to try iTunes, which would be great. - Dan

9 10

Any graphics card y'all like to see tests run on?
by Austin English 01 Mar '08

01 Mar '08

Howdy, I'm about to get a new graphics card, because my current crappy Nvidia FX 5200 doesn't support widescreen, and I just got a shiny nice new 22". So, I'm going to upgrade my graphics card. I don't have a preference, since I don't game at all, just need something that will run 1920x1040 and $200<=. So any of you d3d/ddraw guys, is there some graphics card y'all need tests run on, and don't see around often, because now's your chance... -Austin

4 5

Re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings
by Robert Shearman 01 Mar '08

01 Mar '08

Adam Strzelecki wrote: > During playing with installing Visual Studio 2005 with WINE I found > out that WINE's MSI is spending lot of time inside lstrcmpW. With Mac > OS X process sampler I checked that actually 60-70% of CompareStringW > is wine_compare_string, rest is rest of function body, which is in > case 2 strlenW calls (inline). > I believe this isn't necessary, moreover most of compares in MSI are > non-matching on first few characters, however with current > implementation we go trough all strings with strlenW regardless of > anything, which is waste in CPU cucles. > I modified both CompareStringW and wine_compare_string so they work > with -1 strings without strlenW checking before. > This saves in my testing about 20-30% of CPU cycles. You introduce a lot of complexity into the low-level helper routines. We don't want to put Win32 quirks, like -1 meaning "until the null terminator" being put into the low-level functions unless we have to. In this case, if this is the sole cause of the slowdown then you would be better off caching the length at the MSI level since the strings are bound to be accessed more than once. However, I think you'll find that this is an algorithm problem in MSI rather than a performance issue in the functions you mention. By that, I mean it is likely that one MSI query is being performed again and again and that the results should be cached. > Note also that WINE's strlenW and lstrcmpW functions are far from > perfect. Normal msvcrt or glibc string functions are far more > optimized at machine code level. This makes strong impact on WINE > parts strongly relaying on string manipulation which is in this case MSI. How do you know that the compiler isn't generating the same assembly for the functions as that used by msvcrt / glibc? Theories like these need numbers to back them up. -- Rob Shearman

3 2

Re: kernel32 & winex11: WaitForMultipleObjectsEx should ignore NULL handles
by Robert Shearman 01 Mar '08

01 Mar '08

Adam Strzelecki wrote: > Hi, > > In MSI dialog.c: msi_dialog_check_messages function it often happens > that is sends: > MsgWaitForMultipleObjects( 1, &handle, 0, INFINITE, QS_ALLINPUT ); > Where handle = NULL. I'm not sure if it is correct behavior. But > tracing it down I found out that kernel32 and winex11 sync functions > are not checking at all if the passes handles are not NULLs. > > So I'm not sure whether this patch is right or not, but I believe we > shouldn't bother wineserver with NULL handles!? > Yet maybe I don't understand clearly the way interserver communication > works, and sending "WaitFor" with NULL handle makes sense. Does it? No, but this is the wrong fix. You're assuming that because MSI code does action A and that causes bad effect when it does action B that the correct action is to fix B so that it doesn't have a bad effect. However, the bug could also be that action A shouldn't be done. In this case, MSI should not be calling MsgWaitForMultipleObjects with an invalid handle and in fact that barring memory corruption, this can't happen: > while (1) > { > msi_process_pending_messages( NULL ); > > if( !handle ) > break; > > /* > * block here until somebody creates a new dialog or > * the handle we're waiting on becomes ready > */ > r = MsgWaitForMultipleObjects( 1, &handle, 0, INFINITE, > QS_ALLINPUT ); > if( r == WAIT_OBJECT_0 ) > break; > } -- Rob Shearman

2 1

Re: wine.inf: Create fake dll entry for dosx.exe
by Justin Chevrier 29 Feb '08

29 Feb '08

> Changelog: > > Create a fake dll entry for dosx.exe Anything wrong with this one liner? Justin Chevrier

2 1

Re: Conformance tests for LoadStringW and LoadStringA
by Christopher 29 Feb '08

29 Feb '08

wine-devel-request(a)winehq.org wrote: > Message: 3 > Date: Fri, 29 Feb 2008 12:50:53 +0100 > From: Alexandre Julliard <julliard(a)winehq.org> > Subject: Re: Conformance tests for LoadStringW and LoadStringA > To: Christopher <raccoonone(a)procyongames.com> > Cc: wine-devel(a)winehq.org > Message-ID: <87y794yo9u.fsf(a)wine.dyndns.org> > Content-Type: text/plain; charset=us-ascii > > Christopher <raccoonone(a)procyongames.com> writes: > > >> > + ok(!memcmp(copiedstring, returnedstring, (length2 + 1)*sizeof(WCHAR)), >> > + "LoadStringW returned a string that does not match the string pointed to by the pointer it returned. \ >> > + returnedstring = %ls, copiedstring = %ls", (wchar_t *)returnedstring, (wchar_t *)copiedstring); >> > > You cannot cast a WCHAR* to a wchar_t*. > > -- Alexandre Julliard julliard(a)winehq.org Thanks, I assumed they were the same since under Windows WCHAR is typedef'ed as wchar_t. Is the proper way to handle this to use WideCharToMultiByte() on returnedstring and copiedstring, and then pass the converted (multibyte) strings to ok()? Christopher Berner

1 0

Re: kernel32: Forward fiber local storage APIs to thread local storage equivalents.
by Paul Chitescu 29 Feb '08

29 Feb '08

Actually a lot of programs fail to start since the addition of these stubs. In particular anything that uses MSVCRT80. This is a major regression. Most applications seem to live a happy life without fiber local storage - is there one that would benefit from it? On Fri, 29 Feb 2008, Hans Leidekker wrote: > > Photoshop CS2 fails to start after the Fls* stubs were added. This patch > makes it start again but I'm not enough of an expert on this matter to say > if this is the right thing to do. > > -Hans > > Changelog > Forward fiber local storage APIs to thread local storage equivalents.

1 0

Re: msi: ACTION_RegisterProduct store all InstallProperties
by James Hawkins 29 Feb '08

29 Feb '08

On Fri, Feb 29, 2008 at 9:13 AM, Adam Strzelecki <ono(a)java.pl> wrote: > Hi, > > WINE is writing properties such as Language or VersionMajor only to > Uninstall key in ACTION_RegisterProduct, while MSI_GetProductInfo is > trying to read those from InstallProperties key. > > So this patch duplicates all properties written into MSI product > Uninstall key, also to InstallProperies. > This is normal behavior I can see in Windows XP's MSI, as properties > are duplicated in both Uninstall and InstallProperties. > Please do not accept this patch. I'm trying to clean up the publishing code, and without tests to prove this case, it should not go in. The tests that do exist show that the properties are written into the Uninstall key on RegisterProduct, but not the product key. -- James Hawkins

1 0