- wine-devel - winehq.org

Re: [PATCH] olepro32: Add typelib resource (resend)
by Huw Davies 25 Jan '16

25 Jan '16

On Thu, Jan 07, 2016 at 06:15:52PM +1100, Alistair Leslie-Hughes wrote: > diff --git a/dlls/olepro32/olepro.idl b/dlls/olepro32/olepro.idl > new file mode 100644 > index 0000000..a34822d > --- /dev/null > +++ b/dlls/olepro32/olepro.idl > @@ -0,0 +1,358 @@ > +/* > + * Copyright (C) 2015 Alistair Leslie-Hughes > + * This appears to be a stripped down copy of std_ole_v1.idl, which is fine; what's not fine is stripping out the copyright and replacing it with your own. What should happen here is that this typelib should importlib("stdole32.tlb") and not have the IUnknown or IDispatch definitions. This will mean adding stdole32.tlb to the include directory. Huw.

1 0

Re: [PATCH 1/2] user32: Use correct values to deselect combo box text with EM_SETSEL
by Dmitry Timoshkov 25 Jan '16

25 Jan '16

Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/user32/combo.c | 2 ++ > dlls/user32/tests/combo.c | 4 ++-- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/dlls/user32/combo.c b/dlls/user32/combo.c > index c744ee5..4c57b72 100644 > --- a/dlls/user32/combo.c > +++ b/dlls/user32/combo.c > @@ -1189,6 +1189,8 @@ static void COMBO_KillFocus( LPHEADCOMBO lphc ) > { > if( CB_GETTYPE(lphc) == CBS_DROPDOWNLIST ) > SendMessageW(lphc->hWndLBox, LB_CARETOFF, 0, 0); > + else > + SendMessageW(lphc->hWndEdit, EM_SETSEL, 0, 0); The message test doesn't confirm that this is a correct solution. -- Dmitry.

2 2

Re: [PATCH 2/2 v3] user32: Test error returned in out of timers case
by Marvin 25 Jan '16

25 Jan '16

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=19942 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different === w1064 (64 bit msg) === msg.c:6903: Test failed: WmParentPaint: 2: the msg sequence is not complete: expected 0000 - actual 001a

1 0

Re: [PATCH 2/2 v2] user32: Test error returned in out of timers case
by Sebastian Lackner 25 Jan '16

25 Jan '16

On 22.01.2016 16:10, Piotr Caban wrote: > + if (i == sizeof(ids)/sizeof(ids[0])) > + ok(0, "all timers were created successfully\n"); Why don't you use ok() directly to check the condition?

2 1

Re: advapi32/tests: Trace the SIDs if they are not as expected.
by Marvin 24 Jan '16

24 Jan '16

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=19941 Your paranoid android. === w864 (32 bit security) === security.c:3774: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). === w1064 (32 bit security) === security.c:3774: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:3815: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:3819: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:3828: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0)

1 0

Re: [PATCH v4] ntoskrnl.exe: Implement ZwLoadDriver and ZwUnloadDriver
by Sebastian Lackner 24 Jan '16

24 Jan '16

On 22.01.2016 19:15, Aric Stewart wrote: > Code is mostly moved from winedevice.exe > winedevice.exe now uses these functions > v3: No longer use advapi32 Registry functions > v4: Fix FALSE return code (thanks to Huw Davies for spotting this one) > Remove WINE_ from debuging macros > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 306 ++++++++++++++++++++++++++++++++++++ > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 4 +- > programs/winedevice/device.c | 243 +--------------------------- > 3 files changed, 313 insertions(+), 240 deletions(-) > I don't think moving the loader code from winedevice to ntoskrnl.exe is a good idea, at least not without further changes, because: * We should not initialize the same driver twice, the second initialization could fail because of namespace collisions. * Drivers should be properly uninitialized, no matter how they were loaded. * In theory, all drivers should be loaded into the same address space. This means, winedevice and the wineserver has to keep track of them, and its not sufficient to maintain a list in ntoskrnl.exe. Besides those design issues, I've marked a couple of other issues in the patch below. > > 0001-ntoskrnl.exe-Implement-ZwLoadDriver-and-ZwUnloadDriver.txt > > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index 04f0198..032ab21 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -72,6 +72,18 @@ static DWORD request_thread; > static DWORD client_tid; > static DWORD client_pid; > > +/* Loaded driver list */ > +typedef struct _loaded_driver { > + struct list entry; > + > + UNICODE_STRING name; > + HMODULE module; > + DRIVER_OBJECT driver_obj; > + DRIVER_EXTENSION driver_extension; > +} loaded_driver; > + > +struct list loaded_drivers = LIST_INIT(loaded_drivers); It wouldn't hurt to add locking for such a global list. > + > #ifdef __i386__ > #define DEFINE_FASTCALL1_ENTRYPOINT( name ) \ > __ASM_STDCALL_FUNC( name, 4, \ > @@ -2407,3 +2419,297 @@ NTSTATUS WINAPI CmUnRegisterCallback(LARGE_INTEGER cookie) > FIXME("(%s): stub\n", wine_dbgstr_longlong(cookie.QuadPart)); > return STATUS_NOT_IMPLEMENTED; > } > + > + > +/* find the LDR_MODULE corresponding to the driver module */ > +static LDR_MODULE *find_ldr_module( HMODULE module ) > +{ > + LIST_ENTRY *entry, *list = &NtCurrentTeb()->Peb->LdrData->InMemoryOrderModuleList; > + > + for (entry = list->Flink; entry != list; entry = entry->Flink) > + { > + LDR_MODULE *ldr = CONTAINING_RECORD(entry, LDR_MODULE, InMemoryOrderModuleList); > + if (ldr->BaseAddress == module) return ldr; > + if (ldr->BaseAddress > (void *)module) break; > + } The loader lock should be acquired while iterating through this list. (Yes, this is an existing issue, but before it was less critical because the code was single-threaded.) > + return NULL; > +} > + > +/* load the driver module file */ > +static HMODULE load_driver_module( const WCHAR *name ) > +{ > + IMAGE_NT_HEADERS *nt; > + const IMAGE_IMPORT_DESCRIPTOR *imports; > + SYSTEM_BASIC_INFORMATION info; > + int i; > + INT_PTR delta; > + ULONG size; > + HMODULE module = LoadLibraryW( name ); > + > + if (!module) return NULL; > + nt = RtlImageNtHeader( module ); > + > + if (!(delta = (char *)module - (char *)nt->OptionalHeader.ImageBase)) return module; > + > + /* the loader does not apply relocations to non page-aligned binaries or executables, > + * we have to do it ourselves */ > + > + NtQuerySystemInformation( SystemBasicInformation, &info, sizeof(info), NULL ); > + if (nt->OptionalHeader.SectionAlignment < info.PageSize || > + !(nt->FileHeader.Characteristics & IMAGE_FILE_DLL)) > + { > + DWORD old; > + IMAGE_BASE_RELOCATION *rel, *end; > + > + if ((rel = RtlImageDirectoryEntryToData( module, TRUE, IMAGE_DIRECTORY_ENTRY_BASERELOC, &size ))) > + { > + TRACE( "%s: relocating from %p to %p\n", > + wine_dbgstr_w(name), (char *)module - delta, module ); > + end = (IMAGE_BASE_RELOCATION *)((char *)rel + size); > + while (rel < end && rel->SizeOfBlock) > + { > + void *page = (char *)module + rel->VirtualAddress; > + VirtualProtect( page, info.PageSize, PAGE_EXECUTE_READWRITE, &old ); > + rel = LdrProcessRelocationBlock( page, (rel->SizeOfBlock - sizeof(*rel)) / sizeof(USHORT), > + (USHORT *)(rel + 1), delta ); > + if (old != PAGE_EXECUTE_READWRITE) VirtualProtect( page, info.PageSize, old, &old ); > + if (!rel) goto error; > + } > + /* make sure we don't try again */ > + size = FIELD_OFFSET( IMAGE_NT_HEADERS, OptionalHeader ) + nt->FileHeader.SizeOfOptionalHeader; > + VirtualProtect( nt, size, PAGE_READWRITE, &old ); > + nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress = 0; > + VirtualProtect( nt, size, old, &old ); > + } > + } > + > + /* make sure imports are relocated too */ > + > + if ((imports = RtlImageDirectoryEntryToData( module, TRUE, IMAGE_DIRECTORY_ENTRY_IMPORT, &size ))) > + { > + for (i = 0; imports[i].Name && imports[i].FirstThunk; i++) > + { > + char *name = (char *)module + imports[i].Name; > + WCHAR buffer[32], *p = buffer; > + > + while (p < buffer + 32) if (!(*p++ = *name++)) break; > + if (p <= buffer + 32) FreeLibrary( load_driver_module( buffer ) ); > + } > + } > + > + return module; > + > +error: > + FreeLibrary( module ); > + return NULL; > +} > + > +/* call the driver init entry point */ > +static NTSTATUS init_driver( const WCHAR *driver_name, UNICODE_STRING *keyname, loaded_driver *driver ) > +{ > + unsigned int i; > + NTSTATUS status; > + const IMAGE_NT_HEADERS *nt = RtlImageNtHeader( driver->module ); > + > + if (!nt->OptionalHeader.AddressOfEntryPoint) return STATUS_SUCCESS; > + > + driver->driver_obj.Size = sizeof(driver->driver_obj); > + driver->driver_obj.DriverSection = find_ldr_module( driver->module ); > + driver->driver_obj.DriverInit = (PDRIVER_INITIALIZE)((char *)driver->module + nt->OptionalHeader.AddressOfEntryPoint); > + driver->driver_obj.DriverExtension = &driver->driver_extension; > + > + driver->driver_obj.DriverExtension->DriverObject = &driver->driver_obj; > + driver->driver_obj.DriverExtension->ServiceKeyName = *keyname; > + > + if (TRACE_ON(relay)) > + DPRINTF( "%04x:Call driver init %p (obj=%p,str=%s)\n", GetCurrentThreadId(), > + driver->driver_obj.DriverInit, &driver->driver_obj, wine_dbgstr_w(keyname->Buffer) ); > + > + status = driver->driver_obj.DriverInit( &driver->driver_obj, keyname ); > + > + if (TRACE_ON(relay)) > + DPRINTF( "%04x:Ret driver init %p (obj=%p,str=%s) retval=%08x\n", GetCurrentThreadId(), > + driver->driver_obj.DriverInit, &driver->driver_obj, wine_dbgstr_w(keyname->Buffer), status ); > + > + TRACE( "init done for %s obj %p\n", wine_dbgstr_w(driver_name), &driver->driver_obj ); > + TRACE( "- DriverInit = %p\n", driver->driver_obj.DriverInit ); > + TRACE( "- DriverStartIo = %p\n", driver->driver_obj.DriverStartIo ); > + TRACE( "- DriverUnload = %p\n", driver->driver_obj.DriverUnload ); > + for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) > + TRACE( "- MajorFunction[%d] = %p\n", i, driver->driver_obj.MajorFunction[i] ); > + > + return status; > +} > + > +/*********************************************************************** > + * ZwLoadDriver (NTOSKRNL.EXE.@) > + */ > +NTSTATUS WINAPI ZwLoadDriver(const UNICODE_STRING *DriverServiceName) Both the Nt* and Zw* function should do the same, so I would suggest to implement Nt* instead and forward Zw*, like its done in ntdll. > +{ > + static const WCHAR driversW[] = {'\\','d','r','i','v','e','r','s','\\',0}; > + static const WCHAR systemrootW[] = {'\\','S','y','s','t','e','m','R','o','o','t','\\',0}; > + static const WCHAR postfixW[] = {'.','s','y','s',0}; > + static const WCHAR ntprefixW[] = {'\\','?','?','\\',0}; > + static const WCHAR ImagePathW[] = {'I','m','a','g','e','P','a','t','h',0}; > + static const WCHAR servicesW[] = {'\\','R','e','g','i','s','t','r','y', > + '\\','M','a','c','h','i','n','e', > + '\\','S','y','s','t','e','m', > + '\\','C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t', > + '\\','S','e','r','v','i','c','e','s','\\',0}; > + > + UNICODE_STRING keypath, reg_str; > + HMODULE module; > + LPWSTR path = NULL, str; > + DWORD size; > + HANDLE driver_hkey; > + OBJECT_ATTRIBUTES attr; > + NTSTATUS status; > + char buffer[256]; > + KEY_VALUE_PARTIAL_INFORMATION *info = (KEY_VALUE_PARTIAL_INFORMATION *)buffer; The initialization here looks unnecessary. > + static const int info_size = offsetof( KEY_VALUE_PARTIAL_INFORMATION, Data ); > + loaded_driver *driver; > + > + /* Check if driver is already loaded */ > + LIST_FOR_EACH_ENTRY(driver, &loaded_drivers, loaded_driver, entry) > + { > + if (RtlEqualUnicodeString(DriverServiceName, &driver->name, FALSE)) > + return ERROR_SUCCESS; > + } > + > + str = HeapAlloc(GetProcessHeap(), 0, sizeof(servicesW) + DriverServiceName->Length*sizeof(WCHAR)); Length is the length in bytes, so the calculation above is wrong. > + lstrcpyW(str, servicesW); > + lstrcatW(str, DriverServiceName->Buffer); I don't think you can assume a terminating NULL character. > + > + attr.Length = sizeof(attr); > + attr.RootDirectory = 0; > + attr.ObjectName = &reg_str; > + attr.Attributes = 0; > + attr.SecurityDescriptor = NULL; > + attr.SecurityQualityOfService = NULL; > + > + RtlInitUnicodeString(&reg_str, str); > + > + status = NtCreateKey(&driver_hkey, KEY_ALL_ACCESS, &attr, 0, NULL, 0, NULL); > + if (status != STATUS_SUCCESS) > + { > + ERR("cannot open key %s, err=0x%x\n", wine_dbgstr_w(str), status); > + HeapFree(GetProcessHeap(), 0, str); > + return status; > + } > + RtlInitUnicodeString(&keypath, str); > + > + /* read the executable path from memory */ > + size = 0; > + RtlInitUnicodeString(&reg_str, ImagePathW); > + > + status = NtQueryValueKey(driver_hkey, &reg_str, KeyValuePartialInformation, buffer, info_size, &size); > + if (status == STATUS_BUFFER_OVERFLOW) > + { > + str = HeapAlloc(GetProcessHeap(), 0, size); str was already set before, so this might leak memory, at least on some exit paths. > + info = (KEY_VALUE_PARTIAL_INFORMATION *) str; > + status = NtQueryValueKey(driver_hkey, &reg_str, KeyValuePartialInformation, str, size, &size); > + > + if (status == STATUS_SUCCESS) > + { > + size = ExpandEnvironmentStringsW((LPCWSTR)info->Data,NULL,0); > + path = HeapAlloc(GetProcessHeap(),0,size*sizeof(WCHAR)); > + ExpandEnvironmentStringsW((LPCWSTR)info->Data,path,size); > + } > + HeapFree(GetProcessHeap(), 0, str); > + if (!path) > + { > + TRACE("Failed to load driver path(0x%x): %s\n", status, > + wine_dbgstr_w((LPCWSTR)info->Data)); info->Data points into str, which was deallocated just before. > + NtClose(driver_hkey); > + return status; > + } > + > + if (!strncmpiW(path, systemrootW, 12)) > + { > + WCHAR buffer[MAX_PATH]; The variable name is the same as above, which might be misleading. > + > + GetWindowsDirectoryW(buffer, MAX_PATH); > + > + str = HeapAlloc(GetProcessHeap(), 0, (size -11 + strlenW(buffer)) > + * sizeof(WCHAR)); > + lstrcpyW(str, buffer); > + lstrcatW(str, path + 11); > + HeapFree(GetProcessHeap(), 0, path); > + path = str; > + } > + else if (!strncmpW(path, ntprefixW, 4)) > + str = path + 4; > + else > + str = path; > + } > + else > + { > + /* default is to use the driver name + ".sys" */ > + WCHAR buffer[MAX_PATH]; > + GetSystemDirectoryW(buffer, MAX_PATH); > + path = HeapAlloc(GetProcessHeap(),0, > + (strlenW(buffer) + strlenW(driversW) + DriverServiceName->Length + strlenW(postfixW) + 1) > + *sizeof(WCHAR)); Similar to above, ->Length is the length in bytes. > + lstrcpyW(path, buffer); > + lstrcatW(path, driversW); > + lstrcatW(path, DriverServiceName->Buffer); > + lstrcatW(path, postfixW); > + str = path; > + } > + NtClose(driver_hkey); > + > + TRACE("loading driver %s\n", wine_dbgstr_w(str)); > + > + module = load_driver_module(str); > + HeapFree(GetProcessHeap(), 0, path); > + > + if (!module) > + return STATUS_NOT_FOUND; > + > + driver = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*driver)); > + driver->module = module; > + RtlDuplicateUnicodeString(1, DriverServiceName, &driver->name); > + > + init_driver(DriverServiceName->Buffer, &keypath, driver); > + > + list_add_tail(&loaded_drivers, &driver->entry); > + > + return STATUS_SUCCESS; > +} > + > +/*********************************************************************** > + * ZwUnloadDriver (NTOSKRNL.EXE.@) > + */ > +NTSTATUS WINAPI ZwUnloadDriver(const UNICODE_STRING *DriverServiceName) > +{ > + loaded_driver *driver, *ptr; > + > + LIST_FOR_EACH_ENTRY_SAFE(driver, ptr, &loaded_drivers, loaded_driver, entry) > + { > + if (RtlEqualUnicodeString(DriverServiceName, &driver->name, FALSE)) > + { > + list_remove(&driver->entry); > + > + if (driver->driver_obj.DriverUnload) > + { > + if (TRACE_ON(relay)) > + DPRINTF("%04x:Call driver unload %p (obj=%p)\n", GetCurrentThreadId(), > + driver->driver_obj.DriverUnload, &driver->driver_obj ); > + > + driver->driver_obj.DriverUnload( &driver->driver_obj); > + > + if (TRACE_ON(relay)) > + DPRINTF("%04x:Ret driver unload %p (obj=%p)\n", GetCurrentThreadId(), > + driver->driver_obj.DriverUnload, &driver->driver_obj); > + } > + > + RtlFreeUnicodeString(&driver->name); > + RtlFreeUnicodeString(&driver->driver_extension.ServiceKeyName); > + FreeLibrary(driver->module); > + HeapFree(GetProcessHeap(), 0, driver); > + return STATUS_SUCCESS; > + } > + } > + > + return STATUS_NOT_FOUND; > +} > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > index 1319ada..a98a523 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -1314,7 +1314,7 @@ > @ stdcall ZwFsControlFile(long long long long long long long long long long) ntdll.ZwFsControlFile > @ stdcall ZwInitiatePowerAction(long long long long) ntdll.ZwInitiatePowerAction > @ stdcall ZwIsProcessInJob(long long) ntdll.ZwIsProcessInJob > -@ stdcall ZwLoadDriver(ptr) ntdll.ZwLoadDriver > +@ stdcall ZwLoadDriver(ptr) > @ stdcall ZwLoadKey(ptr ptr) ntdll.ZwLoadKey > @ stdcall ZwMakeTemporaryObject(long) ntdll.ZwMakeTemporaryObject > @ stdcall ZwMapViewOfSection(long long ptr long long ptr ptr long long long) ntdll.ZwMapViewOfSection > @@ -1384,7 +1384,7 @@ > @ stdcall ZwTerminateJobObject(long long) ntdll.ZwTerminateJobObject > @ stdcall ZwTerminateProcess(long long) ntdll.ZwTerminateProcess > @ stub ZwTranslateFilePath > -@ stdcall ZwUnloadDriver(ptr) ntdll.ZwUnloadDriver > +@ stdcall ZwUnloadDriver(ptr) > @ stdcall ZwUnloadKey(long) ntdll.ZwUnloadKey > @ stdcall ZwUnmapViewOfSection(long ptr) ntdll.ZwUnmapViewOfSection > @ stdcall ZwWaitForMultipleObjects(long ptr long long ptr) ntdll.ZwWaitForMultipleObjects > diff --git a/programs/winedevice/device.c b/programs/winedevice/device.c > index ef1e1ef..cb6a6ba 100644 > --- a/programs/winedevice/device.c > +++ b/programs/winedevice/device.c > @@ -25,253 +25,19 @@ > > #include "ntstatus.h" > #define WIN32_NO_STATUS > -#include "windef.h" > -#include "winbase.h" > #include "winternl.h" > -#include "winreg.h" > -#include "winnls.h" > #include "winsvc.h" > #include "ddk/wdm.h" > #include "wine/unicode.h" > #include "wine/debug.h" > > WINE_DEFAULT_DEBUG_CHANNEL(winedevice); > -WINE_DECLARE_DEBUG_CHANNEL(relay); > > extern NTSTATUS CDECL wine_ntoskrnl_main_loop( HANDLE stop_event ); > > static WCHAR *driver_name; > static SERVICE_STATUS_HANDLE service_handle; > -static HKEY driver_hkey; > static HANDLE stop_event; > -static DRIVER_OBJECT driver_obj; > -static DRIVER_EXTENSION driver_extension; > - > -/* find the LDR_MODULE corresponding to the driver module */ > -static LDR_MODULE *find_ldr_module( HMODULE module ) > -{ > - LIST_ENTRY *entry, *list = &NtCurrentTeb()->Peb->LdrData->InMemoryOrderModuleList; > - > - for (entry = list->Flink; entry != list; entry = entry->Flink) > - { > - LDR_MODULE *ldr = CONTAINING_RECORD(entry, LDR_MODULE, InMemoryOrderModuleList); > - if (ldr->BaseAddress == module) return ldr; > - if (ldr->BaseAddress > (void *)module) break; > - } > - return NULL; > -} > - > -/* load the driver module file */ > -static HMODULE load_driver_module( const WCHAR *name ) > -{ > - IMAGE_NT_HEADERS *nt; > - const IMAGE_IMPORT_DESCRIPTOR *imports; > - SYSTEM_BASIC_INFORMATION info; > - int i; > - INT_PTR delta; > - ULONG size; > - HMODULE module = LoadLibraryW( name ); > - > - if (!module) return NULL; > - nt = RtlImageNtHeader( module ); > - > - if (!(delta = (char *)module - (char *)nt->OptionalHeader.ImageBase)) return module; > - > - /* the loader does not apply relocations to non page-aligned binaries or executables, > - * we have to do it ourselves */ > - > - NtQuerySystemInformation( SystemBasicInformation, &info, sizeof(info), NULL ); > - if (nt->OptionalHeader.SectionAlignment < info.PageSize || > - !(nt->FileHeader.Characteristics & IMAGE_FILE_DLL)) > - { > - DWORD old; > - IMAGE_BASE_RELOCATION *rel, *end; > - > - if ((rel = RtlImageDirectoryEntryToData( module, TRUE, IMAGE_DIRECTORY_ENTRY_BASERELOC, &size ))) > - { > - WINE_TRACE( "%s: relocating from %p to %p\n", > - wine_dbgstr_w(name), (char *)module - delta, module ); > - end = (IMAGE_BASE_RELOCATION *)((char *)rel + size); > - while (rel < end && rel->SizeOfBlock) > - { > - void *page = (char *)module + rel->VirtualAddress; > - VirtualProtect( page, info.PageSize, PAGE_EXECUTE_READWRITE, &old ); > - rel = LdrProcessRelocationBlock( page, (rel->SizeOfBlock - sizeof(*rel)) / sizeof(USHORT), > - (USHORT *)(rel + 1), delta ); > - if (old != PAGE_EXECUTE_READWRITE) VirtualProtect( page, info.PageSize, old, &old ); > - if (!rel) goto error; > - } > - /* make sure we don't try again */ > - size = FIELD_OFFSET( IMAGE_NT_HEADERS, OptionalHeader ) + nt->FileHeader.SizeOfOptionalHeader; > - VirtualProtect( nt, size, PAGE_READWRITE, &old ); > - nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress = 0; > - VirtualProtect( nt, size, old, &old ); > - } > - } > - > - /* make sure imports are relocated too */ > - > - if ((imports = RtlImageDirectoryEntryToData( module, TRUE, IMAGE_DIRECTORY_ENTRY_IMPORT, &size ))) > - { > - for (i = 0; imports[i].Name && imports[i].FirstThunk; i++) > - { > - char *name = (char *)module + imports[i].Name; > - WCHAR buffer[32], *p = buffer; > - > - while (p < buffer + 32) if (!(*p++ = *name++)) break; > - if (p <= buffer + 32) FreeLibrary( load_driver_module( buffer ) ); > - } > - } > - > - return module; > - > -error: > - FreeLibrary( module ); > - return NULL; > -} > - > -/* call the driver init entry point */ > -static NTSTATUS init_driver( HMODULE module, UNICODE_STRING *keyname ) > -{ > - unsigned int i; > - NTSTATUS status; > - const IMAGE_NT_HEADERS *nt = RtlImageNtHeader( module ); > - > - if (!nt->OptionalHeader.AddressOfEntryPoint) return STATUS_SUCCESS; > - > - driver_obj.Size = sizeof(driver_obj); > - driver_obj.DriverSection = find_ldr_module( module ); > - driver_obj.DriverInit = (PDRIVER_INITIALIZE)((char *)module + nt->OptionalHeader.AddressOfEntryPoint); > - driver_obj.DriverExtension = &driver_extension; > - > - driver_extension.DriverObject = &driver_obj; > - driver_extension.ServiceKeyName = *keyname; > - > - if (WINE_TRACE_ON(relay)) > - WINE_DPRINTF( "%04x:Call driver init %p (obj=%p,str=%s)\n", GetCurrentThreadId(), > - driver_obj.DriverInit, &driver_obj, wine_dbgstr_w(keyname->Buffer) ); > - > - status = driver_obj.DriverInit( &driver_obj, keyname ); > - > - if (WINE_TRACE_ON(relay)) > - WINE_DPRINTF( "%04x:Ret driver init %p (obj=%p,str=%s) retval=%08x\n", GetCurrentThreadId(), > - driver_obj.DriverInit, &driver_obj, wine_dbgstr_w(keyname->Buffer), status ); > - > - WINE_TRACE( "init done for %s obj %p\n", wine_dbgstr_w(driver_name), &driver_obj ); > - WINE_TRACE( "- DriverInit = %p\n", driver_obj.DriverInit ); > - WINE_TRACE( "- DriverStartIo = %p\n", driver_obj.DriverStartIo ); > - WINE_TRACE( "- DriverUnload = %p\n", driver_obj.DriverUnload ); > - for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) > - WINE_TRACE( "- MajorFunction[%d] = %p\n", i, driver_obj.MajorFunction[i] ); > - > - return status; > -} > - > -/* call the driver unload function */ > -static void unload_driver( HMODULE module, DRIVER_OBJECT *driver_obj ) > -{ > - if (driver_obj->DriverUnload) > - { > - if (WINE_TRACE_ON(relay)) > - WINE_DPRINTF( "%04x:Call driver unload %p (obj=%p)\n", GetCurrentThreadId(), > - driver_obj->DriverUnload, driver_obj ); > - > - driver_obj->DriverUnload( driver_obj ); > - > - if (WINE_TRACE_ON(relay)) > - WINE_DPRINTF( "%04x:Ret driver unload %p (obj=%p)\n", GetCurrentThreadId(), > - driver_obj->DriverUnload, driver_obj ); > - } > - FreeLibrary( module ); > -} > - > -/* load the .sys module for a device driver */ > -static HMODULE load_driver(void) > -{ > - static const WCHAR driversW[] = {'\\','d','r','i','v','e','r','s','\\',0}; > - static const WCHAR systemrootW[] = {'\\','S','y','s','t','e','m','R','o','o','t','\\',0}; > - static const WCHAR postfixW[] = {'.','s','y','s',0}; > - static const WCHAR ntprefixW[] = {'\\','?','?','\\',0}; > - static const WCHAR ImagePathW[] = {'I','m','a','g','e','P','a','t','h',0}; > - static const WCHAR servicesW[] = {'\\','R','e','g','i','s','t','r','y', > - '\\','M','a','c','h','i','n','e', > - '\\','S','y','s','t','e','m', > - '\\','C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t', > - '\\','S','e','r','v','i','c','e','s','\\',0}; > - > - UNICODE_STRING keypath; > - HMODULE module; > - LPWSTR path = NULL, str; > - DWORD type, size; > - > - str = HeapAlloc( GetProcessHeap(), 0, sizeof(servicesW) + strlenW(driver_name)*sizeof(WCHAR) ); > - lstrcpyW( str, servicesW ); > - lstrcatW( str, driver_name ); > - > - if (RegOpenKeyW( HKEY_LOCAL_MACHINE, str + 18 /* skip \registry\machine */, &driver_hkey )) > - { > - WINE_ERR( "cannot open key %s, err=%u\n", wine_dbgstr_w(str), GetLastError() ); > - HeapFree( GetProcessHeap(), 0, str); > - return FALSE; > - } > - RtlInitUnicodeString( &keypath, str ); > - > - /* read the executable path from memory */ > - size = 0; > - if (!RegQueryValueExW( driver_hkey, ImagePathW, NULL, &type, NULL, &size )) > - { > - str = HeapAlloc( GetProcessHeap(), 0, size ); > - if (!RegQueryValueExW( driver_hkey, ImagePathW, NULL, &type, (LPBYTE)str, &size )) > - { > - size = ExpandEnvironmentStringsW(str,NULL,0); > - path = HeapAlloc(GetProcessHeap(),0,size*sizeof(WCHAR)); > - ExpandEnvironmentStringsW(str,path,size); > - } > - HeapFree( GetProcessHeap(), 0, str ); > - if (!path) return FALSE; > - > - if (!strncmpiW( path, systemrootW, 12 )) > - { > - WCHAR buffer[MAX_PATH]; > - > - GetWindowsDirectoryW(buffer, MAX_PATH); > - > - str = HeapAlloc(GetProcessHeap(), 0, (size -11 + strlenW(buffer)) > - * sizeof(WCHAR)); > - lstrcpyW(str, buffer); > - lstrcatW(str, path + 11); > - HeapFree( GetProcessHeap(), 0, path ); > - path = str; > - } > - else if (!strncmpW( path, ntprefixW, 4 )) > - str = path + 4; > - else > - str = path; > - } > - else > - { > - /* default is to use the driver name + ".sys" */ > - WCHAR buffer[MAX_PATH]; > - GetSystemDirectoryW(buffer, MAX_PATH); > - path = HeapAlloc(GetProcessHeap(),0, > - (strlenW(buffer) + strlenW(driversW) + strlenW(driver_name) + strlenW(postfixW) + 1) > - *sizeof(WCHAR)); > - lstrcpyW(path, buffer); > - lstrcatW(path, driversW); > - lstrcatW(path, driver_name); > - lstrcatW(path, postfixW); > - str = path; > - } > - > - WINE_TRACE( "loading driver %s\n", wine_dbgstr_w(str) ); > - > - module = load_driver_module( str ); > - HeapFree( GetProcessHeap(), 0, path ); > - if (!module) return NULL; > - > - init_driver( module, &keypath ); > - return module; > -} > > static DWORD WINAPI service_handler( DWORD ctrl, DWORD event_type, LPVOID event_data, LPVOID context ) > { > @@ -305,7 +71,7 @@ static DWORD WINAPI service_handler( DWORD ctrl, DWORD event_type, LPVOID event_ > static void WINAPI ServiceMain( DWORD argc, LPWSTR *argv ) > { > SERVICE_STATUS status; > - HMODULE driver_module; > + UNICODE_STRING DriverName; > > WINE_TRACE( "starting service %s\n", wine_dbgstr_w(driver_name) ); > > @@ -324,15 +90,16 @@ static void WINAPI ServiceMain( DWORD argc, LPWSTR *argv ) > status.dwWaitHint = 10000; > SetServiceStatus( service_handle, &status ); > > - driver_module = load_driver(); > - if (driver_module) > + RtlInitUnicodeString( &DriverName, driver_name ); > + > + if ( ZwLoadDriver( &DriverName ) == ERROR_SUCCESS ) > { > status.dwCurrentState = SERVICE_RUNNING; > status.dwControlsAccepted = SERVICE_ACCEPT_STOP | SERVICE_ACCEPT_SHUTDOWN; > SetServiceStatus( service_handle, &status ); > > wine_ntoskrnl_main_loop( stop_event ); > - unload_driver( driver_module, &driver_obj ); > + ZwUnloadDriver( &DriverName ); > } > else WINE_ERR( "driver %s failed to load\n", wine_dbgstr_w(driver_name) ); > > > >

3 7

Re: [PATCH v3] mscoree: Implement VTable fixup for x86_64 architecture.
by Sebastian Lackner 23 Jan '16

23 Jan '16

On 22.01.2016 23:24, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/mscoree/corruntimehost.c | 91 +++++++++++++++++++++++++++++++++++++------ > 1 file changed, 79 insertions(+), 12 deletions(-) > > diff --git a/dlls/mscoree/corruntimehost.c b/dlls/mscoree/corruntimehost.c > index e437cc2..05ac9c9 100644 > --- a/dlls/mscoree/corruntimehost.c > +++ b/dlls/mscoree/corruntimehost.c > @@ -919,7 +919,68 @@ static const struct vtable_fixup_thunk thunk_template = { > > #include "poppack.h" > > -#else /* !defined(__i386__) */ > +#elif __x86_64__ /* !__i386__ */ > + > +# define CAN_FIXUP_VTABLE 1 > + > +#include "pshpack1.h" > + > +struct vtable_fixup_thunk > +{ > + /* push %rcx; push %rdx; push %r8; push %r9 */ I think it would be better to allocate a proper stack frame (pushq %rbp, movq %rsp, %rbp, subq ...,%rsp) and then use movq instructions. > + BYTE i1[6]; > + /* sub $0x68, %rsp ; 0x10*4 + 0x20 + 0x8 (align stack for subsequent func call) > + movups %xmm0,0x28(%esp); ...; movups %xmm5,0x58(%esp) Shouldn't it be %rsp ? Same for the precompiled assembler code below. Also, its theoretically safe to use movdqa like done in various other wine functions. > + > + ReallyFixupVTable will crash if we are called with unaligned stack There is no need to add a comment for that, its expected to crash when misaligning the stack. > + */ > + BYTE i2[28]; > + /* mov function,%eax */ > + BYTE i3[2]; > + void (CDECL *function)(struct dll_fixup *); > + /* mov fixup,%rcx */ > + BYTE i4[2]; > + struct dll_fixup *fixup; > + /* call *%eax */ > + BYTE i5[2]; > + /* > + movups 0x28(%esp),xmm0; ...; movups 0x58(%esp),xmm3 > + add $0x68, %rsp > + */ > + BYTE i6[28]; > + /* pop %r9; pop %r8; pop %rdx; pop %rcx */ > + BYTE i7[6]; > + /* mov vtable_entry, %rax */ > + BYTE i8[2]; > + void *vtable_entry; > + /* mov [%rax],%rax > + jmp %rax */ > + BYTE i9[5]; > +}; > + > +static const struct vtable_fixup_thunk thunk_template = { > + {0x51,0x52,0x41,0x50,0x41,0x51}, > + {0x48,0x83,0xEC,0x68, > + 0x67,0x0F,0x11,0x44,0x24,0x28, 0x67,0x0F,0x11,0x4C,0x24,0x38, > + 0x67,0x0F,0x11,0x54,0x24,0x48, 0x67,0x0F,0x11,0x5C,0x24,0x58, > + }, > + {0x48,0xB8}, > + NULL, > + {0x48,0xB9}, > + NULL, > + {0xFF,0xD0}, > + {0x67,0x0F,0x10,0x44,0x24,0x28, 0x67,0x0F,0x10,0x4C,0x24,0x38, > + 0x67,0x0F,0x10,0x54,0x24,0x48, 0x67,0x0F,0x10,0x5C,0x24,0x58, > + 0x48,0x83,0xC4,0x68}, > + {0x41,0x59,0x41,0x58,0x5A,0x59}, > + {0x48,0xB8}, > + NULL, > + {0x48,0x8B,0x00,0xFF,0xE0} > +}; > + > +#include "poppack.h" > + > +#else /* !__i386__ && !__x86_64__ */ > > # define CAN_FIXUP_VTABLE 0 > > @@ -982,15 +1043,19 @@ static void CDECL ReallyFixupVTable(struct dll_fixup *fixup) > /* Mono needs an image that belongs to an assembly. */ > image = mono_assembly_get_image(assembly); > > +#if __x86_64__ > + if (fixup->fixup->type & COR_VTABLE_64BIT) > +#else > if (fixup->fixup->type & COR_VTABLE_32BIT) > +#endif > { > - DWORD *vtable = fixup->vtable; > - DWORD *tokens = fixup->tokens; > + void **vtable = fixup->vtable; > + ULONG_PTR *tokens = fixup->tokens; > for (i=0; i<fixup->fixup->count; i++) > { > - TRACE("%x\n", tokens[i]); > - vtable[i] = PtrToUint(mono_marshal_get_vtfixup_ftnptr( > - image, tokens[i], fixup->fixup->type)); > + TRACE("%#lx\n", tokens[i]); > + vtable[i] = mono_marshal_get_vtfixup_ftnptr( > + image, tokens[i], fixup->fixup->type); I would suggest to move those changes and some of the changes below into a separate patch. They can easily be reviewed separately and using PtrToUint() instead of pointer types wasn't even a good idea on 32-bit. ;) > } > } > > @@ -1029,16 +1094,18 @@ static void FixupVTableEntry(HMODULE hmodule, VTableFixup *vtable_fixup) > fixup->vtable = (BYTE*)hmodule + vtable_fixup->rva; > fixup->done = FALSE; > > + TRACE("vtable_fixup->type=0x%x\n",vtable_fixup->type); > +#if __x86_64__ > + if (vtable_fixup->type & COR_VTABLE_64BIT) > +#else > if (vtable_fixup->type & COR_VTABLE_32BIT) > +#endif > { > - DWORD *vtable = fixup->vtable; > - DWORD *tokens; > + void **vtable = fixup->vtable; > + ULONG_PTR *tokens; > int i; > struct vtable_fixup_thunk *thunks = fixup->thunk_code; > > - if (sizeof(void*) > 4) > - ERR("32-bit fixup in 64-bit mode; broken image?\n"); > - > tokens = fixup->tokens = HeapAlloc(GetProcessHeap(), 0, sizeof(*tokens) * vtable_fixup->count); > memcpy(tokens, vtable, sizeof(*tokens) * vtable_fixup->count); > for (i=0; i<vtable_fixup->count; i++) > @@ -1047,7 +1114,7 @@ static void FixupVTableEntry(HMODULE hmodule, VTableFixup *vtable_fixup) > thunks[i].fixup = fixup; > thunks[i].function = ReallyFixupVTable; > thunks[i].vtable_entry = &vtable[i]; > - vtable[i] = PtrToUint(&thunks[i]); > + vtable[i] = &thunks[i]; > } > } > else >

3 3

Re: [PATCH 3/3] mpr: Implement WNetUseConnectionA(). (try 4)
by Alexandre Julliard 23 Jan '16

23 Jan '16

Pierre Schweitzer <pierre(a)reactos.org> writes: > + ret = WNetUseConnectionW(hwndOwner, pRes, passW, userIDW, dwFlags, > + accessNameW, lpBufferSize, lpResult); > + if (lpAccessName && lpBufferSize && *lpBufferSize && accessNameW) > + { > + len = WideCharToMultiByte(CP_ACP, 0, accessNameW, -1, NULL, 0, NULL, NULL); > + if (len && len <= *lpBufferSize) > + WideCharToMultiByte(CP_ACP, 0, accessNameW, -1, lpAccessName, len, NULL, NULL); > + } You need to handle failures, and a possibly different lpBufferSize for the W function. It could also use some test cases, which would probably require the W function to do something useful first. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH v2 3/3] shell32/tests: Trace the association properties for the DDE tests.
by Marvin 22 Jan '16

22 Jan '16

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=19922 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:1610: Test failed: WaitForSingleObject returned 258 shlexec.c:1639: Test failed: argvA3 expected 'QuotedLowerL', got 'Open' shlexec.c:1647: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDA95.tmp\test file.shlexec', got 'C:\Users\winetest\AppData\Local\Temp\wtDA95.tmp\test file.noassoc.shlexec' === w1064 (32 bit shlexec) === shlexec.c:2356: Test failed: failed: rc=29 err=2 shlexec.c:2356: Test failed: failed: rc=29 err=2 shlexec.c:2356: Test failed: failed: rc=29 err=2 shlexec.c:2356: Test failed: failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2356: Test failed: failed: rc=29 err=2 shlexec.c:2356: Test failed: failed: rc=29 err=2 shlexec.c:2356: Test failed: failed: rc=29 err=2 shlexec.c:2368: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt4F7B.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt4F7B.tmp\test file.sde")]' shlexec.c:2356: Test failed: failed: rc=29 err=2 shlexec.c:2356: Test failed: failed: rc=29 err=2

2 1

Re: [PATCH] mscoree: Implement VTable fixup for x86_64 architecture.
by Vincent Povirk 22 Jan '16

22 Jan '16

I don't see anything obviously wrong here, but I also have no way of testing it, since we can't compile methods without loading the class library dll's. > +#elif __x86_64__ /* !defined(__i386__) */ Later in the patch it says defined(__x86_64__). I have no idea whether this distinction matters.

3 19

Re: [PATCH v2] mscoree: Implement VTable fixup for x86_64 architecture.
by Vincent Povirk 22 Jan '16

22 Jan '16

So, I'm trying to understand which registers we need to preserve, and I found some pages on MSDN. register usage: https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx parameter passing: https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx I think we need to preserve all parameter registers and can freely use any scratch registers that are not parameter registers, and that we only need to worry about the 64-bit Windows ABI. MSDN seems to say that only XMM0 through XMM3 are used for parameter passing, and that the extra bits in YMM0 through YMM3 are scratch registers. I think that means we can ignore XMM4, XMM5, and AVX extensions. The requirements may be different for the non-Windows ABI, but I hope we can trust the compiler to take care of that as long as we're not calling such a function directly. I'm not sure if we can use __attribute__((force_align_arg_pointer)) directly in this way, but I will defer to others on that question.

2 5

Re: [PATCH v2 2/3] shell32/tests: Call okShell() after a shell_execute{_ex}() test.
by Marvin 22 Jan '16

22 Jan '16

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=19921 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:1583: Test failed: WaitForSingleObject returned 258 shlexec.c:1612: Test failed: argvA3 expected 'QuotedLowerL', got 'Open' shlexec.c:1620: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDD63.tmp\test file.shlexec', got 'C:\Users\winetest\AppData\Local\Temp\wtDD63.tmp\test file.noassoc.shlexec' === w1064 (32 bit shlexec) === shlexec.c:2329: Test failed: failed: rc=29 err=2 shlexec.c:2329: Test failed: failed: rc=29 err=2 shlexec.c:2329: Test failed: failed: rc=29 err=2 shlexec.c:2329: Test failed: failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2329: Test failed: failed: rc=29 err=2 shlexec.c:2329: Test failed: failed: rc=29 err=2 shlexec.c:2329: Test failed: failed: rc=29 err=2 shlexec.c:2341: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt14C3.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt14C3.tmp\test file.sde")]' shlexec.c:2329: Test failed: failed: rc=29 err=2 shlexec.c:2329: Test failed: failed: rc=29 err=2

1 0

Re: [PATCH v2 1/3] shell32/tests: Trace the last ShellExecute command whenever a corresponding test fails.
by Marvin 22 Jan '16

22 Jan '16

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=19920 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt39FF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt39FF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt39FF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2348: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt39FF.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt39FF.tmp\test file.sde")]' shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt39FF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt39FF.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt29CA.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt29CA.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt29CA.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2336: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt29CA.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: include: Create todo_wine_if.
by Sebastian Lackner 22 Jan '16

22 Jan '16

On 22.01.2016 17:50, Bernhard Übelacker wrote: > +#define todo_if(is_todo, platform) for (winetest_start_todo_if(is_todo, platform); \ > + winetest_loop_todo(); \ > + winetest_end_todo_if(is_todo, platform)) There is a high risk of corrupting todo_level if is_todo changes in the meantime. Nevertheless, I like the general idea of introducing such a command, it would make some tests much easier and avoid duplicated checks.

1 0

Re: [PATCH 2/2 v2] user32: Test error returned in out of timers case
by Marvin 22 Jan '16

22 Jan '16

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=19916 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different === w7pro64 (64 bit msg) === msg.c:15113: Test failed: wrong status 00400040

2 1

Re: shell32/tests: Fix a couple of okChildString()/okChildPath() mixups.
by Marvin 22 Jan '16

22 Jan '16

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=19918 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/7] wined3d: Add support for WINED3DFMT_R8G8B8A8_UINT textures.
by Henri Verbeet 22 Jan '16

22 Jan '16

This introduces GL errors: err:d3d:check_fbo_compat >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Post-pixelshader blending check @ utils.c / 1905 err:d3d:check_fbo_compat >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Post-pixelshader blending check @ utils.c / 1905 err:d3d:check_fbo_compat >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Post-pixelshader blending check @ utils.c / 1905 err:d3d:check_fbo_compat >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Post-pixelshader blending check @ utils.c / 1905 err:d3d:check_fbo_compat >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Post-pixelshader blending check @ utils.c / 1905 err:d3d:check_fbo_compat >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from Post-pixelshader blending check @ utils.c / 1905 I didn't check if that's the issue here, but in the longer term we'll probably need to add channel type information to the formats[] table. E.g. look at places that currently use WINED3DFMT_FLAG_FLOAT.

2 1

Re: [1/2] shell32/tests: Trace the last ShellExecute command whenever a corresponding test fails.
by Alexandre Julliard 22 Jan '16

22 Jan '16

Francois Gouget <fgouget(a)codeweavers.com> writes: > Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> > --- > dlls/shell32/tests/shlexec.c | 75 ++++++++++++++++++++++++++++++-------------- > 1 file changed, 52 insertions(+), 23 deletions(-) > > diff --git a/dlls/shell32/tests/shlexec.c b/dlls/shell32/tests/shlexec.c > index 8f03799..360fb2b 100644 > --- a/dlls/shell32/tests/shlexec.c > +++ b/dlls/shell32/tests/shlexec.c > @@ -94,6 +94,28 @@ static int _todo_wait = 0; > #define todo_wait for (_todo_wait = 1; _todo_wait; _todo_wait = 0) > > static char shell_call[2048]=""; > +static char last_shell_call[2048]=""; > +static void WINETEST_PRINTF_ATTR(2,3) _okShell(int condition, const char *msg, ...) > +{ > + va_list valist; > + > + /* Note: if winetest_debug > 1 the ShellExecute() command has already been > + * traced. > + */ > + if (winetest_debug <= 1 && !condition && strcmp(last_shell_call, shell_call)) > + { > + winetest_trace("Called %s\n", shell_call); > + strcpy(last_shell_call, shell_call); > + } > + > + va_start(valist, msg); > + winetest_vok(condition, msg, valist); > + va_end(valist); > +} Why is that better than always printing it in the failing calls? -- Alexandre Julliard julliard(a)winehq.org

2 5

MSSQL ODBC as describesd in 4.3.6.2 4.3.6.2. Using Windows ODBC drivers
by Olaf Schumann 22 Jan '16

22 Jan '16

Hi, This works fine, but if the MSSQL-Server needs SSL the connection fails. To Test it, install MDAC_TYP.EXE from Microsoft (winetricks: win2k and native_mdac) Control Panel->Data Sources(ODBC)->SystemDSN->Add->SQL Server Configure a Server without SSL: Everything's fine. Configure a Server with SSL: Connection fails. I cross-checked this with a Windows 2k VM. Installing MDAC_TYP.EXE. Configuring the above SQL Servers: Connection to a SSL encryption enabled SQL Server works. Best regards, Olaf Olaf Schumann Product Manager ___________________ Logo_email dataplan GmbH Stahltwiete 23 22761 Hamburg, Germany CEO: Dr. Wolfgang Zetsche Comm. Reg.: HRB 31 083 Venue: Hamburg VAT ID No.: DE118540281 Phone +49 40 398 44 20 Fax: +49 40 390 26 39 www.dataplan.de <mailto:oschumann@dataplan.de> mailto:oschumann@dataplan.de

1 0

Re: [2/2] user32: Use IsTextUnicode instead of a helper.
by Nikolay Sivov 22 Jan '16

22 Jan '16

On 22.01.2016 10:11, Jactry Zeng wrote: > - if (!data_looks_unicode( ptr, size )) > + if (!IsTextUnicode((WCHAR *)ptr, sizeof((WCHAR *)ptr), NULL)) Why it's sizeof() now instead of 'size' ? Also why do you need a cast to (WCHAR*)?

2 1

Re: [PATCH v2] server: Implement serial port read interval timeouts.
by Alexandre Julliard 22 Jan '16

22 Jan '16

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=39875 > > There is a test program attached to the bug report. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > server/async.c | 14 ++++++++++++++ > server/fd.c | 12 ++++++++++++ > server/file.h | 3 +++ > server/serial.c | 13 ++++++++++++- > 4 files changed, 41 insertions(+), 1 deletion(-) > > diff --git a/server/async.c b/server/async.c > index d2da976..e718462 100644 > --- a/server/async.c > +++ b/server/async.c > @@ -216,6 +216,20 @@ void free_async_queue( struct async_queue *queue ) > release_object( queue ); > } > > +/* set the timeout of the async queue head if the new timeout is shorter than the current one */ > +/* only pass negative timeouts (i.e. timeouts relative to the current time) to this function */ > +void async_queue_set_shorter_timeout( struct async_queue *queue, timeout_t timeout, unsigned int status ) > +{ > + struct list *ptr; > + struct async *async; > + > + if (!(ptr = list_head( &queue->queue ))) return; > + async = LIST_ENTRY( ptr, struct async, queue_entry ); > + > + if (!async->timeout || -timeout < get_timeout_user_remaining( async->timeout )) > + async_set_timeout( async, timeout, status ); > +} You should be able to do this in the serial code, probably by using absolute timeouts. Note that you also need to preserve the original timeout, you can't simply replace it by the interval timeout. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: server: Avoid infinite loop when we're out of timers in set_win_timer server call
by Alexandre Julliard 22 Jan '16

22 Jan '16

Piotr Caban <piotr(a)codeweavers.com> writes: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > server/queue.c | 12 ++++++++++-- > server/trace.c | 1 + > 2 files changed, 11 insertions(+), 2 deletions(-) A test case would be nice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] winebuild: Added support for entry points generated in runtime.
by Sebastian Lackner 22 Jan '16

