September 2006 - Wine-devel

Award for solving bug 6183
by Mirek 28 Sep '06

28 Sep '06

There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek

1 0

Re: msi: Implement MsiDatabaseImport [try2]
by Alexandre Julliard 28 Sep '06

28 Sep '06

"James Hawkins" <truiken(a)gmail.com> writes: > +static LPWSTR msi_read_text_archive(LPCWSTR path) > { > - FIXME("%p %s %s\n", db, debugstr_w(folder), debugstr_w(file) ); > + HANDLE file; > + LPSTR data = NULL; > + DWORD read, size = 0; > + > + file = CreateFileW( path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL ); > + if (file == INVALID_HANDLE_VALUE) > + return NULL; > + > + size = GetFileSize( file, NULL ); > + data = msi_alloc( size + 1 ); > + if (!data) > + return NULL; > + > + if (!ReadFile( file, data, size, &read, NULL )) > + return NULL; > + > + data[size] = '\0'; > + return strdupAtoW( data ); > +} You're leaking both the file and the ascii string. -- Alexandre Julliard julliard(a)winehq.org

1 0

Coverity coverage of Wine
by Paul Vriens 28 Sep '06

28 Sep '06

Hi, the latest run (with report) on the Coverity site seems to be from July 21st. It appears that the main page is updated though (not for the lines of code but for the errors fixed). Does anybody know more about the why? I've tried to contact Coverity for the last month and my last email (where I've requested a read-receipt, shame on me) was deleted without being read. Cheers, Paul.

2 5

Re: Route WGL font code through gdi32.dll
by Huw Davies 28 Sep '06

28 Sep '06

On Thu, Sep 28, 2006 at 08:01:00AM +0200, Roderick Colenbrander wrote: > As mentioned by Huw, I forgot to attach the gdi32.spec changes :( > This is (hopefully) a full patch. > > --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.000000000 +0200 > +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.000000000 +0200 > @@ -396,5 +396,5 @@ > @ stdcall wglSwapLayerBuffers(long long) > @ stdcall wglUseFontBitmapsA(long long long long) > @ stdcall wglUseFontBitmapsW(long long long long) > -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) > -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) > +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA > +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You're still forwarding the wrong set of UseFont functions here. Your patch moved wglUseFontBitmaps to gdi32, so you should forward those not wglUseFontOutlines. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: oleaut32 1/2: [RESEND 2] Implements function varformat:VarWeekdayName
by Alexandre Julliard 28 Sep '06

28 Sep '06

"Benjamin Arai" <me(a)benjaminarai.com> writes: > + if (fAbbrev) > + if (iFirstDay == 0) > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); > + else > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); > + else > + if (iFirstDay == 0) > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); > + else > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); iFirstDay == 0 is supposed to mean system default, but that is locale-dependent, you can't simply hardcode it. -- Alexandre Julliard julliard(a)winehq.org

1 0

wined3d base GLX requirement
by Ivan Gyurdiev 28 Sep '06

28 Sep '06

The current base GLX requirement for wined3d seems to be v1.3. It won't compile otherwise... I wrote a patch for pbuffers, which adds proper extension support for SGIX_PBUFFER and SGIX_FBCONFIG, but: - even with the patch there's additional offenders in directx.c that prevent a compile with glx < 1.3 [ more FBCONFIG dependencies ] - there's comments in the source saying ATI supports pbuffers, but only advertises GLX_VERSION_1_3, without the appropriate extensions. So - should GLX 1.3 be considered a base requirement for wined3d, or should I send patches to clean up pbuffer dependencies?

5 6

Linklint results for winehq
by Tom Wickline 28 Sep '06

28 Sep '06

Hello, I ran our linklint script on winehq and here's the results. I will try and fix as many errors as possible over the next couple weeks. Tom --- Processing ... writing files to linklint wrote 25 txt files wrote 23 html files wrote index file index.html found 1 default index found 476 cgi files found 3 html files found 17 image files found 208 other files found 3833 http links found 5 https links found 20 ftp links found 54 mailto links found 15 news links found 2 unknown links found 2658 named anchors ----- 766 ignored files ----- 3 actions skipped ----- 125 files skipped warn 3 warnings ERROR 1 missing image file ERROR 3 missing other files ERROR 99 missing named anchors Linklint found 705 files and checked 500 html files. There were 4 missing files. 13 files had broken links. 103 errors, 3 warnings. real 5m58.972s user 0m6.960s sys 0m0.320s checking 3833 urls ...

