October 2009 - Wine-Devel - list.winehq.org

Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)

by Nicolas Le Cam

2009/10/30 Paul Vriens <paul.vriens.wine(a)gmail.com>: > On 10/29/2009 01:09 AM, Louis Lenders wrote: >> >> changes: >> >> -fixed typo in ok-call >> -removed FormatMessageW-tests (W behaves same as A) >> -removed useless test for GetLastError in case FormatMessageA succeeds >> >> > > Hi Louis, > > These new tests introduce some test failures on several platforms: > > http://test.winehq.org/data/tests/kernel32:format_msg.html > > On Win9x/WinMe it seems like just another last error. > > There seems to be an issue with a particular test when run on a Windows box > with no English locale (or something different about the locale): > > http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w… > > On Vista/Win7/W2K8 there are also different last errors but some are not yet > defined in our headers: > > 15100 : ERROR_MUI_FILE_NOT_FOUND > 15105 : ERROR_MUI_FILE_NOT_LOADED > > Could you have a look? > > -- > Cheers, > > Paul. > > > w2k-sp4-fr has French locale. I didn't have time to investigate right now but if you need more tests just ask. -- Nicolas Le Cam

Oct. 30, 2009

Re: wined3d: recognize Nvidia 8500 GT

by Roderick Colenbrander

We use this mechanism on purpose. We can't have hundreds of cards in the database. The real name isn't that important it is mostly cosmetic, so it is not a real bug. Roderick

Oct. 30, 2009

Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)

by Paul Vriens

On 10/29/2009 01:09 AM, Louis Lenders wrote: > changes: > > -fixed typo in ok-call > -removed FormatMessageW-tests (W behaves same as A) > -removed useless test for GetLastError in case FormatMessageA succeeds > > Hi Louis, These new tests introduce some test failures on several platforms: http://test.winehq.org/data/tests/kernel32:format_msg.html On Win9x/WinMe it seems like just another last error. There seems to be an issue with a particular test when run on a Windows box with no English locale (or something different about the locale): http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w… On Vista/Win7/W2K8 there are also different last errors but some are not yet defined in our headers: 15100 : ERROR_MUI_FILE_NOT_FOUND 15105 : ERROR_MUI_FILE_NOT_LOADED Could you have a look? -- Cheers, Paul.

Oct. 30, 2009

Re: msvcrt: dont overlap in strcpy (valgrind)

by Vitaliy Margolen

André Hentschel wrote: > here is a case where valgrind claims about "Source and destination overlap in strcpy". > snprintf(data->efcvt_buffer, 80, "%.*le", prec - 1, number); > /* take the decimal "point away */ > if( prec != 1) > - strcpy( data->efcvt_buffer + 1, data->efcvt_buffer + 2); > + { > + char *src = data->efcvt_buffer + 2, *dest = data->efcvt_buffer + 1; > + while ((*dest++=*src++) != 0); > + } You should use memmove instead. Vitaliy.

Oct. 30, 2009

Re: [Bug 20505] After winetricks comctl32, wine does not work completely

by Austin English

On Thu, Oct 29, 2009 at 12:06 PM, Massimo Del Fedele <max(a)veneto.com> wrote: > I agree with you that the use of winetricks and native dll is not a wine > devel issue, but here things are different.... > The DLL USED to work, and now it doesn't. BTW, it doesn't for some apps > (winecfg in primis) and it do for others. > So, I see it as a regression. Maybe there are good reasons because it > doesn't work anymore, maybe it's a bug > introduced in new versions which is worth to analyze. Does this help? -- -Austin

Oct. 29, 2009

Re: [Bug 20505] After winetricks comctl32, wine does not work completely

by Massimo Del Fedele

James Mckenzie ha scritto: >> wine-bugs(a)winehq.org ha scritto: >>> http://bugs.winehq.org/show_bug.cgi?id=20505 >>> >>> >>> Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: >>> >>> What |Removed |Added >>> ---------------------------------------------------------------------------- >>> Status|RESOLVED |CLOSED >>> >>> >>> >>> >>> --- Comment #3 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-10-28 23:53:57 --- >>> Closing invalid. >>> >> This one happens here too, and it used to work before, so IMHO is a regression. >> > I beg to differ. The use of winetricks to get around shortcomings of Wine is not a Wine developer issue and should be addressed to Dan Kegel and Austin English. > > James McKenzie > > > > I agree with you that the use of winetricks and native dll is not a wine devel issue, but here things are different.... The DLL USED to work, and now it doesn't. BTW, it doesn't for some apps (winecfg in primis) and it do for others. So, I see it as a regression. Maybe there are good reasons because it doesn't work anymore, maybe it's a bug introduced in new versions which is worth to analyze. Max