22 Jan '16

On 19.01.2016 12:20, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > tools/winebuild/build.h | 1 + > tools/winebuild/parser.c | 1 + > tools/winebuild/spec32.c | 59 > ++++++++++++++++++++++++++++++++++++++++ > tools/winebuild/winebuild.man.in | 3 ++ > 4 files changed, 64 insertions(+) > I would also like to get this issue fixed, so I wouldn't complain if Alexandre really prefers the JIT approach, but I personally still do not really see a big advantage compared to static code generation. Let me quickly explain again why. I'll also send another mail to point a couple of issues with the current patch, but here again first the general discussion. * We have no way to implement support for 64-bit because SYSCALL instructions are directly part of the thunk. Unless we want to remove the "not" in the definition of "Wine is not an emulator", its technically impossible to intercept those Syscalls and we cannot implement it. * 32-bit Windows 8 thunks also cannot be implemented, with the same reason as 64-bit thunks. To see that, just take a look at the expected opcodes: // 00 b825000000 mov eax,25h // 05 e803000000 call eip+3 // 0a c22c00 ret 2Ch // 0d 8bd4 mov edx,esp // 0f 0f34 sysenter // 11 c3 ret // 12 8bff mov edi,edi And at the very strict verification: [...] CallEip != function_code.call_eip || function_code.call_offset != 3 [...] kSysenter != function_code.sysenter * Based on my knowledge, implementing WOW64 doesn't help much because we have no app which relies on it. Although their code technically would support it, it seems like Chromium and Steam never uses it in practice. At least during our testing so far, we haven't found a way to fix that. * Last but not least, one of the reasons why I haven't submitted my own approach so far: The whole idea only works reliable as long as we do NOT forward Ldr* functions to syscall thunks. If we do, like it should work on Windows, and like it is most likely required by other apps, there are race conditions all over the place and Steam webstore only works with a probability of about 50% or less. I haven't figured out what causes it yet. @ Alexandre: Do you have a preferrence? Suggestions we had so far: - JIT compilation of thunks (only x86) - Winebuild generated static thunks (see http://ix.io/nxT ) - Macro-generated thunks (see staging repo) To my knowledge, all have the same limitations: x86, non-wow64 and race-conditions when forwarding Ldr* functions through the syscall thunks. Best regards, Sebastian

