wine-devel July 2008

wine-devel@winehq.org

135 participants
411 discussions

Re: user32: sizeof DDEPOKE and DDEDATA is six, which is probably not what is expected, so use offsetof instead.
by James Hawkins 08 Jul '08

08 Jul '08

2008/7/8 Huw Davies <huw(a)codeweavers.com>: > > Fixes a todo_wine and a Valgrind warning. @@ -699,10 +699,7 @@ static HDDEDATA CALLBACK server_ddeml_callback(UINT uType, UINT uFmt, HCONV hcon ptr = (LPSTR)DdeAccessData(hdata, &size); ok(!lstrcmpA(ptr, "poke data\r\n"), "Expected 'poke data\\r\\n', got %s\n", ptr); - todo_wine - { - ok(size == 14, "Expected 14, got %d\n", size); - } + ok(size == 12, "Expected 12, got %d\n", size); DdeUnaccessData(hdata); size = DdeQueryStringA(server_pid, hsz2, str, MAX_PATH, CP_WINANSI); You changed the value of the test. Did you mean to do that? -- James Hawkins

2 2

Re: bug 14357: undefined edge padding in bitmaps annoys valgrind
by James Hawkins 08 Jul '08

08 Jul '08

On Tue, Jul 8, 2008 at 12:59 PM, John Reiser <jreiser(a)bitwagon.com> wrote: > Attached is the patch for http://bugs.winehq.org/show_bug.cgi?id=14357 > undefined edge padding in bitmaps annoys valgrind > + memset(image->data, 0, image->bytes_per_line * height); /* valgrind */ I don't think we should add comments like this. The reason for fixing it is because some logic could potentially depend on an undefined value, which valgrind handily warns us about. -- James Hawkins

1 0

programs: add rudimentary dxdiag
by Louis. Lenders 08 Jul '08

08 Jul '08

Hi, any comments on this one? btw, is there a reason i never ever receive any comments on my patches when they are rejected? If so, please tell me, that'll save me a lot of time of sending them in... ----- Forwarded Message ---- From: Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> To: wine-patches(a)winehq.org Sent: Thursday, 26 June, 2008 3:20:04 AM Subject: Re: programs: add rudimentary dxdiag Hi, some apps like Gameshadow (http://www.gameshadow.com/) check for dxdiag.exe, and give an error if it's not found, so wine needs its own. Instead of simple stub, this patch also adds the (simplified) d3d test like seen in native dxdiag, so users can test if their d3d is setup correctly. Screenshot can be seen here: http://bugs.winehq.org/attachment.cgi?id=14342 A few remarks: -patch contains binary code for a bitmap, so to apply again i had to do git apply dx.patch git add programs/dxdiag/ tools/make_makefiles autoconf maybe there's a simpler way, but i dunno - code for spinning cube was partially based on spinning cube code scattered all over the internet -rest was ripped of winecfg - There' s a problem while minizing the d3d-window, but running it in wine-0.9.22 it all goes fine, so this must be a regression somewhere, and not a bug in the attached code. I'll go after that later. - Hopefully you're not to picky on this patch, it 's quite some line's of code,and i'm sure things need to be improved, but this does not affect wine's core code but os rather an enhancement, and it 's not really possible to send it in in small chuncks. ________________________________ Not happy with your email address? Get the one you really want - millions of new email addresses available now at Yahoo! __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

8 15

Lots of input messages lingering in server slowing down wine tremendously?
by Alexander Dorofeyev 08 Jul '08

08 Jul '08

Hi. There was a problem found recently in a fan-made mod of Forsaken (game), that certain input combinations were slowing wine very seriously. Holding down a keyboard button and moving mouse was found to be especially devastating to performance (200 fps to 10fps in a matter of 10-20 seconds). With help from people who develop this mod, I was able to isolate it in a very small and simplistic testcase, which shows this same problem. It will be included as attachment. Holding a key and moving mouse over the window steadily increases main loop latency from 10 to 50 (and even 100) in a short time, especially so if quickly clicking both mouse buttons as well. In a game this means going from 100 fps to 20 or 10 just because of input messages. Has to be noted that in the actual game the rate of slowdown seemed at least 2-3 times faster for reasons I don't know, but the testcase still should enough to show the problem. Now, I do realize that what the testcase is doing is bad practice, it's basically refusing to process certain types of messages, and PeekMessage just once during a loop is probably bad as well, but that's what the game was originally doing in its main game loop. They do plan to fix it in the game. Still, there are several concerns about it: 1) No slowdown happens of Windows as far as I can tell. No matter how much I move the mouse holding key and clicking madly, it shows same stable 15-16 ticks latency in the testcase. I don't know what it does, but somehow it handles this situation better than Wine. 2) Can this (broken) way of doing things be exposing some inefficiency in message handling, maybe something that could use optimization? I tried to put debug hacks into queue_hardware_message(), it seems that when slowdown is already VERY bad in Forsaken (10fps), message queue in wine server has about 400 or maybe 600 messages. Is that kind of processing overhead per message inevitable? (This is happening on AMD Athlon(tm) 3200+). Perhaps somebody who knows that part of code well may be interested in looking into performance issues in this case. Because, if 400-600 messages in the queue slow down the application to a crawl, then who knows, perhaps it decreases performance of more well-behaved but input-intensive apps as well, just less drastically (holding one or several keys to move, all the while aiming with mouse and abusing mouse buttons is a common thing in games, so there can be quite a few input messages flooding the server). The reason I decided to post it to wine-devel is because I'm not sure if this kind of thing is expected and unavoidable or a bug that can be fixed, so better to hear some comments first, then a bug entry can be opened if needed. #include <windows.h> HWND window; int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { WNDCLASS wc = {0}; MSG msg; DWORD ticks, ticks2; HHOOK kbd_hook, mouse_hook; wc.lpfnWndProc = &DefWindowProc; wc.lpszClassName = "testwc"; RegisterClass(&wc); window = CreateWindow("testwc", "test", WS_OVERLAPPED | WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0); ticks = GetTickCount(); for (;;) { if (PeekMessage(&msg, NULL, WM_NULL, WM_KEYFIRST, PM_REMOVE)) { if (msg.message == WM_QUIT) { DestroyWindow(window); break; } TranslateMessage(&msg); DispatchMessage(&msg); } //simulated work ticks2 = GetTickCount(); for (;;) { UINT i; volatile int dummy = 1; for (; i < 10000 && dummy; i++) ; if (GetTickCount() - ticks2 >= 10) break; } printf("main loop %u tick latency\n", GetTickCount() - ticks); ticks = GetTickCount(); } }

