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

Re: [PATCH] [Server]: when getting the status of an exception, ensure the debugger continue information is not erased when releasing objects
by Alexandre Julliard Nov. 30, 2009

Nov. 30, 2009

Eric Pouech <eric.pouech(a)orange.fr> writes: > diff --git a/server/debugger.c b/server/debugger.c > index 795a24a..4458a3b 100644 > --- a/server/debugger.c > +++ b/server/debugger.c > @@ -677,6 +677,8 @@ DECL_HANDLER(get_exception_status) > if ((event = (struct debug_event *)get_handle_obj( current->process, req->handle, > 0, &debug_event_ops ))) > { > + NTSTATUS status = STATUS_PENDING; > + > close_handle( current->process, req->handle ); > if (event->state == EVENT_CONTINUED) > { > @@ -686,10 +688,10 @@ DECL_HANDLER(get_exception_status) > set_reply_data( &event->context, size ); > current->context = NULL; > } > - set_error( event->status ); > + status = event->status; > } > - else set_error( STATUS_PENDING ); > release_object( event ); > + set_error( status ); Releasing an object should never change the error code. Where do you see that happening? -- Alexandre Julliard julliard(a)winehq.org

2 2

Introducing WineTestBot
by Joerg-Cyril.Hoehle＠t-systems.com Nov. 30, 2009

Nov. 30, 2009

Greg, Congratulations, that's a great service. >I know that programmers like to be as lazy as possible. >So the next step will be to allow you >to upload the git diff instead of a Windows executable. The next most wanted improvement! Step 3.5 suggestion: split that in two steps, allow us to upload the patch and download the .exe. >so it's probably not all that useful to >run sound and DirectDraw tests on them. Then we can take the .exe to machines with sound and DD/DX to complete the impact analysis. Regards, Jörg Höhle.

2 1

Re: [PATCH 1/3] ole32: Add test for CoLockObjectExternal with fLastUnlockReleases as FALSE.
by Paul Vriens Nov. 30, 2009

Nov. 30, 2009

On 11/23/2009 04:07 PM, Rob Shearman wrote: > --- > dlls/ole32/tests/marshal.c | 38 +++++++++++++++++++++++++++++++++++++- > 1 files changed, 37 insertions(+), 1 deletions(-) > > Tested on XP. > Hi Rob, http://test.winehq.org/data/tests/ole32:marshal.html doesn't look too healthy. Not sure if this is the actual one as there were a few that touched marshal.c. Could you have a look? -- Cheers, Paul.

1 0

Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)
by Alexandre Julliard Nov. 30, 2009

Nov. 30, 2009

Paul Chitescu <paulc(a)voip.null.ro> writes: > @@ -569,11 +569,11 @@ DWORD svcctl_ChangeServiceConfigW( > new_entry.config.lpDisplayName = strdupW(lpDisplayName); > } > > - *service->service_entry = new_entry; > - save_service_config(service->service_entry); > + err = save_service_config(&new_entry); > + if (ERROR_SUCCESS == err) *service->service_entry = new_entry; > service_unlock(service->service_entry); This can't work, the strings have been freed already. -- Alexandre Julliard julliard(a)winehq.org

2 2

Fedora users, please test mci patch about time-out/hanging machine
by Joerg-Cyril.Hoehle＠t-systems.com Nov. 30, 2009

Nov. 30, 2009

Hi, Testhq.org results from 17th of November about winmm:mci were striking: All machines producing a timeout had "f11" in their name. (Another day, some f11 machines passed the tests). http://test.winehq.org/data/4990ca0ea342bd115a9a46047b3b2de599cb916e/index_… Please test whether the following patch correlates with hanging machines. Not checking waveoutwrite's return code for sure has the potential to hang the play loop, waiting for a buffer to come back that was never sent out in case of error. But then, why did waveOutWrite fail? That's what I'd like you to investigate. Why Fedora 11? Below patch only adds error reporting to the mciplay loop. Feel free to add the same to the mcirecord loop. diff --git a/dlls/mciwave/mciwave.c b/dlls/mciwave/mciwave.c index cdf9146..fdb6b18 100644 --- a/dlls/mciwave/mciwave.c +++ b/dlls/mciwave/mciwave.c @@ -882,6 +882,7 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, &waveHdr[whidx], waveHdr[whidx].dwBufferLength, waveHdr[whidx].dwBytesRecorded); dwRet = waveOutWrite(wmw->hWave, &waveHdr[whidx], sizeof(WAVEHDR)); + if (dwRet) ERR("Write %d\n", dwRet); left -= count; wmw->dwPosition += count; TRACE("after WODM_WRITE dwPosition=%u\n", wmw->dwPosition); @@ -893,7 +894,8 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, WAVE_mciPlayWaitDone(wmw); /* to balance first buffer */ /* just to get rid of some race conditions between play, stop and pause */ - waveOutReset(wmw->hWave); + dwRet = waveOutReset(wmw->hWave); + if (dwRet) ERR("Reset %d\n", dwRet); waveOutUnprepareHeader(wmw->hWave, &waveHdr[0], sizeof(WAVEHDR)); waveOutUnprepareHeader(wmw->hWave, &waveHdr[1], sizeof(WAVEHDR)); A future patch will abort the loop in case of error. However so far, when creating situations that hung on my (non-Fedora) machine (cf. bug #20664), the above ERR message was never triggered. So the cause of random mci time-out on test.winehq may as well lay elsewhere. Thanks for your help, Jörg Höhle