6 15

Status of patch #118257
by Pierre Schweitzer 21 Jan '16

21 Jan '16

Hi, Is there anything wrong I can fix about patch #118257? Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Re: [PATCH 1/2] dwrite: Ask freetype once about kerning pairs support and monospaced property
by Alexandre Julliard 21 Jan '16

21 Jan '16

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/dwrite/font.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M dwrite.dll -p dwrite_test.exe.so font && touch font.ok font.c:3088: Test failed: got 0 font.c:3095: Test failed: got 0 font.c:5059: Tests skipped: Segoe UI Emoji font not found. font.c:5165: Tests skipped: Segoe UI Emoji font not found. Makefile:212: recipe for target 'font.ok' failed make[1]: *** [font.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH v2 1/1] ddraw/tests: Port test_lockrect_invalid to other versions.
by Marvin 21 Jan '16

21 Jan '16

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=19881 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2523: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2338: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit dsurface) === dsurface.c:144: Test failed: Destination data after blitting is not correct dsurface.c:178: Test failed: Destination data after blitting is not correct dsurface.c:357: Test failed: Surface data after srckey blit does not match dsurface.c:382: Test failed: Surface data after src override key blit does not match dsurface.c:436: Test failed: Surface data after dest key blit does not match dsurface.c:462: Test failed: Surface data after dest key override blit does not match dsurface.c:524: Test failed: Surface data with src key and dest key blit does not match === w1064 (32 bit ddraw1) === ddraw1.c:2187: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 4/8] d3d11: Handle NULL source box in d3d10_device_CopySubresourceRegion().
by Henri Verbeet 21 Jan '16