1 1

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp 28 Sep '06

28 Sep '06

> From: Alexandre Julliard <julliard(a)winehq.org> > > If you expect > anything to happen, you'll need to make much more concrete > suggestions, and provide examples to make us understand how > what you are suggesting would work in practice Fair enough. Some disclaimers upfront: I'm basically thinking out loud, I have no idea what your typical workflow looks like. I'm also not restrained by any knowledge of emacs and what can be done in its plugins, macro's, user-defined commands or whatever they're called. But I know I could code the proposal below in e.g Perl or C, so I guess it should be possible in Lisp also. Who's going to code that is a different matter altogether, let's first see if we can think of a solution which would work. Let's assume a patch is submitted to wine-patches. A bot would receive it and store it in a database (Patchwork already seems to do a fine job on this). The bot could do some simple checks, like does it apply cleanly, no C++ comments, whatever automatic checks we can come up with. If one of the checks fails, the status would be set to RFC (Request For Change, I'm using the Patchwork statuses here) and the author would receive an automatic email explaining what's wrong, otherwise the status would be set to New. Note that this should save you some time, weeding out "obviously" wrong patches. On to your workflow. You'd issue a Meta-Ctrl-Shift-whatever emacs command. Behind the scenes, this would send a request to the webserver which would reply with a list of queued patches. This list could be sorted by a score. Authors who consistently submit good patches would get a higher score than, well, me. This score could be computed as the number of accepted patches minus the number of rejected patches. A patch already reviewed (and recommended) by a subsystem maintainer could get a real big score boost so it ends up near the top of the list. Patches which have been in the queue for a few days could get extra points. Patches with RFC status wouldn't be shown at all or get a very low score. Anyway, you end up with a list of patches on your screen with the least problematic near the top. This should help ensure that these get through pretty quickly. So you select a patch which is then retrieved from the server. It could be automatically applied, a build started, whatever suits you best. Comments made on it by other developers could be shown to you. After testing is complete, you issue a "decision" command. You can decide to accept the patch, that would send an "accept" message to the webserver and perhaps it could be comitted to your git repo. If the patch needs more work, you'll be prompted for a message. That message will be mailed to the author with a copy to win-devel and it will be sent to the webserver which will change the patch status to RFC. If you think the patch is beyond hope it can be rejected outright (again with a message to author and wine-devel). Or you can decide not to decide on it today and sleep on it for a night. Then the patch will just show up in the list of pending patches again tomorrow, with a little bit higher priority (since it has been in the queue longer). Back to the list of pending patches, repeat. > and how it would be different from what we are doing now. It would make sure the author always receives some kind of feedback (either from the bot, other developers or yourself) and would make sure patches don't get lost (patches are automatically entered into the system and only leave the system when the author withdraws them or when you make a final decision). Ge van Geldorp.

6 6

Re: [PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Vitaliy Margolen 28 Sep '06

28 Sep '06

Christoph Frick wrote: > hi > > would someone please comment on that patch? this is a nearly unchanged > version of my previous attempt - but this time against current git. > > -static const unsigned int depths[] = {8, 16, 32}; > +static const unsigned int depths[] = {8, 16, 32, 24}; > +static const unsigned int nr_depths = sizeof(depths) / sizeof(depths[0]); > Can you make a test that demonstrates presence of 24-bit color depth on native? I have checked winnt40, win2k, winxp and none offering 24-bit. Also I seen some programs and games that will crash if you tell them that we really in 24-bit (as most X users are). Vitaliy.

1 0

Re: Problem with NtReadVirtualMemory and wine server connection
by Juan Lang 28 Sep '06

28 Sep '06

Hi Peter, I'm guessing the fact that no one has replied means that no one has a strong opinion, or no one feels qualified to answer, or that AJ would prefer to see a patch first. I'll give my opinion in the hope of stimulating discussion, as I think it's important. > 1. allocate a temporary buffer in NtReadVirtualMemory, read server > answer to this buffer, and then inside a try / catch block copy to > application memory This would be my preference, for two reasons: 1. This would allow the test to pass, that is, we could successfully return STATUS_ACCESS_VIOLATION in this case. 2. The server protocol appears to be robust enough, as it crashes the client, not the server. The problem is mapping the fault to an NTSTATUS, and recovering from it. The disadvantage may be that each server request would have to be checked whether it could fail in the same way. Any other opinions? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1