July 2007 - Wine-devel - list.winehq.org

Re: [PATCH 1/2] urlmon/tests: Add tests for ObtainUserAgentString.
by James Hawkins 09 Jul '07

09 Jul '07

On 7/8/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > Tested on Win98 and WinXP. if (1)'s for wine page faults are removed in the second patch of the set. > I don't know whether Julliard will accept these patches as they are, but the policy about disabling blocks of tests because they fail on Wine is that it's not allowed. I know the second patch fixes this, but if that is the case, why don't you just send the fixes patch first, then the tests second? -- James Hawkins

1 0

EV_RXFLAG emulation
by Valentine Sinitsyn 09 Jul '07

09 Jul '07

Hi all, I spent the last couple of days trying to run one program in Wine. The program (Easy Wireless Net, end-user tool to control many CDMA modems, if you are interested in) extensively use EV_RXFLAG event which is currently unimplemented in Wine. I've made a simplest implementation possible (fire EV_RXLAG every time you have something in the serial port input buffer - all the messages come in once anyway) and it worked just fine with the aforementioned program, so I have two questions now: 1. Would the patch with such "implementation" for EV_RXFLAG be accepted to the mainline Wine (my take is having some sort of support for the feature is always better that not having support at all) ? 2. Of course, a proper implementation of the feature is desirable - i.e. one should look after EventChar in WaitCommEvent (ntdll/serial.c:wait_for_event(), to be precise) but unfortunately this lead to a trouble (I guess it's the reason why EV_RXFLAG is still unimplemented): you need to "peek" into a buffer or read the data twice: first time in WaitCommEvent to look for eventchar, and second - in NtReadFile to actually obtain the data. And of course, it's not possible, so some sort of buffering must be implemented. Alas, WINE's architecture doesn't imply any buffering between Unix and Windows layer as Developer's Guide states. My proposed solution is to read data in serial.c:wait_comm_event() and store it somewhere; then, in NtReadFile() one should check whether fd corresponds to serial file and, if so, look in the corresponding buffer before doing actual read. Does this fit nicely into WINE's design ? Or there are some other (more correct) approaches to perform this task? Thank you in advance. Regards, Valentine

1 0

Rude hack fixes Run Time Error 445:Object Doesn't Support This Action
by David Anderson 08 Jul '07

08 Jul '07

The following rudely changed function: static HRESULT WINAPI WebBrowser_put_RegisterAsBrowser(IWebBrowser2 *iface, VARIANT_BOOL bRegister) { WebBrowser *This = WEBBROWSER_THIS(iface); FIXME("(%p)->(%x)\n", This, bRegister); TRACE("dadebug fake return\n"); /* My rude addition. */ return S_OK; /* My rude addition */ return E_NOTIMPL; } in wine/dlls/shdocvw/webbrowser.c works around wine bug 5183. For me. The app I use to run the test is a VB app written by a friend (not commercial software). I have no idea what the above function is really supposed to do nor any idea how to even find out. I really don't want a web browser running out of VB anyway :-) Note that a couple years ago the app in question worked. But stopped with Run-time error "445":Object doesn't support this action (oleaut32) at some point. If anyone could make a suggestion of something *meaningful* I could do about this that would be great. What if the above simply returned S_OK with a FIXME instead of E_NOTIMPL??? Would that be an acceptable hack for the official source? David Anderson

2 1

RE: #2 kernel32: Implement GetTickCount64.
by Rolf Kalbermatter 08 Jul '07

08 Jul '07

Hans Leidekker wrote: >Changelog > Implement GetTickCount64. .... >--- a/dlls/kernel32/kernel_main.c >+++ b/dlls/kernel32/kernel_main.c >@@ -256,3 +256,11 @@ DWORD WINAPI GetTickCount(void) > { > return NtGetTickCount(); > } Is there a particular reason not to call NtGetTickCount64() directly here as is also done in NtGetTickCount(). On a side note: I wonder if older C compiler versions will simply do the right coercion from ULONGLONG to DWORD in these cases. Rolf Kalbermatter

2 1

DungeonSiege works!
by Robert Hurst 08 Jul '07

08 Jul '07

Finally running at full speed, see my post at http://appdb.winehq.org/appview.php?iVersionId=1017 But there is only 1 little 'cleanup' that would make this game perfect... its mouse pointer is clean, but the square it occupies is generally filled with a corrupted texture. I own two copies of the game, the original 1.0 and the latest Legends of Arianna 1.11 version. I can send a NOCD copy of it to a d3d developer, for debugging purposes, if that helps any. Send instructions, and it shall be done. Not as important as the mouse pointer, but the loading and saving of sessions is horribly slow, though improved as of 0.9.39. I wonder why? Thanks for 'resurrecting' a lot of abandoned Windows software for the community.

1 0

winealsa/dsound: Testers asked for capture patch
by Maarten Lankhorst 08 Jul '07

08 Jul '07