21 Jan '16

On 19 January 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -4002,15 +4002,25 @@ HRESULT CDECL wined3d_device_copy_sub_resource_region(struct wined3d_device *dev > } > src_surface = surface_from_resource(tmp); > > + if (src_box) > + { > + src_rect.left = src_box->left; > + src_rect.top = src_box->top; > + src_rect.right = src_box->right; > + src_rect.bottom = src_box->bottom; > + } > + else > + { > + src_rect.left = 0; > + src_rect.top = 0; > + src_rect.right = src_surface->resource.width; > + src_rect.bottom = src_surface->resource.height; > + } That's mostly what surface_get_rect() does, except that it doesn't take a wined3d_box structure, of course. wined3d_surface_blt() can handle a NULL src_rect though, so you don't need to do it here. It may make sense to require callers to pass a non-NULL wined3d_box to wined3d_texture_blt(). I think that everything that calls wined3d_surface_blt() or wined3d_texture_blt() should have easy access to the surface dimensions. That's a bit more involved because there are callers outside wined3d though.

2 2

Re: [PATCH 2/3] oleaut32: BSTRs should have 8 byte alignment on 64 bits.
by Jacek Caban 21 Jan '16

21 Jan '16

On 01/21/16 11:29, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/oleaut32/oleaut.c | 3 +++ > dlls/oleaut32/tests/vartype.c | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index 8a22c2e..07db9ff 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -84,6 +84,9 @@ static CRITICAL_SECTION_DEBUG cs_bstr_cache_dbg = > static CRITICAL_SECTION cs_bstr_cache = { &cs_bstr_cache_dbg, -1, 0, 0, 0, 0 }; > > typedef struct { > +#ifdef _WIN64 > + DWORD pad; > +#endif > DWORD size; > union { > char ptr[1]; How about changing size type to SIZE_T instead? This should have the same effect. Thanks, Jacek

2 1

Re: [PATCH] server: Implement serial port read interval timeouts.
by Alexandre Julliard 21 Jan '16

21 Jan '16

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Fixes https://bugs.winehq.org/show_bug.cgi?id=39875 > > There is a test program attached to the bug report. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > server/async.c | 13 +++++++++++++ > server/fd.c | 6 ++++++ > server/file.h | 2 ++ > server/serial.c | 3 +++ > 4 files changed, 24 insertions(+) That's a good start, but I think you should be able to do it through the reselect_async fd operation, without making changes to the generic async code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] ddraw/tests: Port test_lockrect_invalid to other versions (v2).
by Marvin 21 Jan '16

21 Jan '16

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=19863 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2523: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2338: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit dsurface) === dsurface.c:144: Test failed: Destination data after blitting is not correct dsurface.c:178: Test failed: Destination data after blitting is not correct dsurface.c:357: Test failed: Surface data after srckey blit does not match dsurface.c:382: Test failed: Surface data after src override key blit does not match dsurface.c:436: Test failed: Surface data after dest key blit does not match dsurface.c:462: Test failed: Surface data after dest key override blit does not match dsurface.c:524: Test failed: Surface data with src key and dest key blit does not match === w1064 (32 bit ddraw1) === ddraw1.c:2187: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: Updated WineHQ.org
by Theodore Dubois 20 Jan '16

