December 2006 - Wine-devel - list.winehq.org

Call for DirectPlay captures
by Kai Blin 04 Dec '06

04 Dec '06

Hi folks, As you might know, I'm currently toying with figuring out the MS DirectPlay protocol. I've been making some progress with my wireshark dissector over the weekend, and would be interested in some additional games to get more different data on some of this stuff. Here's what I would like you to do (if you want to help out): Fire up a network sniffer that dumps to libpcap format. Grab TCP and UDP packets. Start a game that uses DirectPlay for networking and start a network game. Start the game on another box and connect to the game. Now, in the game lobby, use the chat to say something from both games. Then, change a setting or two and start the game. After a few moments of playing (or more, your pick), leave the game. After both games are closed, you can stop the capture, zip it up and send it to me. Thanks in advance, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

4 6

Re: riched20: fixes and additional conformance tests for EM_EXSETSEL
by Matt Finnicum 04 Dec '06

04 Dec '06

Hey, I'm sorry for not noticing this bug earlier - I have a bad habit of only browsing bugs listed under wine-richedit. I actually sent in a patch that fixes this bug before, but it wasn't accepted because I hadn't marked a test that it causes to fail as todo_wine. Does the attached patch solve your problem? The attached patch moves all the logic to ME_SetSelection, so it'll apply to EM_SETSEL as well as EM_EXSETSEL (they both are supposed to follow the same special cases), and this way it will contribute to my further separating functionality from the message handlers into ME_ local functions which is needed to properly implement windowless controls. This patch does result in a wrong return if the user sent a SetSelection beyond the end of the document (windows allows you to select an imaginary character at the end), but I don't think that's a problem for anything, and I'll have it working in a couple weeks (I'm working on improving the selection code in general, a part of which will allow you to actually select that extra character in our richedit). I suppose i could just put a small hack in for the meantime, if anyone cares. I haven't tried them together yet, but your new tests do look significantly more comprehensive - well done. --Matt On 12/3/06, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > Changelog: > * Check the input to EM_EXSETSEL > * Fixes bug 6814 > * Added more comprehensive conformance tests for EM_EXSETSEL > > editor.c | 52 +++++++++++++++++++++--- > tests/editor.c | 103 +++++++++++++++++++++++++++++++------------------ > 2 files changed, 112 insertions(+), 43 deletions(-) > > > > > > >

2 1

Re: tools/. mono.php
by Jonathan Ernst 04 Dec '06

04 Dec '06

Le vendredi 01 décembre 2006 à 10:35 -0600, Jeremy Newman a écrit : > ChangeSet ID: 30235 > CVSROOT: /opt/cvs-commit > Module name: tools > Changes by: jnewman(a)winehq.org 2006/12/01 10:35:01 > > Added files: > . : mono.php > > Log message: > Jonathan Ernst <jonathan(a)ernstfamily.ch> > - mono downloader script Please don't forget to upload the files to sourceforge as requested with the patches, because it is breaking those Wine downloads... See: http://source.winehq.org/mono.php?action=showlist http://source.winehq.org/mozactivex?action=showlist Thanks

3 2

Re: [ws2_32] make closesocket cancel pending I/O operations
by Kai Blin 04 Dec '06

04 Dec '06

On Monday 04 December 2006 07:01, Damjan Jovanovic wrote: > On Windows, calling closesocket in one thread causes blocking I/O > operations on that socket (select, accept) running in other threads to > return immediately. On Linux, the I/O will block forever. Calling > shutdown as part of closesocket reproduces the same behaviour under > Linux. Closes #4619 and #3777. Sweet, this seems to solve part of the problems in bug #5534, too. Thanks, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: ws2_32: Rewrite getsockopt to make it more readable.
by Kai Blin 04 Dec '06

04 Dec '06

On Sunday 03 December 2006 16:46, Kai Blin wrote: > --- > dlls/ws2_32/socket.c | 409 > ++++++++++++++++++++++++++++++++++------------ > dlls/ws2_32/tests/sock.c | 35 ++++ > 2 files changed, 332 insertions(+), 112 deletions(-) Sorry, misplaced a closing bracked somehow. I'll send a fixed version in a minute. Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Firefox-1.5.x on Wine slow on javascript-heavy pages
by Dan Kegel 04 Dec '06