Since apparantly counter strike goes 2 fps or so when alsa is used and capture is enabled, I was looking to see if that can be speed up,. Since I don't have that game I cannot do it myself, so can someone test attached patch and see if that fixes performance problems? Maarten >From 7593fcf19ba306d0024048e7a49e87b7c8d5c318 Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> Date: Thu, 5 Jul 2007 00:41:59 +0200 Subject: [PATCH] winealsa: Increase performance of wavein getposition --- dlls/winealsa.drv/wavein.c | 12 +++--------- 1 files changed, 3 insertions(+), 9 deletions(-) diff --git a/dlls/winealsa.drv/wavein.c b/dlls/winealsa.drv/wavein.c index 5d731eb..412edd2 100644 --- a/dlls/winealsa.drv/wavein.c +++ b/dlls/winealsa.drv/wavein.c @@ -154,7 +154,7 @@ static DWORD CALLBACK widRecorder(LPVOID pmt) DWORD frames_per_period; wwi->state = WINE_WS_STOPPED; - wwi->dwTotalRecorded = 0; + InterlockedExchange((LONG*)&wwi->dwTotalRecorded, 0); wwi->lpQueuePtr = NULL; SetEvent(wwi->hStartUpEvent); @@ -198,7 +198,7 @@ static DWORD CALLBACK widRecorder(LPVOID pmt) { /* update number of bytes recorded in current buffer and by this device */ lpWaveHdr->dwBytesRecorded += bytesRead; - wwi->dwTotalRecorded += bytesRead; + InterlockedExchangeAdd((LONG*)&wwi->dwTotalRecorded, bytesRead); /* buffer is full. notify client */ if (lpWaveHdr->dwBytesRecorded == lpWaveHdr->dwBufferLength) @@ -247,7 +247,7 @@ static DWORD CALLBACK widRecorder(LPVOID pmt) /* update number of bytes recorded in current buffer and by this device */ lpWaveHdr->dwBytesRecorded += dwToCopy; - wwi->dwTotalRecorded += dwToCopy; + InterlockedExchangeAdd((LONG*)&wwi->dwTotalRecorded, dwToCopy); bytesRead -= dwToCopy; pOffset += dwToCopy; @@ -385,10 +385,6 @@ static DWORD CALLBACK widRecorder(LPVOID pmt) HeapFree(GetProcessHeap(), 0, buffer); ExitThread(0); /* shouldn't go here */ - case WINE_WM_UPDATE: - SetEvent(ev); - break; - default: FIXME("unknown message %d\n", msg); break; @@ -784,8 +780,6 @@ static DWORD widGetPosition(WORD wDevID, LPMMTIME lpTime, DWORD uSize) } wwi = &WInDev[wDevID]; - ALSA_AddRingMessage(&wwi->msgRing, WINE_WM_UPDATE, 0, TRUE); - return ALSA_bytes_to_mmtime(lpTime, wwi->dwTotalRecorded, &wwi->format); } -- 1.4.4.2

2 2

re: Rude hack fixes Run Time Error 445:Object Doesn't Support This Action
by Dan Kegel 08 Jul '07

08 Jul '07

Dave wrote: >The following rudely changed function: >static HRESULT WINAPI WebBrowser_put_RegisterAsBrowser(... >works around wine bug 5183. For me. >The app I use to run the test is a VB app written by a friend Can you throw together a minimal test in VB and attach it with source and binary to bug 5183? - Dan

1 0

Re: [5/5] WineD3D: Implement high order patches
by H. Verbeet 07 Jul '07

07 Jul '07

On 06/07/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > The right list this time > I realize this has already been committed, but is there no way to split tesselate_rectpatch() up a bit into smaller functions? It's rather huge at the moment.

3 2

Re: Paul Vriens : kernel32/tests 2/2: Use skip for not implemented function.
by Michael Stefaniuc 07 Jul '07

07 Jul '07

This patch introduced a lot of dead code. Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 35edd40f33ba8dce6d2c39fda46c6b5045947c1c > URL: http://source.winehq.org/git/wine.git/?a=commit;h=35edd40f33ba8dce6d2c39fda… > > Author: Paul Vriens <paul.vriens.wine(a)gmail.com> > Date: Thu Jul 5 16:35:10 2007 +0200 > > kernel32/tests 2/2: Use skip for not implemented function. > > --- > > dlls/kernel32/tests/profile.c | 24 +++++++++++++++--------- > 1 files changed, 15 insertions(+), 9 deletions(-) > > diff --git a/dlls/kernel32/tests/profile.c b/dlls/kernel32/tests/profile.c > index 4824ce8..b875134 100644 > --- a/dlls/kernel32/tests/profile.c > +++ b/dlls/kernel32/tests/profile.c > @@ -227,31 +227,37 @@ static void test_profile_sections_names(void) > ok( ret == 25, "expected return size 25, got %d\n", ret ); > ok( buf[ret+1] == 0 && buf[ret] == 0, "returned buffer not terminated with double-null\n" ); > > + /* Tests on nonexistent file */ > + memset(buf, 0xcc, sizeof(buf)); > + ret = GetPrivateProfileSectionNamesA( buf, 10, ".\\not_here.ini" ); > + ok( ret == 0, "expected return size 0, got %d\n", ret ); > + ok( buf[0] == 0, "returned buffer not terminated with null\n" ); > + ok( buf[1] != 0, "returned buffer terminated with double-null\n" ); > > /* Test with sufficiently large buffer */ > + SetLastError(0xdeadbeef); > ret = GetPrivateProfileSectionNamesW( bufW, 29, testfile3W ); Looks like some if () is missing here. The skip and return are therefor called unconditionally. Smatch is rightfully complaining about dead code after the return. > + { > + skip("GetPrivateProfileSectionNamesW is not implemented\n"); > + DeleteFileA( testfile3 ); > + return; > + } bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

winealsa/dsound: Testers asked for capture patch
by ling weak 07 Jul '07

07 Jul '07

Sorry, I couldn't notice any improvements using that patch. For your information: >From wine-0.9.36 to .39 graphics and sound were very choppy. As of wine-0.9.40 video is still stuck at 4fps but audio plays stutter-free. I think this was caused by your remixing-patch.

1 0