20 Jan '16

You are allowed to use table layout (i.e: display: table, display: table-cell, etc.) Just not <table> tags. ~Theodore > On Jan 20, 2016, at 11:53 AM, Jeremy Newman <jnewman(a)codeweavers.com> wrote: > > This is why I miss using tables for HTML layout. This kind of problem was easy to solve with tables. But Nooooo tables are bad now. :-| > > I only applied my resize handler to the right side. I could apply it to the left side as well, but I think that will cause issues as the two sides fight over who should be the correct height. > > On 01/20/2016 01:44 PM, Ruslan Kabatsayev wrote: >> On Wed, Jan 20, 2016 at 10:19 PM, Jeremy Newman <jnewman(a)codeweavers.com> wrote: >>> On 01/20/2016 12:10 AM, Ruslan Kabatsayev wrote: >>>> >>>> Current version makes the Download/Support/Development/Donate block >>>> have twice the needed height with my 782px wide Chromium window, i.e. >>>> has empty space under the links. >>> >>> >>> This is by design. I added some jquery-fu to make sure that box was the same >>> height as the two boxes to the left of it. I think this looks better than a >>> larger empty black space under it. >>> >>> I do notice that at that width that the Development link does get a bit too >>> close to the edge of the box. Perhaps I should shrink down the font size by >>> a couple of px. >> >> OK, that thing was due my too old Chromium, it appears not >> reproducible with current versions. >> >> The jquery-fu though seems to not always work, namely with zoomed out >> page, see "zoomed" attachment (zoom is 50% there). This remains true >> with up-to-date Chromium and Firefox. >> >>> >>> -N > >

