February 2012 - Wine-Devel - list.winehq.org

bugzilla: show the component, not "comp" and not the assignee

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

Hi, Somehow I discovered that bugzilla can display the component in a search result list. Now I'm using that instead of the useless "assignee" field. Here's part of the URL I'm using: &columnlist=bug_severity%2Cop_sys%2Ccomponent%2Cbug_status%2Cshort_desc& Unfortunately, the column named "Comp" only holds 8 characters, causing ugly names like: directx- : you don't know which one out of ten directx-YZ winmm&mc : one missing letter looks rather stupid It would be nice if some bugzilla admin would enlarge that column BTW, I recently suggested replacing the mostly useless "assignee" column in the default search result list by the component. No answer. What do you think? Thank you, Jörg Höhle

Feb. 27, 2012

Re: Major mmdevapi and winmm audio bugs

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

Hi, Maarten Lankhorst wrote (partly in a former thread): >> R. thread priority -- no "Pro Audio" / Real-Time priority >Not going to happen, ever. AJ nuked all my attempts at it, >[...] >Or just fix things properly and use rtkit for time critical threads and now: >I would say using rtkit for setting threads to realtime would be an aid for this. I can understand AJ's reluctance to RT code in Wine. I wouldn't feel comfortable either. I believe few people realize that RT is a gifted gift. Bear in mind that RT processes work at a priority above any root or user process. Do something wrong there, consume 100% CPU and you can press the single core machine's power down button. I would not accept RT code in a system without a very careful code review and think twice about the consequences, and require a design that keeps the RT part of the app as small as possible, better separated. OTOH, RT is the means to provide reliable ticks, and that's why PA as a sound server wants that. Now one can argue that Wine's mmdevapi plays sound server for all w32 apps, so it has the same needs. >I'm just using a simple mainloop thread That's my plan for past 1.4 too. Get rid of CreateTimerQueue as callback source in mmdevapi, use a thread for the feeder and poll() to wait 10ms, like all devices used to do. I believe that's too big a change for code freeze. W.r.t. to 1.4.0, I believe the following path should be taken: - Write CreateTimerQueue tests to verify whether native behaves like: a) sleep(Xms) /* what Wine does now */ or b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */ - If b), fix CreateTimerQueue. - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi and something else must be sought... Regards, Jörg Höhle

Feb. 27, 2012

Re: Testbot and changes to multiple tests

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