2 1

Re: services: when displayname is absent, the keyname should be used when searching by displayname (fixes bug #13958)
by Alexandre Julliard 08 Jul '08

08 Jul '08

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > diff --git a/programs/services/services.c b/programs/services/services.c > index 36ed117..b166d51 100644 > --- a/programs/services/services.c > +++ b/programs/services/services.c > @@ -344,7 +344,7 @@ struct service_entry *scmdatabase_find_service_by_displayname(struct scmdatabase > > LIST_FOR_EACH_ENTRY(service, &db->services, struct service_entry, entry) > { > - if (strcmpiW(name, service->config.lpDisplayName) == 0) > + if (strcmpiW(name, get_display_name(service)) == 0) > return service; > } You should not change scmdatabase_find_service_by_displayname, it does what its name implies. You should fix the callers where necessary. -- Alexandre Julliard julliard(a)winehq.org

2 1

mscoree:GetCORSystemDirectory. Need advice
by Vitaly Perov 08 Jul '08

08 Jul '08

Hi! I hame implemented mscoree:GetCORSystemDirectory function. (Patch included) It find a folder of the latest .Net installation in the registry. So there are several problems: 1) Registry entry doesn't exist. I don't know how to add it correctly. Now I import it from the Windows registry by regedit. 2) The folder of .Net installation doesn't exist. So, does somebody know how to solve these problems? Thank you! -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

1 1

[1/3] [d3d8] Add testcase for IDirect3DDevice8::CreateImageSurface
by Tobias Jakobi 08 Jul '08

08 Jul '08

Posted a alternate version of the patchset to wine-patches, now using todo_wine and activating the testcase in the first patch. Patch no. 3 didn't change though, but I reposted it anyway. Greets, Tobias

1 0

Re: [1/3] [d3d8] Add testcase for IDirect3DDevice8::CreateImageSurface (correct)
by H. Verbeet 08 Jul '08

08 Jul '08

Looks ok to me.

1 0

Re: riched20: Fix typo.
by Michael Stefaniuc 08 Jul '08

08 Jul '08

Dylan Smith wrote: > Yes, that is right. > > Thanks for catching that. > > By the way, should I be replying to wine-devel? Or should I only be doing > that if something is wrong with the patch so that Julliard can ignore it? This should do. thanks bye michael > On Tue, Jul 8, 2008 at 8:05 AM, Michael Stefaniuc <mstefani(a)redhat.com> > wrote: > >> This fixes a warning introduced by 69cf4e9a : >> dlls/riched20/editor.c:1647: warning: 'clickMsg.pt.y' is used uninitialized >> in this function >> >> >> --- >> Dylan, please confirm that I have replaced the right 'x'. >> >> >> dlls/riched20/editor.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c >> index 7e90096..c285733 100644 >> --- a/dlls/riched20/editor.c >> +++ b/dlls/riched20/editor.c >> @@ -1643,7 +1643,7 @@ static int ME_CalculateClickCount(HWND hWnd, UINT >> msg, WPARAM wParam, >> clickMsg.lParam = lParam; >> clickMsg.time = GetMessageTime(); >> clickMsg.pt.x = LOWORD(lParam); >> - clickMsg.pt.x = HIWORD(lParam); >> + clickMsg.pt.y = HIWORD(lParam); >> if ((clickNum != 0) && >> (clickMsg.message == prevClickMsg.message) && >> (clickMsg.hwnd == prevClickMsg.hwnd) && >> -- >> 1.5.6.2 >> > -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei Muenchen Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

1 0

Re: ws2_32: Partial implementation of TransmitFile/TransmitPackets
by Alexandre Julliard 08 Jul '08

08 Jul '08

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > + while (send_len) > + { > + wsabuf.len = send_len; > + if (wsabuf.len > chunk_len) > + wsabuf.len = chunk_len; > + if (!ReadFile(packet->u.s.hFile, wsabuf.buf, wsabuf.len, NULL, NULL) || > + WSASendTo(s, &wsabuf, 1, &n, 0, NULL, 0, NULL, NULL) == SOCKET_ERROR) > + goto TransmitPackets_fail; Both ReadFile and WSASendTo will return the number of bytes read/written, you need to take that into account. > + if (WSASendTo(s, &wsabuf, 1, &n, 0, NULL, 0, NULL, NULL) == SOCKET_ERROR) > + goto TransmitPackets_fail; > + send_len -= wsabuf.len; > + wsabuf.buf += wsabuf.len; Same here. > + packet->cLength = total_len; > + /* FIXME: I'm not certain we should always use the current file > + * position (rather than the start of the file), though it works > + * for mapache.exe. > + */ Some test cases would be a good idea. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
29
30
31
32
33
34
35
...
42
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2008