1 0

Updated WineHQ.org
by Jeremy Newman 20 Jan '16

20 Jan '16

I have updated the WineHQ.org main website with a new mobile friendly (bootstrap based) theme. The goal was the preserve the old look somewhat, while bringing it up to modern standards. I've ported most of the existing translations for the home page. Sub-pages will need to be updated. Translators, please update your sub-pages. Please update download.template first. -N

3 6

WWN?
by André Hentschel 20 Jan '16

20 Jan '16

Hi, As you might have noticed, I lost time and motivation to do WWN. Someone out there to continue it? Then I would cleanup the tools for it and guide her/him into using them.

1 0

Re: [PATCH 1/2] d3drm: Fix QueryInterface for IDirect3DRMTexture* (v2).
by Henri Verbeet 20 Jan '16

20 Jan '16

On 19 January 2016 at 15:29, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > WARN("%s not implemented, returning E_NOINTERFACE.\n", debugstr_guid(riid)); > - return E_NOINTERFACE; > + return CLASS_E_CLASSNOTAVAILABLE; I missed this in the original patch as well, but now the message doesn't match the return value. These two patches seem fine otherwise.

2 1

Re: [2/2] comctl32: Don't update the status if the item is no longer valid.
by Nikolay Sivov 20 Jan '16

20 Jan '16