04 Dec '06

I've been using Firefox-1.5.x again on wine (using the winehq packages for Ubuntu) on my dual 650MHz system as my main browser again for the last few months. It's working quite well... except that javascript-heavy pages/apps like gmail are a tad sluggish at accepting keyboard input. For some reason, yahoo.com's main page is also sluggish; they must do something fancy. Both are fine with native firefox on this system. I'm sure this won't affect anyone with a modern system, but it is kind of sad that my trusty old dual CPU system isn't up to daily tasks anymore. Sniff... ah, well, I see Fry's has amd64 4000 motherboard/cpu combos for $189, guess it's time to upgrade. At some point it'd be nice to look into why Firefox's javascript is slow under Wine, though. - Dan

2 1

Re: d3d [2]: Optional callback infrastructure for implicit texture surface destruction.
by Stefan Dösinger 03 Dec '06

03 Dec '06

Am Sonntag 03 Dezember 2006 21:52 schrieb Markus Amsler: > /* IWineD3DTexture */ > + IWineD3DTextureImpl_Destroy, Wouldn't it maybe be better to make the destroy method part of IWineD3DBase?

2 1

Re: d3d [2]: Optional callback infrastructure for implicit texture surface destruction.
by H. Verbeet 03 Dec '06

03 Dec '06

On 03/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > --- > dlls/wined3d/texture.c | 53 > +++++++++++++++++++++++--------------- > include/wine/wined3d_interface.h | 7 +++++ > 2 files changed, 39 insertions(+), 21 deletions(-) I think the callback should be non-optional.

2 1

One more go at fixing GetCursorPos()
by Vitaliy Margolen 03 Dec '06

03 Dec '06