Oct. 29, 2009

Re: New valgrind results for Oct 26, 2009

by André Hentschel

Dan Kegel schrieb: > 2009/10/28 André Hentschel <nerv(a)dawncrow.de>: >> I think i found a false postitv. its http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/vg-ntdll_env.txt >> the code in ntdll/tests/env.c looks like: >> ... >> name.Buffer = bn; >> ... >> value.Buffer = bv; >> ... >> nts = pRtlQueryEnvironmentVariable_U(small_env, &name, &value); >> ... >> if(memcmp(bv, bn, test->len*sizeof(WCHAR)) == 0) >> >> So valgrind thinks bn and bv are uninitialised, but thats wrong. >> Do you agree with me? > > I actually looked at this one for an hour the other day. > I think valgrind's probably right, but the test is confusingly written. So i send this issue to wine-devel to know what other devs think about it. -- Best Regards, André Hentschel

Oct. 29, 2009

Order of setting audio Play/Pause state and device opening

by Joerg-Cyril.Hoehle＠t-systems.com

Ken, I was please to see your recent changes to winecoreaudio. In my quest for audio bugs, when I reviewed the code, I found the following which I believe is wrong or I don't understand. Maybe you could look at it? BTW, the code and comments are the same in both wineoss.drv and winecoreaudio.drv. In audio.c/wodPause: /* The order of the following operations is important since we can't hold * the mutex while we make an Audio Unit call. Stop the Audio Unit before * setting the PAUSED state. That's indeed what the code below does. * Although we can be in PAUSED * state with the Audio Unit still running, Quite to the contrary, PAUSED state is only set after the unit stopped. * that's harmless because the * render callback will just produce silence. I can't comment on that. The code is (error checking not shown): status = AudioOutputUnitStop(wwo->audioUnit); OSSpinLockLock(&wwo->lock); if (wwo->state == WINE_WS_PLAYING) wwo->state = WINE_WS_PAUSED; OSSpinLockUnlock(&wwo->lock); In audio.c/wodRestart: * In wodRestart, the order is reversed. Indeed. * This guarantees that we can't get into a situation where the state is * PLAYING but the Audio Unit isn't running. Quite to the contrary, PLAYING state is reached yet AudioOutputUnitStart is only called a few instructions afterwards. Likewise above, it's stopped and PLAYING state is only unset afterwards. OSSpinLockLock(&wwo->lock); if (wwo->state == WINE_WS_PAUSED) wwo->state = WINE_WS_PLAYING; OSSpinLockUnlock(&wwo->lock); status = AudioOutputUnitStart(wwo->audioUnit); Is my understanding wrong? Does the code need be changed to reflect the comments? Do the comments need correction? Thanks, Jorg Hohle

Oct. 29, 2009

Re: crypt32: CryptUnprotectData: test zero-length payload

by Dan Kegel

On Thu, Oct 29, 2009 at 7:05 AM, Dan Kegel <dank(a)kegel.com> wrote: > On Thu, Oct 29, 2009 at 1:06 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >> Some testfailures on everything below W2K. Some tests were already skipped >> because of this. >> >> I tried several things but the last error is always set to >> RPC_X_WRONG_STUB_VERSION. Maybe we should test for that before we do any >> tests and bail out? Does this error make sense on 9x/Me/NT4? > > http://www.codeguru.com/forum/archive/index.php/t-326734.html > may have a clue, it mentions that midl has a /robust option that > produces this error if used with older windows? > http://msdn.microsoft.com/en-us/library/aa367363(VS.85).aspx Oh, and the other part of the clue: I hear that on Windows, this function's guts are implemented with COM. So perhaps Windows is tripping over its shoelaces internally on this?

Oct. 29, 2009

Re: crypt32: CryptUnprotectData: test zero-length payload

by Dan Kegel

On Thu, Oct 29, 2009 at 1:06 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Some testfailures on everything below W2K. Some tests were already skipped > because of this. > > I tried several things but the last error is always set to > RPC_X_WRONG_STUB_VERSION. Maybe we should test for that before we do any > tests and bail out? Does this error make sense on 9x/Me/NT4? http://www.codeguru.com/forum/archive/index.php/t-326734.html may have a clue, it mentions that midl has a /robust option that produces this error if used with older windows? http://msdn.microsoft.com/en-us/library/aa367363(VS.85).aspx - Dan

Oct. 29, 2009