3 4

today's git broke winetricks gecko :-(
by Joerg-Cyril.Hoehle＠t-systems.com Nov. 30, 2009

Nov. 30, 2009

Hi, >wine cmd /c echo yes now downloads gecko. Me to -- I'm not pleased with Wine-1.1.33 starting an installation request upon startup. - How am I going to automate regression testing when it hangs waiting for a mouse click? - I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why. >Any suggestions are welcome. Winecfg would be a better place to propose the installation of an optional component. Perhaps I'm a very atypical Wine user: - no MMORPG, no ie6 - My Wine is not used for anything online. Quite to the contrary, I have some iptables firewall rules to disable Wine IP traffic should anything ever manage to get in. - I never used winetricks. I sometimes peeked at it. When I needed Gecko long ago, I saw that the Wine source contains code to install it, downloaded Gecko.cab myself, modified the one registry entry to point to the .cab and let it install. Worked. IMHO, no general-purpose application should attempt to talk to the internet when it starts. Please leave that behaviour to viruses and trojans only (and alikes, e.g. Adobe's pdf). Maybe I'm too old-fashioned in this decade of "always online even in the subway" technical achievements. Or I've been in the privacy-protection (Datenschutz) and security business for too long. Regarding winecfg, it could display "no Gecko/HTML support, click here to install it (need be online)" in flashing red to attract the user's attention once you start it. I wouldn't mind. Regards, Jörg Höhle.

13 25

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
by Alexandre Julliard Nov. 30, 2009

Nov. 30, 2009

Paul Chitescu <paulc(a)voip.null.ro> writes: > Changelog: > wineserver: Added support for read/only Registry, similar to > unprivileged users > > Rationale: > This is a first step towards implementing shared wine prefixes with > most users being unprivileged and a single Administrator (power user, etc.) > capable of installing programs. I don't think it's a step in the right direction. What you need is proper access control with security descriptors, like we have for other objects. A single read-only bit cannot be extended to support this. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control
by Nikolay Sivov Nov. 30, 2009

Nov. 30, 2009

Ilya Shpigor wrote: > +static INT > +DATETIME_GetText (DATETIME_INFO *infoPtr, INT count, LPWSTR dst) > +{ > + WCHAR buf[80]; > + int i; > + > + if(!count) return 0; > + > + dst[0] = 0; > + for (i = 0; i < infoPtr->nrFields; i++) > + { > + DATETIME_ReturnTxt(infoPtr, i, buf, sizeof(buf)/sizeof(buf[0])); > + if ((strlenW(dst) + strlenW(buf)) <= count) > + strcatW(dst, buf); > + else break; > + } > + return strlenW(dst); > +} > I don't think it's a right way. You probably should use window text instead updating it on every change, see how GetWindowText is implemented. > @@ -674,6 +675,10 @@ static void test_wm_set_get_text(void) > ret = SendMessage(hWnd, WM_GETTEXT, sizeof(buff), (LPARAM)buff); > ok(strcmp(buff, a_str) != 0, "Expected text not to change, got %s\n", buff); > > + GetSystemTime(&stime); > + sprintf(time, "%d.%d.%d", stime.wDay, stime.wMonth, stime.wYear); > + ok(!strcmp(buff, time), "Expected %s, got %s\n", time, buff); > + > DestroyWindow(hWnd); > } > Test is definitely wrong. You can't expect DD.MMMM.YYYY pattern here, it's locale dependent.

2 4

Re: mciqtz32: Fix open/close omissions.
by Dmitry Timoshkov Nov. 30, 2009

Nov. 30, 2009

You need to provide more information why is this change required, and what is the problem you are trying to fix. -- Dmitry.

1 0

Re: Implement a stub for PrintWindow in user32
by Dmitry Timoshkov Nov. 30, 2009

Nov. 30, 2009

"Luke Benstead" <kazade(a)gmail.com> wrote: > +/************************************************************************ > + * PrintWindow (USER32.@) > + * > + */ > +BOOL WINAPI PrintWindow(HWND hwnd, HDC hdcBlt, UINT nFlags) > +{ > + return TRUE; > +} If this is a stub, it should not return TRUE, should print a FIXME, and probably set an appropriate last error. Besides, MSDN has a nice hint how to implement this API properly. -- Dmitry.

1 0