Here is one more shot at fixing GetCursorPos() to make it usable in dinput. This time I used a refcount of sorts. Because the problem appears only during processing of hook chain. Just to remind about what is the problem: when hook handler calls GetCursorPos() position returned is the "old" position. While hook parameters contain "new" coordinates. This is on windows. On Wine returned position queried directly from X and might be even "newer" then position in hook parameters. Attached are two tests (out of lots more that I've used to find and fix the problem). test_msg.c - tests major problem that Alexandre pointed out about last fix attempt. Application in question does not process messages while calling GetCursorPos(). It still works properly with proposed patch. di_mouse_2th.c - 2 threads showing that there are no extra thread local position involved (if there is such a thing). Cached cursor position is global to all threads. (Last numbers should stay at dt(0 0) at all times). Inside hook handler d(x y) should show relative mouse move delta. If anyone has any objections, comment, suggestions, please do send them. Vitaliy Margolen. #define COBJMACROS #define _WIN32_WINNT 0x0501 #include <windows.h> #include <windowsx.h> #include <stdio.h> static HANDLE event1, event2; static HINSTANCE g_hInstance; static POINT pt_global; LRESULT CALLBACK hook_proc( int code, WPARAM wparam, LPARAM lparam ) { MSLLHOOKSTRUCT *hook = (MSLLHOOKSTRUCT *)lparam; POINT pt; GetCursorPos(&pt); if (code == HC_ACTION) { fprintf(stderr, "Hook: code=%d w=%x [(%ld %ld) %lx %lx %lx] cur(%ld %ld) d(%ld %ld) ", code, wparam, hook->pt.x, hook->pt.y, hook->mouseData, hook->flags, hook->dwExtraInfo, pt.x, pt.y, hook->pt.x - pt.x, hook->pt.y - pt.y); pt_global = pt; SetEvent(event1); WaitForSingleObject(event2, INFINITE); } return CallNextHookEx( 0, code, wparam, lparam ); } static DWORD CALLBACK thread_proc(LPVOID arg) { while (WaitForSingleObject(event1, INFINITE) == WAIT_OBJECT_0) { POINT pt; GetCursorPos(&pt); fprintf(stderr, "Th: (%ld %ld) dt(%ld %ld)\n", pt.x, pt.y, pt.x - pt_global.x, pt.y - pt_global.y); SetEvent(event2); } return 0; } static DWORD wnd_proc(void) { MSG msg; while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return msg.wParam; } #define SEND(x,y) \ i.mi.time = GetCurrentTime(); \ i.mi.dx = x; i.mi.dy = y; \ SendInput(1, &i, sizeof(INPUT)); void send_input(void) { INPUT i; POINT ptorg, pt; GetCursorPos(&ptorg); fprintf(stderr, "Cur pos: %ld %ld\n", ptorg.x, ptorg.y); i.type = INPUT_MOUSE; i.mi.dwFlags = MOUSEEVENTF_MOVE; i.mi.dwExtraInfo = 0; i.mi.mouseData = 0; SEND(-4, -4) GetCursorPos(&pt); fprintf(stderr, "%ld %ld\n", pt.x, pt.y); SetCursorPos(ptorg.x, ptorg.y); Sleep(250); fprintf(stderr, "***DONE***\n"); } void test1(HWND hwnd) { HANDLE thread; HHOOK hook; MSG msg; event1 = CreateEvent(NULL, FALSE, FALSE, NULL); event2 = CreateEvent(NULL, FALSE, FALSE, NULL); thread = CreateThread(NULL, 0, thread_proc, NULL, 0, NULL); Sleep(250); hook = SetWindowsHookExA(WH_MOUSE_LL, hook_proc, g_hInstance, 0); Sleep(250); // send_input(); wnd_proc(); while (PeekMessage( &msg, 0, 0, 0, PM_REMOVE )) DispatchMessage( &msg ); UnhookWindowsHookEx(hook); CloseHandle(event1); CloseHandle(event2); CloseHandle(thread); Sleep(250); } LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_DESTROY: PostQuitMessage(0); return 0; } return DefWindowProc(hWnd, message, wParam, lParam); } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { WNDCLASSEX wcex; HWND hwnd; g_hInstance = hInstance; wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS_HREDRAW | CS_VREDRAW; wcex.lpfnWndProc = (WNDPROC)WndProc; wcex.cbClsExtra = 0; wcex.cbWndExtra = 0; wcex.hInstance = hInstance; wcex.hIcon = NULL; wcex.hCursor = LoadCursor(NULL, IDC_ARROW); wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1); wcex.lpszMenuName = NULL; wcex.lpszClassName = "MainWindow"; wcex.hIconSm = NULL; RegisterClassEx(&wcex); hwnd = CreateWindow("MainWindow", "Title", WS_OVERLAPPEDWINDOW, 10, 10, 200, 200, NULL, NULL, NULL, NULL); ShowWindow(hwnd, SW_SHOW); test1(hwnd); DestroyWindow(hwnd); return 0; } #include <windows.h> #include <stdio.h> int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { LONG started = GetTickCount(); POINT pt, pt_org; HWND hwnd; MSG msg; hwnd = CreateWindow("static", "Title", WS_OVERLAPPEDWINDOW | WS_VISIBLE, 10, 10, 200, 200, NULL, NULL, NULL, NULL); GetCursorPos(&pt_org); while (PeekMessage( &msg, 0, 0, 0, PM_REMOVE )) DispatchMessage( &msg ); while (started + 10000 > GetTickCount()) { GetCursorPos(&pt); if ((pt.x - pt_org.x) || (pt.y - pt_org.y)) printf("(%ld %ld)\n", pt.x - pt_org.x, pt.y - pt_org.y); pt_org = pt; } DestroyWindow(hwnd); return 0; }

2 2

winedump: Cast-qual warnings fix (2 of 2)
by Andrew Talbot 03 Dec '06

03 Dec '06

Sorry, I made a mess of titling this patch, twice. Please find and use the version whose subject line and changelog entry refer to "winedump", not "winedbg". Thanks, -- Andy.

1 0