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

Re: kernel32: catch invalid memory accesses in resource enumerationhandlers
by Dmitry Timoshkov 05 Oct '09

05 Oct '09

"Andrey Turkin" <andrey.turkin(a)gmail.com> wrote: > This is what Windows do as described by AF in bug 10525 (I tested it and > all 3 enumeration functions indeed do catch page faults and fail > gracefully). Should fix bugs 10525 and 16320. It would be better to use SEH only around the real callback call, and not around the whole API body. Adding 2 wrappers for calling the callbacks would simplify the code. And the tests wouldn't hurt. -- Dmitry.

1 0

please test audio with WINETEST_INTERACTIVE=1
by Joerg-Cyril.Hoehle＠t-systems.com 05 Oct '09

05 Oct '09

Hi, when the WINETEST_INTERACTIVE variable is set, winetest.exe and make test perform more checks. These are in danger of bit-rotting. E.g. dplayx is not tested at all without WINETEST_INTERACTIVE! Please test the sound systems using WINETEST_INTERACTIVE with and without hardware acceleration/emulation. On my machines, several tests fail, whereas the tests without WINETEST_INTERACTIVE succeed. - make dsound.ok, dsound8.ok or ds3d.ok: - Sometimes playing only for 837ms instead of 1000ms. - Sometimes producing noise instead of a sine tone on Linux and MacOS. - crashes Wine on MacOS. Please test again for every audio driver winecfg shows (OSS/ALSA/Jack etc.). That makes 2*N invocations. Please test on MS-Windows as well. In a shell: set WINETEST_INTERACTIVE=1 winetest.exe This may help show whether the tests or the audio drivers are broken. On UNIX: WINETEST_INTERACTIVE=1 make test or make wave.ok I also recommend you change runtest -q into -v in the Makefile or on the command line. This will show the test trace output. When unset on UNIX, I still get some seemingly minor test failures. The test report says that it played for 998ms instead of 1000ms here and there. Thank you, Jörg Höhle

2 1

Re: kernel32/tests: Pass test on error code returned by Windows 7
by Dmitry Kislyuk 05 Oct '09

05 Oct '09

--- On Mon, 10/5/09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: From: Paul Vriens <paul.vriens.wine(a)gmail.com> Subject: Re: kernel32/tests: Pass test on error code returned by Windows 7 To: "Dmitry Kislyuk" <dimaki(a)rocketmail.com> Cc: wine-devel(a)winehq.org Date: Monday, October 5, 2009, 12:49 AM On 10/05/2009 05:09 AM, Dmitry Kislyuk wrote: > > > --- On *Sun, 10/4/09, Paul Vriens /<paul.vriens.wine(a)gmail.com>/* wrote: > > > From: Paul Vriens <paul.vriens.wine(a)gmail.com> > Subject: Re: kernel32/tests: Pass test on error code returned by > Windows 7 > To: dimaki(a)rocketmail.com > Cc: wine-devel(a)winehq.org > Date: Sunday, October 4, 2009, 4:20 AM > > On 10/04/2009 09:10 AM, Dmitry Kislyuk wrote: > >> + ok( GetLastError() == 0xdeadbeef || GetLastError() == 2 /* Win > 7 */, > >> + "expected 0xdeadbeef or 2, got %d\n", GetLastError()); > > >Don't use magic numbers, ERROR_FILE_NOT_FOUND would be better. > > >-- Cheers, > > >Paul. > > Hi Paul, > > All of the tests in this group of tests are the same way. Magic > numbers instead of defines. I wanted to stay consistent with that. > > If Alexandre doesn't apply it I will resend with using > ERROR_FILE_NOT_FOUND per your suggestion. > > Thank you for looking at my patch. > > Dmitry > >Hi Dmitry, >The 'magical numbers' you are talking about in profile.c are not error >codes but the return values from for example GetPrivateProfileStringA >(number of characters). >-- >Cheers, >Paul. Thank you, I modified the patch and resent it. Dmitry