On 19.01.2016 17:45, Akihiro Sagawa wrote: > > This fixes https://bugs.winehq.org/show_bug.cgi?id=39677 > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/comctl32/listview.c | 2 +- > dlls/comctl32/tests/listview.c | 22 ++++++++++++++++++++++ > 2 files changed, 23 insertions(+), 1 deletion(-) > I think this is correct, but to make sure I fully understand what's going on. The idea is to return early from _SetItemT() for the case when old focused item index is larger than current number items in a list? >From reading surrounding code, it looks like application will receive state notifications for item number that's no longer valid, am I right? > + /* The focused item isn't updated after the invalidation */ The opposite is true, focused item is updated in this new test, from 0 to -1 (nothing focused), please fix this comment to reflect that. > comctl32: Don't update the status if the item is no longer valid. Subject needs some adjusting to, something like "Prevent invalid focuse change notifications from LVS_OWNERDATA lists", or similar. Right now it's not clear what 'status' and 'item' mean in this context. Thanks for debugging this.

2 1

Re: [PATCH] ntoskrnl.exe: Implement ZwLoadDriver and ZwUnloadDriver
by Dmitry Timoshkov 20 Jan '16

20 Jan '16

Aric Stewart <aric(a)codeweavers.com> wrote: > Code is mostly moved from winedevice.exe > winedevice.exe now uses these functions > > With consultation and help from Damjan Jovanovic This code is broken in so many ways, so I woudn't bother listing them all. -- Dmitry.

2 1

Re: [PATCH] d2d1: Don't update target dpi if only one SetDpi() argument is zero
by Henri Verbeet 20 Jan '16

20 Jan '16

On 19 January 2016 at 22:43, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > @@ -1436,6 +1436,8 @@ static void STDMETHODCALLTYPE d2d_d3d_render_target_SetDpi(ID2D1RenderTarget *if > dpi_x = 96.0f; > dpi_y = 96.0f; > } > + else if (dpi_x == 0.0f || dpi_y == 0.0f) > + return; > Should this affect rendertarget creation (i.e., d2d_d3d_render_target_init()) as well? What about bitmap creation?

2 1

Re: [PATCH 1/8] wined3d: Do not update surface when empty box is passed.
by Henri Verbeet 20 Jan '16

20 Jan '16

On 19 January 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > if (box->left >= box->right || box->right > sub_resource->width > - || box->top >= box->bottom || box->bottom > sub_resource->height) > + || box->top >= box->bottom || box->bottom > sub_resource->height > + || box->front >= box->back) It seems likely that you'll need to validate box->back against sub_resource->depth as well, although you may need 3D textures for a reliable test.

1 0

Re: [PATCH 1/3] msvcrt: Fix size test of structure returned by _Gettnames
by Marvin 20 Jan '16

20 Jan '16

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=19825 Your paranoid android. === w1064 (32 bit locale) === locale.c:461: Test failed: ret = Norwegian Bokmål_Norway.1252 locale.c:468: Test failed: ret = Norwegian Bokmål_Norway.1252

2 1

Re: winspool.drv: add EnumPrinterKeyA/W stubs (try 2)
by Huw Davies 20 Jan '16

20 Jan '16

