November 2015 - Wine-devel - list.winehq.org

Re: user32: Test layered window focus
by Marvin 11 Nov '15

11 Nov '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=18123 Your paranoid android. === w8 (32 bit win) === win.c:3467: Test failed: hwnd 00030196 message 0118 === w864 (32 bit win) === win.c:3467: Test failed: hwnd 0003019E message 0118 === w1064 (32 bit win) === win.c:6718: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6740: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6718: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6718: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6718: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6718: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6718: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6740: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6718: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6740: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

2 1

Re: server: Only send WM_WINE_CLIPCURSOR for forced clip resets. (resend)
by Ken Thomases 11 Nov '15

11 Nov '15

On Nov 10, 2015, at 10:30 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > > It would be nice if someone familiar with winemac.drv could confirm/test that > removing the duplicate notification doesn't break anything. It shouldn't break anything. The Mac driver works very differently from the X11 driver in this area. Cursor clipping isn't closely related to the delivery of relative mouse movement events. There's nothing like grabbing the pointer or the use of an extra window, etc. Also, the desktop owner doesn't ever present a window (no virtual desktop mode support, yet), so it's never the active Mac process. So, calls or lack of calls to macdrv_ClipCursor() in that process make no difference. All of that said, it seems the problem is specific to the X11 driver and the solution should probably be restricted to there, too. No matter what thread or process receives WM_WINE_CLIPCURSOR, it gets the cursor clipping rectangle and (re)establishes that via the driver. The driver should never do the wrong thing when it receives a request that's appropriate to the current state. The fact that cursor clipping and relative mouse movements are closely intertwined is an artifact of X11. If grab_clipping_window() is going to be used for both, then the X11 driver has to take care not to call ungrab_clipping_window() just because one of those two needs is not currently in effect. -Ken

2 1

Re: [PATCH] mshtml: Make it clear that ATTR_FIX_PX and ATTR_FIX_URL as exclusive (Coverity)
by Jacek Caban 11 Nov '15

11 Nov '15

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> On 11/10/15 20:31, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > Otherwise first allocated val is leaked. Jacek, can you confirm? Well, I don't think this causes a real leak because even if we try to apply both fixups, the attribute would need to be URL and integer at the same time for the leak to happen. However, I don't think there are attributes that could require both fixups, so I'm fine with the patch. Thanks, Jacek

1 0

Re: [resend] dbghelp: Crash fix in module_find_cb on trying to parse non image files.
by Marcus Meissner 11 Nov '15

11 Nov '15

Hi, Patch looks good to me. (doing it in the nested style of this if () if () if() nesting is probably not needed) Ciao, Marcus On Tue, Nov 10, 2015 at 07:22:03PM +0100, Ralf Habacker wrote: > > Bug: https://bugs.winehq.org/show_bug.cgi?id=39568 > > Signed-off-by: Ralf Habacker <ralf.habacker(a)freenet.de> Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/dbghelp/path.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > > diff --git a/dlls/dbghelp/path.c b/dlls/dbghelp/path.c > index a0e51bd..8c74426 100644 > --- a/dlls/dbghelp/path.c > +++ b/dlls/dbghelp/path.c > @@ -490,7 +490,13 @@ static BOOL CALLBACK module_find_cb(PCWSTR buffer, PVOID user) > if ((mapping = MapViewOfFile(hMap, FILE_MAP_READ, 0, 0, 0)) != NULL) > { > IMAGE_NT_HEADERS* nth = RtlImageNtHeader(mapping); > - > + if (!nth) > + { > + UnmapViewOfFile(mapping); > + CloseHandle(hMap); > + CloseHandle(hFile); > + return FALSE; > + } > matched++; > timestamp = nth->FileHeader.TimeDateStamp; > size = nth->OptionalHeader.SizeOfImage; > >

1 0

Re: [PATCH 1/2] wininet: Free Critical Section (valrind)
by Marvin 10 Nov '15

10 Nov '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=18101 Your paranoid android. === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2408: Test failed: count was wrong http.c:2409: Test failed: http data wrong, got: Garbage: Header http.c:3072: Test failed: HttpAddRequestHeaders succeeded http.c:3073: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3078: Test failed: code = 200, expected 400 http.c:3078: Test failed: code = 200, expected 400 http.c:3078: Test failed: unexpected status code 200, expected 400 http.c:3078: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