1 0

oleaut - SysAllocString/SysFreeString
by Markus Stockhausen 05 Oct '09

05 Oct '09

Hi, maybe this topic has discussed before but I did not find any threads in the devel mailing list for the last months. Additionally i followed wine development for only a few weeks. So here we go ... oleaut.c in native Windows has some type of "heap reusage" when working with strings. This can be unconvered when placing debug messages into IMalloc_xxx functions. A sequence of SysAllocString, SysFreeString will show something like that: Alloc olemalloc:IMalloc_fnAlloc (0x7ec47df8, 16) - addr is 0x12a1b8 Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16 Alloc nothing Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16 When exiting the program one can see a message like this olemalloc:IMalloc_fnFree (0x7ec47df8, 0x12a1b8) In Wine the heap will be released immediately. Why sould that be of any concern you may ask. This behaviour makes some buggy applications run with native oleaut32 (see bug 12460). In this case the application copies the contents of a string directly after it has been freed. Wine corrupts the heap in between and the application will crash. My question is: Should this behaviour declared as "application is buggy & will not be fixed" or has a patch a chance to find its way into git? An idea would be an deferred free like this. - TlsAlloc on entry of dll. - SysFreeString TlsGetValue for last address if value is set FreeHeap(address) TlsSetValue for current address - on exit of dll do some cleanup (heap & Tls) Of course this behaviour is far away from the oleaut implementation and will consume some more CPU cycles. Thanks for your feedback in inadvance. Markus

4 6

Re: [PATCH] Add test case to user32 winetests for edit control contextmenu.
by Dmitry Timoshkov 05 Oct '09

05 Oct '09