Stefan Dösinger wrote: >When I manually submit a patch to the Wine testbot, it refuses to test it if >the patch changes multiple tests. I know that and live with it as follows: - I usually keep changes to separate tests as distinct commits in my git, so I can send them separately to testbot. I merge them just prior to submission to wine-patches. - Alternatively, I edit the patch file in an editor and change it so that only one test file is modified, then edit again, saving the second test. >Why are they refused when I submit them via the testbot web interface? Perhaps to keep the web interface clean? (e.g. page 3 where it's asking you for the command line arguments) Regards, Jörg Höhle

Feb. 27, 2012

Re: po: zh_TW translation updates

by Hin-Tak Leung

--- On Mon, 27/2/12, 盧瑞元 <rueiyuan.lu(a)gmail.com> wrote: <snipped> > >> msgid "Finished searching the document." > >> -msgstr "檔案搜尋結束。" > >> +msgstr "檔案查找結束." > > "查找" is used in zh_CN, not zh_TW. > > > The older version is preferred. (may be it is just my > opinion). > > > >> msgid "Failed to load the RichEdit library." > >> -msgstr "RichEdit 載入失敗。" > >> +msgstr "RichEdit 裝載失敗." > > Same as above. > > > ditto here. The older version is preferred. That's two of us, saying those two changes are questionable. I think quite a few other changes in that patch is of this opinion. Here is the patch, BTW, http://www.winehq.org/pipermail/wine-patches/attachments/20120225/a9133e28/… for those of us who can read chinese.

Feb. 27, 2012

Re: msvcrt/file.c: file mode T (temporary file) (try 3)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17117 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2KPROSP4 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === WXPPROSP3 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2K3R2SESP2 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === WVISTAADM (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2K8SE (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PRO (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PROX64 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === TEST64_W7SP1 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PROX64 (64 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === TEST64_W7SP1 (64 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed.

Feb. 27, 2012

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > I don't see any evidence that you are addressing the issues that caused > us to not do that in the first place. Because the only thing I want to see fixed at this point is a view leak, it's still better than current state of things. Without this fix Wine shows exactly the same broken behaviour as NT4 does in the loader test when LoadLibrary is called on an already mapped image: dangling/leaked file handle, inability to overwrite/delete an executable file. -- Dmitry.

Feb. 27, 2012

Re: Hungarian translation patch 2

by Nagy Zoltán

I would like to send a translation patch again. I am sending the file attached with the mail. Best regards,Zoltan Nagy Francois Gouget <fgouget(a)free.fr> írta: > >Thanks. That first patch made quite a big difference already. Hungarian >is now in the 90% range :-) > >I noticed some issues though: > >-#, fuzzy > msgid "&Modify/Remove" > msgstr "&Módosítás/Eltávolítás..." > >You should remove the ellipsis here. > > > msgctxt "Saturation" > msgid "&Sat:" >-msgstr "" >+msgstr "&Telítettség:" > > msgctxt "Luminance" > msgid "&Lum:" >-msgstr "" >+msgstr "&Fényerő" > >These two may be too long, hence why they are truncated in English. You >can check in winecfg. Go to Desktop Integration, pick an Item, click on >Color and click on Define Custom Colors. They should also have a >trailing colon. > > > msgctxt "All key" > msgid "A" >-msgstr "" >+msgstr "A" > >Given that 'All' is translated into 'Mind', this should most likely be >an 'M'. > > >-#, fuzzy > msgid "Certificate &status:" >-msgstr "Tanusítvány beszerzés" >+msgstr "Tanusítvány &állapot" > >-#, fuzzy > msgid "&Friendly name:" > msgstr "Keresztnév" > >More missing colons... Also the second one looks like it's supposed to >have a keyboard shortcut. > > > msgid "Connection is active.\n" >-msgstr "Kapcsolat aktív" >+msgstr "Kapcsolat aktív\n" > >This one should probably have a trailing full stop. > > > >You'll find more issues like this on the Wine PO site. >http://fgouget.free.fr/wine-po/ > > >Specifically: >http://fgouget.free.fr/wine-po/hu-errors.html > > >-- >Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > La terre est une bêta...

Feb. 27, 2012

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> I don't see any evidence that you are addressing the issues that caused >> us to not do that in the first place. > > Because the only thing I want to see fixed at this point is a view leak, > it's still better than current state of things. I don't think that deleting an object that may have references is making things better. -- Alexandre Julliard julliard(a)winehq.org

Feb. 27, 2012

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -1548,6 +1549,11 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, LPCWSTR name, HANDLE file, > *pwm = wm; > status = STATUS_SUCCESS; > done: > + if (status) > + { > + if (wm) free_modref( wm ); > + else if (module) NtUnmapViewOfSection( NtCurrentProcess(), module ); > + } I don't see any evidence that you are addressing the issues that caused us to not do that in the first place. -- Alexandre Julliard julliard(a)winehq.org

Feb. 27, 2012

Re: dsound: Small fixes to IDirectSoundCaptureBuffer

by Andrew Eikum

This patch looks sane and fixes the tests on my machine, but causes no changes to dsound capture behavior in Audacity. I don't have much of an opinion on if it should go in for 1.4. On Tue, Feb 21, 2012 at 05:33:35PM +0100, Maarten Lankhorst wrote: > --- > I suspect a lot more AUDCLNT_E_* calls will have to be mapped > correctly, but at least this is enough to pass the dsound:capture > tests again on wine. > > dlls/dsound/capture.c | 8 +++++--- > dlls/dsound/tests/capture.c | 24 +++++++++++++++--------- > 2 files changed, 20 insertions(+), 12 deletions(-) > > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 90cddb7..7ceddfc 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -456,13 +456,14 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_Start(IDirectSoundCaptureBuf > > EnterCriticalSection(&(This->device->lock)); > > - This->flags = dwFlags; > - TRACE("old This->device->state=%s\n",captureStateString[This->device->state]); > if (This->device->state == STATE_STOPPED) > This->device->state = STATE_STARTING; > else if (This->device->state == STATE_STOPPING) > This->device->state = STATE_CAPTURING; > + else > + goto out; > TRACE("new This->device->state=%s\n",captureStateString[This->device->state]); > + This->flags = dwFlags; > > if (This->device->buffer) > FillMemory(This->device->buffer, This->device->buflen, (This->device->pwfx->wBitsPerSample == 8) ? 128 : 0); > @@ -474,6 +475,7 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_Start(IDirectSoundCaptureBuf > return hres; > } > > +out: > LeaveCriticalSection(&This->device->lock); > > TRACE("returning DS_OK\n"); > @@ -705,7 +707,7 @@ static HRESULT IDirectSoundCaptureBufferImpl_Create( > HeapFree(GetProcessHeap(), 0, This->pdscbd); > This->device->capture_buffer = 0; > HeapFree( GetProcessHeap(), 0, This ); > - return err; > + return err == AUDCLNT_E_UNSUPPORTED_FORMAT ? DSERR_BADFORMAT : err; > } > > err = IAudioClient_GetService(device->client, &IID_IAudioCaptureClient, > diff --git a/dlls/dsound/tests/capture.c b/dlls/dsound/tests/capture.c > index 96fb417..2040f3f 100644 > --- a/dlls/dsound/tests/capture.c > +++ b/dlls/dsound/tests/capture.c > @@ -393,15 +393,18 @@ static void test_capture_buffer(LPDIRECTSOUNDCAPTURE dsco, > ok(ref==0,"IDirectSoundNotify_Release(): has %d references, should have " > "0\n",ref); > > - if (record) { > - rc=IDirectSoundCaptureBuffer_Start(dscbo,DSCBSTART_LOOPING); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > + rc=IDirectSoundCaptureBuffer_Start(dscbo,DSCBSTART_LOOPING); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > + > + rc=IDirectSoundCaptureBuffer_Start(dscbo,0); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > > - rc=IDirectSoundCaptureBuffer_GetStatus(dscbo,&status); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_GetStatus() failed: %08x\n", rc); > - ok(status==(DSCBSTATUS_CAPTURING|DSCBSTATUS_LOOPING), > - "GetStatus: bad status: %x\n",status); > + rc=IDirectSoundCaptureBuffer_GetStatus(dscbo,&status); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_GetStatus() failed: %08x\n", rc); > + ok(status==(DSCBSTATUS_CAPTURING|DSCBSTATUS_LOOPING), > + "GetStatus: bad status: %x\n",status); > > + if (record) { > /* wait for the notifications */ > for (i = 0; i < (NOTIFICATIONS * 2); i++) { > rc=WaitForMultipleObjects(NOTIFICATIONS,state.event,FALSE,3000); > @@ -416,9 +419,12 @@ static void test_capture_buffer(LPDIRECTSOUNDCAPTURE dsco, > break; > } > > - rc=IDirectSoundCaptureBuffer_Stop(dscbo); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > } > + rc=IDirectSoundCaptureBuffer_Stop(dscbo); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > + > + rc=IDirectSoundCaptureBuffer_Stop(dscbo); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > } > > static BOOL WINAPI dscenum_callback(LPGUID lpGuid, LPCSTR lpcstrDescription, > -- > 1.7.7.6 > > > > >

Feb. 27, 2012