July 2008 - Wine-Devel - list.winehq.org

Re: dlls/ws2_32/tests/sock.c: Wait on thread handles before closing sockets
by Alexandre Julliard July 17, 2008

July 17, 2008

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > In the socket tests, avoid a race by waiting for the read threads to > finish before closing the sockets (found during TransmitFile testing). CloseHandle doesn't wait for the thread to finish, so this has no effect. In any case there doesn't seem to be any need to wait in those tests. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/3] mstask: TaskScheduler stub with AddRef, QueryInterface, and Release
by Roy Shea July 17, 2008

July 17, 2008

Broken patch set :( Please disregard this sequence (1-3) of patches. I'll send a revised version out later today. Peace, -Roy On Thu, Jul 17, 2008 at 1:37 PM, Roy Shea <royshea(a)gmail.com> wrote: > --- > dlls/mstask/Makefile.in | 2 + > dlls/mstask/mstask_main.c | 5 +- > dlls/mstask/mstask_private.h | 39 ++++++++++ > dlls/mstask/task_scheduler.c | 167 ++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 209 insertions(+), 4 deletions(-) > create mode 100644 dlls/mstask/mstask_private.h > create mode 100644 dlls/mstask/task_scheduler.c >

1 0

Re: user32: fix create_window_handle to create Ansi Edit after SetClassLongPtrW
by Vitaliy Margolen July 17, 2008

July 17, 2008

Hongbo Ni wrote: > --=====================_35969977==.ALT > Content-Type: text/html; charset="us-ascii" > > > <html> > <body> > > This patch fixes Bug#14350 > CreateWindowA("Edit"...) should create an Ansi window even > after the builtin > Edit class has been subclassed by > SetClassLongPtrW(hEdit,GCLP_WNDPROC,procW). > This bug applies to all builtin classes, but only Edit needs to be > fixed > since in other builtin classes, user can not change the text in the > control. > A->W->A conversion will get same string back. Edit is special since > user > interact with it. > --- > Please do not send patches in HTML format. Plain text only. Vitaliy

1 0

re: advapi32: "RegGetValue" fails with some correct combinations of "dwFlags"
by Dan Kegel July 17, 2008

July 17, 2008

Mathias Kosch wrote: > ... > The patch and test case were created against wine-1.1.1 and are both > attached to this mail. > > I hope this time I provided enough information You forgot to mention which versions of Windows you ran the test case on (and whether it passed there). - Dan

1 0

Re: [PATCH 05/10][try 2] quartz/tests: Fix interface leaks in aggregation test.
by Michael Karcher July 17, 2008

July 17, 2008

Am Donnerstag, den 17.07.2008, 20:24 +0300 schrieb Alexander Dorofeyev: > + do > + { > + hr = IUnknown_Release(pUnkInner); > + } while (hr); Release returns a ULONG, not a HRESULT. Do we ignore the difference in Wine? Regards, Michael Karcher

2 1

Uninitialized memory reference in winefile
by Dan Kegel July 17, 2008

July 17, 2008

While valgrinding Picasa, I came across the following valgrind error in winefile. (My daily valgrind runs only run the conformance suite, which is why I've never seen this before.) The lines involved seem unchanged since Martin Fuchs' winefile code was merged back in 2002. Conditional jump or move depends on uninitialised value(s) at calc_widths (winefile.c:2711) by create_tree_window (winefile.c:2974) by InitChildWindow (winefile.c:2984) by ChildWndProc (winefile.c:4259) by ??? (library.h:136) by call_window_proc (winproc.c:457) by WINPROC_call_window (winproc.c:2198) by call_window_proc (message.c:1610) by send_message (message.c:2434) by SendMessageW (message.c:2557) by WIN_CreateWindowEx (win.c:1164) by CreateWindowExW (win.c:1362) by MDIClientWndProc_common (mdi.c:1140) by MDIClientWndProcW (mdi.c:1307) by ??? (library.h:136) by call_window_proc (winproc.c:457) by WINPROC_call_window (winproc.c:2198) by call_window_proc (message.c:1610) by send_message (message.c:2434) by SendMessageW (message.c:2557) by create_child_window (winefile.c:1789) by show_frame (winefile.c:4839) by winefile_main (winefile.c:4931) by WinMain (winefile.c:4965) by main (exe_main.c:48) Uninitialised value was created by a stack allocation at calc_widths (winefile.c:2645)

3 2

Re: [10/10] [try 4] appwiz.cpl: Gather extra information for Support Info dialog
by Juan Lang July 17, 2008

July 17, 2008

Hi Owen, this one's another line-limit buster. I won't quote the lines in this one, as most of it is too long. --Juan

1 0

Re: [9/10] [try 4] appwiz.cpl: Add basic Support Information dialog
by Juan Lang July 17, 2008

July 17, 2008

Hi Owen, this one's another long-liner: + if (GetWindowTextW(GetDlgItem(hWnd, IDC_INFO_LABEL), oldtitle, MAX_STRING_LEN) != 0) + DialogBoxParamW(hInst, MAKEINTRESOURCEW(IDD_INFO), hWnd, (DLGPROC) SupportInfoDlgProc, + selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, + if (SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETITEMW, 0, (LPARAM) &lvItem)) Please set your editor window to be rather narrower. --Juan

1 0

Re: [6/10] [try 4] appwiz.cpl: Read installed application information from registry
by Juan Lang July 17, 2008

July 17, 2008

Hi Owen, this patch goes rather over the suggested line length limit of 80. Offending lines: + if (RegOpenKeyExW(root, PathUninstallW, 0, KEY_READ, &hkeyUninst) != ERROR_SUCCESS) + for (i = 0; RegEnumKeyExW(hkeyUninst, i, subKeyName, &sizeOfSubKeyName, NULL, NULL, NULL, NULL) != ERROR_NO_MORE_ITEMS; ++i) + if ((RegQueryValueExW(hkeyApp, DisplayNameW, 0, 0, NULL, &displen) == ERROR_SUCCESS) + && (RegQueryValueExW(hkeyApp, UninstallCommandlineW, 0, 0, NULL, &uninstlen) == ERROR_SUCCESS)) + RegQueryValueExW(hkeyApp, DisplayNameW, 0, 0, (LPBYTE)iter->title, &displen); + RegQueryValueExW(hkeyApp, DisplayIconW, 0, 0, (LPBYTE)iter->icon, &displen); + RegQueryValueExW(hkeyApp, UninstallCommandlineW, 0, 0, (LPBYTE)iter->path, &uninstlen); + if (RegQueryValueExW(hkeyApp, PublisherW, 0, 0, NULL, &displen) == ERROR_SUCCESS) + RegQueryValueExW(hkeyApp, PublisherW, 0, 0, (LPBYTE)iter->publisher, &displen); + if (RegQueryValueExW(hkeyApp, DisplayVersionW, 0, 0, NULL, &displen) == ERROR_SUCCESS) + RegQueryValueExW(hkeyApp, DisplayVersionW, 0, 0, (LPBYTE)iter->version, &displen); + /* reset the list, since it's probably changed if the uninstallation was successful */ Also, + + case WM_COMMAND: + switch (LOWORD(wParam)) + { + case IDC_INSTALL: + FIXME("Installer not implemented."); + break; + } + + break; This doesn't appear to have anything to do with the subject of the patch. In fact it's never used in this patch set, so you should just omit it. --Juan

1 0

Re: [3/10] [try 4] appwiz.cpl: Add column headers to listview
by Juan Lang July 17, 2008

July 17, 2008

Hi Owen, + IDS_COLUMN_TITLE_1, "Name" + IDS_COLUMN_TITLE_2, "Publisher" + IDS_COLUMN_TITLE_3, "Version" These seem like rather poor names for the string IDs. Why not e.g. IDS_COLUMN_NAME or simply IDS_NAME? +/* Definition of column headers for AddListViewColumns function */ +#define NUM_COLUMNS 3 I don't think you need a separate symbolic constant for this, as.. +AppWizColumn columns[NUM_COLUMNS] = { this can be replaced with: +AppWizColumn columns[] = { and this: + /* Add the columns */ + for (i = 0; i < NUM_COLUMNS; i++) can be replaced with: + for (i = 0; i < sizeof(columns) / sizeof(columns[0]; i++) #define IDS_CPL_TITLE 1 #define IDS_CPL_DESC 2 #define IDS_TAB1_TITLE 3 +#define IDS_COLUMN_TITLE_1 6 +#define IDS_COLUMN_TITLE_2 7 +#define IDS_COLUMN_TITLE_3 8 See above for the comment on the choice of names. What happened to items 4 and 5? --Juan

1 0