"Michael Martin" <martinmnet(a)hotmail.com> wrote: > +WNDPROC editWndProc; Should be static. > +static INT_PTR CALLBACK edit_control_wndproc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) INT_PTR is wrong return type for a window proc. > +{ > + static int timerCount = 0; > + HGLOBAL cbData; > + LPTSTR lptStrCopy; > + LPARAM mousePos; > + HWND findHwnd; > + RECT winRect; > + > + ok(msg != WM_COMMAND, "Should not have received WM_COMMAND\n"); > + > + switch(msg) > + { > + case WM_TIMER: > + switch(timerCount) > + { > + case 0: > + /* Copy some data to clipboard */ > + cbData = GlobalAlloc(GMEM_MOVEABLE, 5); > + lptStrCopy = (TCHAR*)GlobalLock(cbData); > + memcpy(lptStrCopy, "test", 4); > + OpenClipboard(hwnd); > + SetClipboardData(CF_TEXT, cbData); > + CloseClipboard(); TCHAR should be never used in Wine. String above is not 0 terminated. A comment explaining that you want to enable some menu item would be helpful as well. > + > + /* Move mouse to upper left of text control */ > + GetWindowRect(hwnd, &winRect); > + SetCursorPos(winRect.left, winRect.top); > + mousePos = MAKELPARAM(winRect.left + 20, winRect.top + 20); > + /* Show the Context Menu */ > + PostMessage(hwnd, WM_CONTEXTMENU, (WPARAM)hwnd, mousePos); > + break; > + case 1: > + case 2: > + case 3: > + case 4: > + /* Find the menu window and send keydown */ > + findHwnd = FindWindowEx(NULL, NULL, MAKEINTATOM(0x8000), NULL); > + PostMessage(findHwnd, WM_KEYDOWN, VK_DOWN,0); > + break; > + case 5: > + /* Find the menu window and send return, selecting the menu item */ > + findHwnd = FindWindowEx(NULL, NULL, MAKEINTATOM(0x8000), NULL); > + PostMessage(findHwnd, WM_KEYDOWN, VK_RETURN,0); > + break; You should use the menu notification messages instead of FindWindowEx above. > + editWndProc = (WNDPROC)SetWindowLong(hwEdit, GWL_WNDPROC,(LONG)edit_control_wndproc); SetWindowLongPtr() should be used here with appropriate GWLP_ value. If the test doesn't pass under Wine you sould use todo_wine(). -- Dmitry.

1 0

Re: kernel32/tests: Pass test on error code returned by Windows 7
by Paul Vriens 05 Oct '09

05 Oct '09

On 10/04/2009 09:10 AM, Dmitry Kislyuk wrote: > + ok( GetLastError() == 0xdeadbeef || GetLastError() == 2 /* Win 7 */, > + "expected 0xdeadbeef or 2, got %d\n", GetLastError()); Don't use magic numbers, ERROR_FILE_NOT_FOUND would be better. -- Cheers, Paul.

2 2

Re: urlmon #11: Move setting protocol_sink to separated function.
by Austin English 04 Oct '09

04 Oct '09

2009/10/3 ink Griffioen <inkiejay(a)hotmail.com>: Forgot the patch. -- -Austin

2 1

d3d9:visual not crashing :)
by Erik Inge Bolsø 03 Oct '09

03 Oct '09

Whee! For the first time since I started running the test suite a few versions ago on this 2005-vintage laptop with WinXP Pro, d3d9:visual didn't crash today. (Intel 915GM, latest drivers from Intel) http://test.winehq.org/data/3c98992f5537dab767bff701de5a210d0ae32907/xp_kna… Tons of failures, but no crash. :) (Only the mapi32 tests are crashing at the moment, they've always done that on this box for some reason) -- -erik http://useofwords.blogspot.com/

1 0

question about concurrent access to resources
by Joerg-Cyril.Hoehle＠t-systems.com 02 Oct '09

02 Oct '09

Hi, I need some information about threads and callbacks. I already found out that: - SetEvent delivers "asynchronously" and can unblock threads WaitingForMultipleObjects. No callback is involved (which does not mean that the current thread cannot be preempted by another one awakening). Therefore, this seems strange: LeaveCriticalSection(&wma->cs); SetEvent(wma->hStopEvent); EnterCriticalSection(&wma->cs); I mean, if you left it, anything can have happened in between (including close of the device). - Likewise, notifications (to either thread or window) deliver asynchronously as well, to a message queue. No callback is involved. - OTOH functions like waveOutReset will callback into the applications (via Un-/PrepareBuffer etc.). In this example, LeaveCriticalSecion seems necessary, because waveOutReset does everything on the caller's thread, which might cause a driver to be entered recursively. LeaveCriticalSection(&wma->cs); dwRet = waveOutReset(wma->hWave); EnterCriticalSection(&wma->cs); HOWEVER, Critical sections can be re-entered by the same thread. They are no inner-thread protection. Why then leave it? Is the Critical section adequate at all? What else is useable? Is it allowed for an application to call waveOpen in one thread and then call waveOut, waveStart, waveAddBuffer etc. from another one? Is it allowed to mmioSeek/mmioRead from different threads using the same handle? Thanks for your help, Jörg Höhle

2 1

Re: comctl32: implement LISTVIEW_ApproximateViewRect for icon and small icon.
by Nikolay Sivov 02 Oct '09

02 Oct '09

James Mckenzie wrote: > Nikolay Sivov wrote at Oct 2, 2009 11:37 AM (PNT) > >> Aric Stewart wrote: >> >>> --- >>> dlls/comctl32/listview.c | 39 ++++++++++++++++++++++++++++++++++----- >>> 1 files changed, 34 insertions(+), 5 deletions(-) >>> >>> >> Hi, Aric. >> >> >> Also this is unsafe: >> --- >> + row_count = wWidth / (rcBox.right - rcBox.left); >> --- >> > > Is this preceeded with a zero check? Otherwise you could end up with a run-time divide by zero error or worse, a negative row count. Also, if the box were small and the item wide, you could end up with a condition where the box might be larger than the screen height. > > James McKenzie > Hi, James. Wrongly addressed actually :). It's better to reuse coord. calculation code here as I mentioned in reply. Tests needed anyway....

1 0