2 1

Re: [2/2] server: Allow multiple registry notifications per key.
by Sebastian Lackner 10 Nov '15

10 Nov '15

On 10.11.2015 23:01, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > After this patch there are still a couple of remaining problems: [...] > * The WatchSubtree Flag and the filters parameter should be stored somewhere in the > key object itself? It seems like its not possible to change it anymore after > the first notification. I just saw that this was already working fine in the old implementation, which means my patch could cause regressions. :( Please ignore this patch for now. I'll resend 1/2 alone with some more tests.

1 0

Re: ntoskrnl.exe: add CmRegisterCallback/CmUnRegisterCallback stub (5/8)
by Sebastian Lackner 10 Nov '15

10 Nov '15

On 09.11.2015 06:59, Austin English wrote: > +/*********************************************************************** > + * CmRegisterCallback (NTOSKRNL.EXE.@) > + */ > +NTSTATUS CmRegisterCallback(EX_CALLBACK_FUNCTION *function, void *context, LARGE_INTEGER *cookie) You forgot to specify the calling convention. The function should be declared as WINAPI. > +{ > + FIXME("(%p %p %p): stub\n", function, context, cookie); > + return STATUS_NOT_IMPLEMENTED; > +} > + > +/*********************************************************************** > + * CmUnRegisterCallback (NTOSKRNL.EXE.@) > + */ > +NTSTATUS CmUnRegisterCallback(LARGE_INTEGER cookie) Same here. > +{ > + FIXME("%d): stub\n", cookie.u.LowPart); There is a "(" missing at the beginning of the FIXME. Also, I think it would be useful to print the whole value. Either something like: FIXME("(%x%08x): stub\n", cookie.u.HighPart, cookie.u.LowPart); or use wine_dbgstr_longlong: FIXME("(%s): stub\n", wine_dbgstr_longlong(cookie.QuadPart)); > + return STATUS_NOT_IMPLEMENTED; > +}

1 0

Re: ntoskrnl.exe: add RtlInitializeGenericTableAvl/RtlInsertElementGenericTableAvl stubs (resend) (1/8)
by Sebastian Lackner 10 Nov '15

10 Nov '15

On 09.11.2015 06:55, Austin English wrote: > From 8ddf8d4bbdaf8a84b73740495d93035f18a15d20 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Sun, 8 Nov 2015 23:22:31 -0600 > Subject: [PATCH 1/8] ntoskrnl.exe: add > RtlInitializeGenericTableAvl/RtlInsertElementGenericTableAvl stubs (resend) > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/ntdll/ntdll.spec | 4 +-- > dlls/ntdll/rtl.c | 16 +++++++++++ > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 4 +-- > include/ddk/ntddk.h | 55 ++++++++++++++++++++++++++++++++++++- > 4 files changed, 74 insertions(+), 5 deletions(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index 464b233..f9b31ff 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -683,7 +683,7 @@ > @ stdcall RtlInitializeCriticalSectionAndSpinCount(ptr long) > @ stdcall RtlInitializeCriticalSectionEx(ptr long long) > @ stdcall RtlInitializeGenericTable(ptr ptr ptr ptr ptr) > -# @ stub RtlInitializeGenericTableAvl > +@ stdcall RtlInitializeGenericTableAvl(ptr ptr ptr ptr ptr) > @ stdcall RtlInitializeHandleTable(long long ptr) > @ stub RtlInitializeRXact > # @ stub RtlInitializeRangeList > @@ -693,7 +693,7 @@ > @ stdcall RtlInitializeSid(ptr ptr long) > # @ stub RtlInitializeStackTraceDataBase > @ stub RtlInsertElementGenericTable > -# @ stub RtlInsertElementGenericTableAvl > +@ stdcall RtlInsertElementGenericTableAvl(ptr ptr long ptr) > @ cdecl -arch=x86_64 RtlInstallFunctionTableCallback(long long long ptr ptr wstr) > @ stdcall RtlInt64ToUnicodeString(int64 long ptr) > @ stdcall RtlIntegerToChar(long long long ptr) > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index 8eb3e9f..0ca27c2 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -1595,3 +1595,19 @@ void WINAPI RtlGetCurrentProcessorNumberEx(PROCESSOR_NUMBER *processor) > processor->Number = NtGetCurrentProcessorNumber(); > processor->Reserved = 0; > } > + > +/*********************************************************************** > + * RtlInitializeGenericTableAvl (NTOSKRNL.EXE.@) Your implementation is in NTDLL, so it would be better to write that in the comment above. > + */ > +void WINAPI RtlInitializeGenericTableAvl(void *table, void *compare, void *allocate, void *free, void *context) According to MSDN all those parameters are documented. You also added them to the include below, why do you not use them here? We'll need them anyway sooner or later, when someone is going to implement them. > +{ > + FIXME("%p %p %p %p %p: stub\n", table, compare, allocate, free, context); > +} > + > +/*********************************************************************** > + * RtlInsertElementGenericTableAvl (NTOSKRNL.EXE.@) NTOSKRNL -> NTDLL, as above. > + */ > +void WINAPI RtlInsertElementGenericTableAvl(void *table, void *buffer, long size, BOOL *element) I would also recommend to use the real types here. Especially "long" should be avoided because it has a different size depending on the architecture. The correct type for the third parameter seems to be CLONG = ULONG. > +{ > + FIXME("%p %p %lu %p: stub\n", table, buffer, size, element); After fixing the types above, you'll have to replace %lu -> %u. > +} > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > index 1957a9a..7690268 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -1055,12 +1055,12 @@ > @ stdcall RtlInitUnicodeString(ptr wstr) ntdll.RtlInitUnicodeString > @ stdcall RtlInitializeBitMap(ptr long long) ntdll.RtlInitializeBitMap > @ stdcall RtlInitializeGenericTable(ptr ptr ptr ptr ptr) ntdll.RtlInitializeGenericTable > -@ stub RtlInitializeGenericTableAvl > +@ stdcall RtlInitializeGenericTableAvl(ptr ptr ptr ptr ptr) ntdll.RtlInitializeGenericTableAvl > @ stub RtlInitializeRangeList > @ stdcall RtlInitializeSid(ptr ptr long) ntdll.RtlInitializeSid > @ stub RtlInitializeUnicodePrefix > @ stub RtlInsertElementGenericTable > -@ stub RtlInsertElementGenericTableAvl > +@ stdcall RtlInsertElementGenericTableAvl(ptr ptr long ptr) ntdll.RtlInsertElementGenericTableAvl > @ stub RtlInsertElementGenericTableFull > @ stub RtlInsertElementGenericTableFullAvl > @ stub RtlInsertUnicodePrefix > diff --git a/include/ddk/ntddk.h b/include/ddk/ntddk.h > index bccfd39..6f656a3 100644 > --- a/include/ddk/ntddk.h > +++ b/include/ddk/ntddk.h > @@ -149,6 +149,59 @@ typedef struct _KWAIT_BLOCK { > USHORT WaitType; > } KWAIT_BLOCK, *PKWAIT_BLOCK, *RESTRICTED_POINTER PRKWAIT_BLOCK; > > +typedef struct _RTL_BALANCED_LINKS { > + struct _RTL_BALANCED_LINKS *parent; > + struct _RTL_BALANCED_LINKS *left_child; > + struct _RTL_BALANCED_LINKS *right_child; > + CHAR balance; > + UCHAR reserved[3]; > +} RTL_BALANCED_LINKS; > +typedef RTL_BALANCED_LINKS *PRTL_BALANCED_LINKS; Not sure which headers you are using, but basically all of the information I found says those struct members should be called "Parent", "LeftChild", "RightChild", and so on. Did you rename them? Please note that this doesn't work, the header files should be compatible with Windows. > + > +struct _RTL_AVL_TABLE; > + > +typedef enum _RTL_GENERIC_COMPARE_RESULTS { > + generic_less_than, > + generic_greater_than, > + generic_qual > +} RTL_GENERIC_COMPARE_RESULTS; Same here, it should probably be "GenericLessThan", "GenericGreaterThan", and so on. > + > +RTL_GENERIC_COMPARE_RESULTS WINAPI RTL_AVL_COMPARE_ROUTINE ( > + struct _RTL_AVL_TABLE *table, > + void *struct1, > + void *struct2 > +); There is no need to keep the formatting the same. Something like: RTL_GENERIC_COMPARE_RESULTS WINAPI RTL_AVL_COMPARE_ROUTINE(struct _RTL_AVL_TABLE *, void *, void *); Would also work, for example. You could even merge it with the line below: typedef RTL_GENERIC_COMPARE_RESULTS (WINAPI *PRTL_AVL_COMPARE_ROUTINE)(struct _RTL_AVL_TABLE *, void *, void *); > + > +typedef enum RTL_AVL_COMPARE_ROUTINE *PRTL_AVL_COMPARE_ROUTINE; RTL_AVL_COMPARE_ROUTINE is not an enumeration. > + > +void WINAPI RTL_AVL_ALLOCATE_ROUTINE ( > + struct _RTL_AVL_TABLE *table, > + LONG size > +); > + > +typedef enum RTL_AVL_ALLOCATE_ROUTINE *PRTL_AVL_ALLOCATE_ROUTINE; > + > +void WINAPI RTL_AVL_FREE_ROUTINE ( > + struct _RTL_AVL_TABLE *table, > + void *buffer > +); > + > +typedef enum RTL_AVL_FREE_ROUTINE *PRTL_AVL_FREE_ROUTINE; > + > +typedef struct _RTL_AVL_TABLE { > + RTL_BALANCED_LINKS balanced_root; > + void *ordered_pointer; > + ULONG which_ordered_element; > + ULONG number_generic_table_elements; > + ULONG tree_depth; > + PRTL_BALANCED_LINKS restart_key; > + ULONG delete_count; > + PRTL_AVL_COMPARE_ROUTINE compare_routine; > + PRTL_AVL_ALLOCATE_ROUTINE allocate_routine; > + PRTL_AVL_FREE_ROUTINE free_routine; > + void *table_context; > +} RTL_AVL_TABLE, *PRTL_AVL_TABLE; The struct members of RTL_AVL_TABLE also don't match my header files. > + > typedef VOID (WINAPI *PDRIVER_NOTIFICATION_CALLBACK_ROUTINE)(PVOID,PVOID); > typedef VOID (WINAPI *PDRIVER_REINITIALIZE)(PDRIVER_OBJECT,PVOID,ULONG); > typedef VOID (WINAPI *PLOAD_IMAGE_NOTIFY_ROUTINE)(PUNICODE_STRING,HANDLE,PIMAGE_INFO); > @@ -160,5 +213,5 @@ NTSTATUS WINAPI IoQueryDeviceDescription(PINTERFACE_TYPE,PULONG,PCONFIGURATION_ > void WINAPI IoRegisterDriverReinitialization(PDRIVER_OBJECT,PDRIVER_REINITIALIZE,PVOID); > NTSTATUS WINAPI IoRegisterShutdownNotification(PDEVICE_OBJECT); > NTSTATUS WINAPI PsSetLoadImageNotifyRoutine(PLOAD_IMAGE_NOTIFY_ROUTINE); > - > +void WINAPI RtlInitializeGenericTableAvl(PRTL_AVL_TABLE, PRTL_AVL_COMPARE_ROUTINE, PRTL_AVL_ALLOCATE_ROUTINE, PRTL_AVL_FREE_ROUTINE, VOID *); Is there any reason why you only add one of both functions? > #endif > -- 2.6.2 > BTW: You could also think about moving all those definitions to winternl.h. It already contains definitions for many other Rtl* functions, and those AVL tree functions are probably also useful for other parts of Wine, in the long term - not just for ntoskrnl.

1 0

Re: [PATCH] hnetcfg: Add Dispatch support to interface INetFwOpenPort
by Nikolay Sivov 10 Nov '15

10 Nov '15

This looks fine to me, it applies on current git. One thing that is wrong is subject - it should say INetFwOpenPorts.

1 0

Attention packagers: New optional dependency on libpulse
by Andrew Eikum 10 Nov '15

10 Nov '15

As you may have noticed, Wine recently integrated the PulseAudio audio backend. This obviously introduces a dependency on libpulse, in 32- and/or 64-bit forms depending on what you're building. Building winepulse will be enabled at configure-time if libpulse is present, otherwise winepulse will not be built. If PulseAudio is not running, or libpulse is not installed, Wine will fall back on another driver. Thanks, Andrew

1 0