On Tue, Jan 19, 2016 at 03:45:32PM -0600, Austin English wrote: > diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c > index 04def86..06fa2a2 100644 > --- a/dlls/winspool.drv/info.c > +++ b/dlls/winspool.drv/info.c > @@ -7527,6 +7527,26 @@ DWORD WINAPI EnumPrinterDataW( HANDLE hPrinter, DWORD dwIndex, LPWSTR pValueName > } > > /***************************************************************************** > + * EnumPrinterKeyA [WINSPOOL.@] > + * > + */ > +DWORD WINAPI EnumPrinterKeyA(HANDLE printer, const CHAR *key, CHAR *subkey, DWORD size, DWORD *ret) 'needed' is probably better than 'ret'. > +{ > + FIXME("%p %s %s %x %p\n", printer, debugstr_a(key), debugstr_a(subkey), size, ret); subkey is an [out] param, so just print the ptr. Same goes for the spec file. Huw.

1 0

Re: hidclass.sys: Properly quit hid_device_thread when both completion event and halt event are signaled (try 3)
by Aric Stewart 20 Jan '16

20 Jan '16

Sorry for the late reply, I have lost this e-mail as well. + rc = WaitForSingleObject(ext->halt_event, 0) You appear to be missing a ; This does not compile. did you even test that before sending in the patch? Otherwise the patch looks fine. -aric

2 1

Re: [2/2] shell32/tests: Call okShell() after a shell_execute{_ex}() test.
by Marvin 20 Jan '16

20 Jan '16

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=19814 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2333: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt206D.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt206D.tmp\test file.sde")]' shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2

1 0

Re: [1/2] shell32/tests: Trace the last ShellExecute command whenever a corresponding test fails.
by Marvin 20 Jan '16

20 Jan '16

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=19813 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2340: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde")]' shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1298.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1298.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1298.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1298.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: [PATCH v2] ole32: The type of the size of IMalloc'ed blocks is SIZE_T.
by Alexandre Julliard 19 Jan '16

19 Jan '16

Huw Davies <huw(a)codeweavers.com> writes: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/ole32/ifs.c | 48 +++++++++++++++++++++++++----------------------- > include/objbase.h | 4 ++-- > include/objidl.idl | 18 +++++++++--------- > 3 files changed, 36 insertions(+), 34 deletions(-) There are more interfaces like IMimeAllocator that derive from IMalloc that need fixing too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ole32: The type of the size of IMalloc'ed blocks is SIZE_T.
by Dmitry Timoshkov 19 Jan '16

19 Jan '16

Huw Davies <huw(a)codeweavers.com> wrote: > -static HRESULT WINAPI IMalloc_fnQueryInterface(LPMALLOC iface,REFIID refiid,LPVOID *obj) { > - > +static HRESULT WINAPI IMalloc_fnQueryInterface(LPMALLOC iface,REFIID refiid,LPVOID *obj) > +{ Since basically every method entry is being changed, why not get rid of LPMALLOC as well? -- Dmitry.

2 1

Re: [PATCH 2/3] winex11: Don't recompute string length in remove_startup_notification.
by Alexandre Julliard 19 Jan '16

19 Jan '16

Alex Henrie <alexhenrie24(a)gmail.com> writes: > The string length was computed during the loop earlier in the function. > There is no need to call the O(n) strlen function to compute it again. Saving a couple of cycles in a function that is executed at most once is irrelevant, and not worth the code churn. Please avoid such "optimizations". -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] winebuild: Added support for entry points generated in runtime.
by Sebastian Lackner 19 Jan '16

19 Jan '16

On 19.01.2016 12:20, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > tools/winebuild/build.h | 1 + > tools/winebuild/parser.c | 1 + > tools/winebuild/spec32.c | 59 > ++++++++++++++++++++++++++++++++++++++++ > tools/winebuild/winebuild.man.in | 3 ++ > 4 files changed, 64 insertions(+) > > > > 0001-winebuild-Added-support-for-entry-points-generated-in.diff > > > diff --git a/tools/winebuild/build.h b/tools/winebuild/build.h > index e32e7a9..2d5a162 100644 > --- a/tools/winebuild/build.h > +++ b/tools/winebuild/build.h > @@ -171,6 +171,7 @@ struct strarray > #define FLAG_REGISTER 0x10 /* use register calling convention */ > #define FLAG_PRIVATE 0x20 /* function is private (cannot be imported) */ > #define FLAG_ORDINAL 0x40 /* function should be imported by ordinal */ > +#define FLAG_JIT 0x80 /* function is generated at runtime */ > > #define FLAG_FORWARD 0x100 /* function is a forwarded name */ > #define FLAG_EXT_LINK 0x200 /* function links to an external symbol */ > diff --git a/tools/winebuild/parser.c b/tools/winebuild/parser.c > index 1d7b84e..c42fceb 100644 > --- a/tools/winebuild/parser.c > +++ b/tools/winebuild/parser.c > @@ -69,6 +69,7 @@ static const char * const FlagNames[] = > "register", /* FLAG_REGISTER */ > "private", /* FLAG_PRIVATE */ > "ordinal", /* FLAG_ORDINAL */ > + "jit", /* FLAG_JIT */ > NULL > }; > > diff --git a/tools/winebuild/spec32.c b/tools/winebuild/spec32.c > index cb56abe..ebce6b4 100644 > --- a/tools/winebuild/spec32.c > +++ b/tools/winebuild/spec32.c > @@ -270,6 +270,60 @@ static void output_relay_debug( DLLSPEC *spec ) > } > } > > +static void output_jit_descs( DLLSPEC *spec ) > +{ > + int i, emited_descs = 0, jit_cnt = 0; No native english speaker here, but shouldn't it be "emitted" ? > + char **jit_entries, *sym_name; > + ORDDEF *odp; > + > + if (target_cpu != CPU_x86) > + return; > + > + for (odp = spec->entry_points; odp < spec->entry_points + spec->nb_entry_points; odp++) > + if (odp->flags & FLAG_JIT) > + jit_cnt++; This code should probably ignore spec entries with FLAG_FORWARD. Generating thunks wouldn't make sense then. Also, winebuild should probably complain when non-stdcall functions use -jit. > + if (!jit_cnt) > + return; > + > + jit_entries = xmalloc( jit_cnt*sizeof(*jit_entries) ); > + > + output( "\t.data\n" ); > + output( "%s\n", asm_globl("__wine_jit_descs") ); > + > + for (odp = spec->entry_points; odp < spec->entry_points + spec->nb_entry_points; odp++) { Minor issue, but coding style in winebuild usually has "{" on the next line. There are a couple more minor style issues in the next lines, like missing space inbetween of "(...)" and arguments. > + if (!(odp->flags & FLAG_JIT)) > + continue; > + > + for (i=0; i < emited_descs; i++) { > + if (!strcmp(odp->link_name, jit_entries[i])) > + break; > + } > + if (i < emited_descs) > + continue; /* already emited */ > + jit_entries[emited_descs] = odp->link_name; > + > + output( "\t%s %s\n", get_asm_ptr_keyword(), asm_name(odp->link_name) ); > + output( "\t.long %u\n", get_args_size(odp) ); > + emited_descs++; > + } > + > + output( "\t%s 0\n", get_asm_ptr_keyword() ); > + output( "\t.long 0\n" ); You should use .previous here to restore the previous section. > + > + output("\t.text\n" ); > + output( "%s\n", asm_globl("__wine_jit_entries") ); > + > + for (i=0; i < emited_descs; i++) { > + sym_name = strmake( "__jit_%s", jit_entries[i] ); > + output( "%s\n", asm_globl(sym_name) ); > + free( sym_name ); > + > + output( "\t.long 0\n\t.long 0\n\t.long 0\n\t.long 0\n" ); You might want to to emit .cfi_startproc and .cgi_endproc CFI directives here, to ensure debuggers and unwinding code can split it into separate functions. Also, you might want to use output_function_size(). > + } Same as above, you should add a ".restore" here. > + > + free(jit_entries); > +} > + > /******************************************************************* > * output_exports > * > @@ -332,6 +386,10 @@ void output_exports( DLLSPEC *spec ) > output( "\t%s %s_%s\n", > get_asm_ptr_keyword(), asm_name("__wine_spec_ext_link"), odp->link_name ); > } > + else if (target_cpu == CPU_x86 && (odp->flags & FLAG_JIT)) > + { > + output( "\t%s %s_%s\n", get_asm_ptr_keyword(), asm_name("__jit"), odp->link_name ); > + } > else > { > output( "\t%s %s\n", get_asm_ptr_keyword(), asm_name(odp->link_name) ); > @@ -622,6 +680,7 @@ void BuildSpec32File( DLLSPEC *spec ) > output_stubs( spec ); > output_exports( spec ); > output_imports( spec ); > + output_jit_descs( spec ); > if (is_undefined( "__wine_call_from_regs" )) output_asm_relays(); > output_resources( spec ); > output_gnu_stack_note(); > diff --git a/tools/winebuild/winebuild.man.in b/tools/winebuild/winebuild.man.in > index 2063738..2905bac 100644 > --- a/tools/winebuild/winebuild.man.in > +++ b/tools/winebuild/winebuild.man.in > @@ -299,6 +299,9 @@ accessed through GetProcAddress. > The entry point will be imported by ordinal instead of by name. The > name is still exported. > .TP > +.B -jit > +The function body will be generated in runtime. For internal Wine usage only. > +.TP > .BI -arch= cpu\fR[\fB,\fIcpu\fR] > The entry point is only available on the specified CPU > architecture(s). The names \fBwin32\fR and \fBwin64\fR match all > > >

1 0

Re: [PATCH 1/3] winebuild: Added support for entry points generated in runtime.
by Marcus Meissner 19 Jan '16

19 Jan '16

On Tue, Jan 19, 2016 at 12:20:30PM +0100, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> I am curious ... for what is this needed? Ciao, Marcus

2 1

Re: [PATCH] winex11: Avoid inefficiency and overflow in remove_startup_notification.
by Alex Henrie 19 Jan '16

19 Jan '16

Could I get some feedback on this patch? I'd rather not have it drop off the list a second time, especially since Vincent already signed off on it: https://www.winehq.org/pipermail/wine-patches/2015-November/144119.html -Alex

2 1

Re: [PATCH 2/2] d3drm/tests: Add QueryInterface tests for IDirect3DRMTexture*.
by Henri Verbeet 19 Jan '16

19 Jan '16

On 18 January 2016 at 19:57, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > + char *file = NULL; Why do you initialize this to NULL? > + BOOL check; > + > + > + hr = Direct3DRMCreate(&d3drm1); The extra empty line is weird. Is that intentional? > + file = create_bitmap(1, 1, TRUE); > + hr = IDirect3DRM_LoadTexture(d3drm1, file, &texture1); I think "file" is a bad name. I'd expect that to be a file handle or descriptor, not a string. > + ok(SUCCEEDED(hr), "Failed to load texture (hr = %x).\n", hr); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMTexture interface (hr = %x)\n", hr); This looks like it was leftover from somewhere, but in either case it doesn't test what the message says it's testing. It's fairly harmless here, but %x is a bad format in most cases. E.g., is "1000" decimal 4096 or decimal 1000? Just use %#x. Ideally you'd also use the same message format as the other D3D tests. > + check = DeleteFileA(file); > + ok(check, "Cannot delete image stored in %s (error = %d).\n", file, GetLastError()); > +} You're leaking "file".

2 1

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