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

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

COM tracing ...
by Michael Meeks Aug. 21, 2018

Aug. 21, 2018

Hi guys, Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help. I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting. I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick. https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d… Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-) Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when ! Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? Anyhow - help much appreciated & sorry for the noise ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot

2 4

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

Re: [PATCH] server_ioctl_file() - Prefix printed hex values with '0x'
by Alexandre Julliard Oct. 12, 2017

Oct. 12, 2017

Chris Morgan <chmorgan(a)gmail.com> writes: > Avoids the ambiguity with non-alphanumeric hex values. > > Signed-off-by: Chris Morgan <chmorgan(a)gmail.com> > --- > dlls/ntdll/file.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index fd7f3dd..4d081b7 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -1567,7 +1567,7 @@ static NTSTATUS server_ioctl_file( HANDLE handle, HANDLE event, > SERVER_END_REQ; > > if (status == STATUS_NOT_SUPPORTED) > - FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n", > + FIXME("Unsupported ioctl 0x%x (device=0x%x access=0x%x func=0x%x method=0x%x)\n", That's mostly a matter of taste, so I don't think it's necessary to change it. -- Alexandre Julliard julliard(a)winehq.org

3 2

Wine Swag Sticker Poll
by Aric Stewart Oct. 10, 2017

Oct. 10, 2017

Hello! So all the way back at wineconf I volunteered to be swag master for winehq. The idea is to have something that can be given away at trade shows, presentations, LUG visits and the like. Just something to help promote the visibility of the project. Jana here, CodeWeavers marketing director, has put together a sampling of designs to do as our first sticker and so now we are looking for some feedback on what people prefer. https://docs.google.com/forms/d/e/1FAIpQLSd5X_fXe9KSFAppRHz8kUo3XKeODyH5KeX… Rosanne? Could you direct me as to where this should be put up for the users as well? I am unfamiliar with how to communicate to our user base. The poll will run for as long as it feels like it needs to get some sort of winner. Comments and suggestions are always welcome! -aric

7 10

Re: shell32: Implement SHCreateItemInKnownFolder.
by Huw Davies Aug. 4, 2017

Aug. 4, 2017

On Sun, Jul 30, 2017 at 05:37:02PM +0800, Jactry Zeng wrote: > diff --git a/dlls/shell32/shellitem.c b/dlls/shell32/shellitem.c > index 1e19f7c72e..57fb849f16 100644 > --- a/dlls/shell32/shellitem.c > +++ b/dlls/shell32/shellitem.c > @@ -662,6 +662,66 @@ HRESULT WINAPI SHCreateItemFromIDList(PCIDLIST_ABSOLUTE pidl, REFIID riid, void > return ret; > } > > +HRESULT WINAPI SHCreateItemInKnownFolder(REFKNOWNFOLDERID rfid, DWORD flags, > + LPWSTR filename, REFIID riid, void **ppv) > +{ > + HRESULT hr; > + WCHAR *pathW = NULL; > + IShellFolder *desktop = NULL, *folder = NULL; > + LPITEMIDLIST pidl_folder = NULL, pidl = NULL; > + > + TRACE("%p, %x, %s, %s, %p\n", rfid, flags, wine_dbgstr_w(filename), > + debugstr_guid(riid), ppv); > + > + if(!rfid || !ppv) > + return E_INVALIDARG; > + > + if(flags) > + FIXME("flags 0x%08x not supported\n", flags); > + > + *ppv = NULL; > + hr = SHGetDesktopFolder(&desktop); > + if(hr != S_OK) return hr; > + > + hr = SHGetKnownFolderPath(rfid, 0, NULL, &pathW); > + if(hr != S_OK) return hr; > + > + hr = IShellFolder_ParseDisplayName(desktop, NULL, NULL, pathW, NULL, &pidl_folder, NULL); > + if(hr != S_OK) > + goto cleanup; You probably want to use SHGetKnownFolderIDList() instead of these last two calls. Huw.

2 3

Re: [5/6] wsdapi: Add support for sending messages via UDP multicast.
by Vincent Povirk Aug. 1, 2017

Aug. 1, 2017

+ delay = rand() % (UDP_MAX_DELAY - UDP_MIN_DELAY + 1) + UDP_MIN_DELAY; Using rand() for this doesn't seem very random, and it could interfere with an application's use of rand(). + /* Get size of buffer for adapters */ + adapterAddresses = (IP_ADAPTER_ADDRESSES *) HeapAlloc(heap, 0, bufferSize); Was this comment meant to be earlier? Sending messages to every adapter in sequence, with a delay for each, doesn't seem right. +void terminate_networking(IWSDiscoveryPublisherImpl *impl) +{ + impl->publisherStarted = FALSE; + + WSACleanup(); +} It seems like this will call WSACleanup even when freeing an object that was never used.

2 1

Re: [2/6] wsdapi: Add code to create SOAP envelope from header and body elements.
by Vincent Povirk Aug. 1, 2017

Aug. 1, 2017

+ wideStringLength = lstrlenW(wideString); + sizeNeeded = WideCharToMultiByte(CP_UTF8, 0, wideString, wideStringLength, NULL, 0, NULL, NULL); + + if (sizeNeeded < 0) + { + return NULL; + } + + newString = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeNeeded + 1); + WideCharToMultiByte(CP_UTF8, 0, wideString, wideStringLength, newString, sizeNeeded, NULL, NULL); This would be much simpler if you passed in -1 as the wide string length. Using HEAP_ZERO_MEMORY to null-terminate the string is a bit weird. + else if (curNode->Type == TextType) + { + textNode = WSDAllocateLinkedMemory(parent, sizeof(WSDXML_TEXT)); + if (textNode == NULL) goto cleanup; + + textNode->Node.Next = NULL; + textNode->Node.Parent = parent; + textNode->Node.Type = TextType; + textNode->Text = duplicate_string(textNode, ((WSDXML_TEXT *)curNode)->Text); + if (textNode->Text == NULL) goto cleanup; + } I'm not sure, but I think you need to add textNode as a child of newElement? + /* SequenceID attribute */ + if (header->AppSequence->SequenceId != NULL) + { + if (!add_string_attribute(xmlContext, appSequenceElement, discoveryNsUri, sequenceIdString, header->AppSequence->SequenceId)) goto cleanup; + } Do we need the namespace for SequenceID?

2 3

Re: [PATCH] kernel32: Load library search in system32 directory.
by Carlos Palminha Aug. 1, 2017

Aug. 1, 2017

On 31-07-2017 18:50, Alexandre Julliard wrote: > Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: > >> On 31-07-2017 17:54, Alexandre Julliard wrote: >>> Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: >>> >>>> Hi Alexandre, >>>> >>>> I tested with iTunes installation that was crashing when calling load_libraryin my system. After the patch it was ok. Probably not enough indicator that was working properly in all systems. >>>> >>>> I will send a second version calling GetWindowsDirectory instead of using %windows%. >>>> >>>> Regarding the other cases, when using the flag >>>> LOAD_LIBRARY_SEARCH_SYSTEM32, directories in the standard search path >>>> are not searched and the value cannot be combined with >>>> LOAD_WITH_ALTERED_SEARCH_PATH. The search path is reduced to >>>> windows\system32, right? Or probably i need to append >>>> %windows&\system32 to the existing path... >>> >>> If you only specify SEARCH_SYSTEM32 the path is reduced to that, but you >>> could also have other flags like SEARCH_APPLICATION_DIR, >>> SEARCH_DLL_LOAD_DIR, etc. You can't handle just one flag and ignore the >>> others. >>> >> >> All the other cases SEARCH_APPLICATION_DIR, SEARCH_DEFAULT_DIRS, SEARCH_DLL_LOAD_DIR and SEARCH_USER_DIRS are not yet supported (unsopported flags). >> So at this moment LOAD_LIBRARY_SEARCH_* are reduced to ALTERED_SEARCH_PATH or SEARCH_SYSTEM32. > > They are not supported now, but if you add one you have to add the > others, otherwise dlls are going to fail to load because you are > searching only system32. > I think today its working for some of those unsupported flags because it's a side effect of calling MODULE_get_dll_load_path with NULL. Probably using only system32 path it might break some of the application that are working based on a side effect. Nevertheless i run the existing tests for module and its ok. I will look at it and add the other SEARCH flags. If i check the other flags then there is no need to fallback to MODULE_get_dll_load_path(NULL), do you agree? Regards, C.Palminha

2 3

Re: [4/6] wsdapi: Implement "Hello" message creation support.
by Vincent Povirk July 31, 2017

July 31, 2017

- obj = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*obj)); + heap = GetProcessHeap(); + obj = HeapAlloc(heap, HEAP_ZERO_MEMORY, sizeof(*obj)); I really hope we don't have to start optimizing for fewer GetProcessHeap calls. + /* Calculate space needed, including colon and potential trailing space */ + memoryNeeded = sizeof(WCHAR) * (lstrlenW(cur->Element->LocalName) + lstrlenW(cur->Element->Space->PreferredPrefix) + 2); This doesn't account for the terminating NULL wsprintfW will add. + discoveredNamespaces = WSDAllocateLinkedMemory(NULL, sizeof(struct list)); + if (!discoveredNamespaces) goto cleanup; Why not allocate this on the stack?

2 1

Re: [PATCHv2] msvcrt: Export -f suffixed float functions functions on arm64
by Piotr Caban July 31, 2017

July 31, 2017

Hi Why do you need it? Is there native arm64 version of the dlls (I've seen some announcements but is it already available)? Or is it only for winelib applications? Thanks, Piotr

2 1

Re: [PATCH] kernel32: Load library search in system32 directory.
by Alexandre Julliard July 31, 2017

July 31, 2017

Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: > Use %windows%\system32 directory to search for the DLL. > Standard search path is not used. > > Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> > --- > dlls/kernel32/module.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) %windows% cannot possibly work, environment variables are not expanded, and even if they were, there's no such variable. How did you test this? Also it's possible to specify multiple flags, this needs to be integrated properly in the code that builds the search path. -- Alexandre Julliard julliard(a)winehq.org

2 3

[PATCH] kernel32: Load library search in system32 directory.
by Carlos Palminha July 31, 2017

July 31, 2017

Use %windows%\system32 directory to search for the DLL. Standard search path is not used. Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> --- dlls/kernel32/module.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/dlls/kernel32/module.c b/dlls/kernel32/module.c index badfe1d175..aff5097664 100644 --- a/dlls/kernel32/module.c +++ b/dlls/kernel32/module.c @@ -915,13 +915,19 @@ static HMODULE load_library( const UNICODE_STRING *libname, DWORD flags ) LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_APPLICATION_DIR | LOAD_LIBRARY_SEARCH_USER_DIRS | - LOAD_LIBRARY_SEARCH_SYSTEM32 | LOAD_LIBRARY_SEARCH_DEFAULT_DIRS; if( flags & unsupported_flags) FIXME("unsupported flag(s) used (flags: 0x%08x)\n", flags); - load_path = MODULE_get_dll_load_path( flags & LOAD_WITH_ALTERED_SEARCH_PATH ? libname->Buffer : NULL ); + if (flags & LOAD_LIBRARY_SEARCH_SYSTEM32) { + WCHAR spath[] = {'%','w','i','n','d','o','w','s','%','\\','s','y','s','t','e','m','3','2',0}; + int slen = (strlenW(spath) + 1) * sizeof(WCHAR); + load_path = HeapAlloc(GetProcessHeap(), 0, slen); + memcpy (load_path, spath, slen); + } else { + load_path = MODULE_get_dll_load_path( flags & LOAD_WITH_ALTERED_SEARCH_PATH ? libname->Buffer : NULL ); + } if (flags & LOAD_LIBRARY_AS_DATAFILE) { -- 2.11.0

1 0

Re: [PATCH] wined3d: Don't enable GL_EXT_geometry_shader4 on OpenGL >3.1
by Henri Verbeet July 31, 2017

July 31, 2017

On 31 July 2017 at 08:13, Zach Mertes <techiezach(a)gmail.com> wrote: > GL_EXT_geometry_shader4's features are intrinsically enabled on OpenGL > 3.1 and newer. > Enabling it past 3.1 causes an annoying GLSL warning. > Against what version of Wine is this written? While it's correct that we don't (ever) want to use EXT_geometry_shader4, Wine has never used that extension. We initially used ARB_geometry_shader4 and later dropped it in favour of the 3.2 core profile.

1 0

UIRibbon
by Fabian Maurer July 30, 2017

July 30, 2017

Hi Wine-Devel, I'm currently working on a patchset to get UIRibbon to work, or at least to not crash the program. I noticed that the ribbon xml files need to be compiled with a program called UICC.exe from the windows SDK, the resulting resources have some proprietary binary format. If we want to load and display a ribbon, we'll have to understand it. Does anyone know about information on that, or is the only way to reverse engineer it? Regards, Fabian Maurer

2 2

Re: [PATCH v4 2/3] uiribbon: Add interface definitions
by Alistair Leslie-Hughes July 30, 2017

July 30, 2017

Hi Fabian, Besides the below issues, the patches look good. On 30/07/17 09:29, Fabian Maurer wrote: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > +[ > + object, > + uuid(D428903C-729A-491d-910D-682A08FF2522), Please make the uuid lowercase ... > +[ > + object, > + uuid(F4F0385D-6872-43a8-AD09-4C339CB3F5C5), > + local, > + pointer_default(unique) Please make the uuid lowercase Also, could you please get rid of the LPVOID in the third patch. Best Regards Alistair Leslie-Hughes

1 0

Re: [PATCH v3 2/3] uiribbon: Add interface definitions
by Alistair Leslie-Hughes July 29, 2017

July 29, 2017

Hi Fabian, On 30/07/17 06:36, Fabian Maurer wrote: > Code taken and adapted from d3dxof. > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/uiribbon/Makefile.in | 2 + > dlls/uiribbon/uiribbon_classes.idl | 21 +++++ These changes don't make any sense for this patch. Move them to the third patch in which the interfaces are registered. Besides this, everything looks ok. Best Regards Alistair

1 0

Re: [PATCH 1/3] uiribbon: Add DLL
by Alistair Leslie-Hughes July 28, 2017

July 28, 2017

Hi Fabian, This is about the series of uiribbon. >+BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) Since nothing is implemented in this dll, please return check for DLL_WINE_PREATTACH. (example dlls/authz/authz.c). In this patch you could also add the private functions. patch 2. > + uiribbon.idl \ ... >interface IUIFramework : IUnknown >+{ >+ >+} >+ If your going to add a idl file, please fill in methods available for each interface. Please also avoid the forward declare for IUIApplication include it in the idl as well. >+ >+HRESULT UIRibbonFrameworkImpl_Create(IUnknown* pUnkOuter, LPVOID* ppObj)l; Move this function to after +static const IUIFrameworkVtbl IUIFramework_Vtbl = then you wont need the forward declare. I would have the following patches. 1. Add new dll (DLLMain and private functions) 2. Add idl to include (Including all the interfaces required) 3. Add the stubbed interface. 4. Tests? (maybe not possible at this stage). Best Regards Alistair Leslie-Hughes

2 3

[PATCH v7 00/26] x86: Enable User-Mode Instruction Prevention
by Ricardo Neri July 28, 2017

July 28, 2017

This is v7 of this series. The six previous submissions can be found here [1], here [2], here[3], here[4], here[5] and here[6]. This version addresses the comments received in v6 plus improvements of the handling of exceptions unrelated to UMIP as well as corner cases in virtual-8086 mode. Please see details in the change log. === What is UMIP? User-Mode Instruction Prevention (UMIP) is a security feature present in new Intel Processors. If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0. If these instructions were executed while in CPL > 0, user space applications could have access to system-wide settings such as the global and local descriptor tables, the segment selectors to the current task state and the local descriptor table. Hiding these system resources reduces the tools available to craft privilege escalation attacks such as [7]. These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register If any of these instructions is executed with CPL > 0, a general protection exception is issued when UMIP is enabled. === How does it impact applications? We want to have UMIP enabled by default. However, UMIP will change the behavior that certain applications expect from the operating system. For instance, programs running on WineHQ and DOSEMU2 rely on some of these instructions to function. Stas Sergeev found that Microsoft Windows 3.1 and dos4gw use the instruction SMSW when running in virtual-8086 mode[8]. SGDT and SIDT can also run on virtual-8086 mode. In order to not change the behavior of the system. This patchset emulates the SGDT, SIDT and SMSW. This should be sufficient to not break the applications mentioned above. Regarding the two remaining instructions, STR and SLDT, the WineHQ team has shown interest catching the general protection fault and use it as a vehicle to fix broken applications[9]. Furthermore, STR and SLDT can only run in protected and long modes. DOSEMU2 emulates virtual-8086 mode via KVM. No applications will be broken unless DOSEMU2 decides to enable the CR4.UMIP bit in platforms that support it. Also, this should not pose a security risk as no system resouces would be revealed. Instead, code running inside the KVM would only see the KVM's GDT, IDT and MSW. Please note that UMIP is always enabled for both 64-bit and 32-bit Linux builds. However, emulation of the UMIP-protected instructions is not done for 64-bit processes. 64-bit user space applications will receive the SIGSEGV signal when UMIP instructions causes a general protection fault. === How are UMIP-protected instructions emulated? This version keeps UMIP enabled at all times and by default. If a general protection fault caused by the instructions protected by UMIP is detected, such fault will be fixed-up by returning dummy values as follows: * SGDT and SIDT return hard-coded dummy values as the base of the global descriptor and interrupt descriptor tables. These hard-coded values correspond to memory addresses that are near the end of the kernel memory map. This is also the case for virtual-8086 mode tasks. In all my experiments in x86_32, the base of GDT and IDT was always a 4-byte address, even for 16-bit operands. Thus, my emulation code does the same. In all cases, the limit of the table is set to 0. * SMSW returns the value with which the CR0 register is programmed in head_32/64.S at boot time. This is, the following bits are enabled: CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for Extension Type, which will always be 1 in recent processors with UMIP; CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment Mask. As per the Intel 64 and IA-32 Architectures Software Developer's Manual, SMSW returns a 16-bit results for memory operands. However, when the operand is a register, the results can be up to CR0[63:0]. Since the emulation code only kicks-in in x86_32, we return up to CR[31:0]. * The proposed emulation code is handles faults that happens in both protected and virtual-8086 mode. * Again, STR and SLDT are not emulated. === How is this series laid out? ++ Preparatory work As per suggestions from Andy Lutormirsky and Borislav Petkov, I moved the x86 page fault error codes to a header. Also, I made user_64bit_mode available to x86_32 builds. This helps to reuse code and reduce the number of #ifdef's in these patches. ++ Fix bugs in MPX address evaluator I found very useful the code for Intel MPX (Memory Protection Extensions) used to parse opcodes and the memory locations contained in the general purpose registers when used as operands. I put some of this code in a separate library file that both MPX and UMIP can access and avoid code duplication. Before creating the new library, I fixed a couple of bugs that I found in how MPX determines the address contained in the instruction and operands. ++ Provide a new x86 instruction evaluating library With bugs fixed, the MPX evaluating code is relocated in a new insn-eval.c library. The basic functionality of this library is extended to obtain the segment descriptor selected by either segment override prefixes or the default segment by the involved registers in the calculation of the effective address. It was also extended to obtain the default address and operand sizes as well as the segment base address. Also, support to process 16-bit address encodings. Armed with this arsenal, it is now possible to determine the linear address onto which the emulated results shall be copied. This code supports Normal 32-bit and 64-bit (i.e., __USER32_CS and/or __USER_CS) protected mode, virtual-8086 mode, 16-bit protected mode with 32-bit base address. ++ Emulate UMIP instructions A new fixup_umip_exception functions inspect the instruction at the instruction pointer. If it is an UMIP-protected instruction, it executes the emulation code. This uses all the address-computing code of the previous section. ++ Add self-tests Lastly, self-tests are added to entry_from_v86.c to exercise the most typical use cases of UMIP-protected instructions in a virtual-8086 mode. ++ Extensive tests Extensive tests were performed to test all the combinations of ModRM, SiB and displacements for 16-bit and 32-bit encodings for the ss, ds, es, fs and gs segments. Tests also include a 64-bit program that uses segmentation via fs and gs. For this purpose, I temporarily enabled UMIP support for 64-bit process. This change is not part of this patchset. The intention is to test the computations of linear addresses in 64-bit mode, including the extra R8-R15 registers. Extensive test is also implemented for virtual-8086 tasks. Code of these tests can be found here [10] and here [11]. ++ Merging this series? Am I any close to see these patches merged? :) [1]. https://lwn.net/Articles/705877/ [2]. https://lkml.org/lkml/2016/12/23/265 [3]. https://lkml.org/lkml/2017/1/25/622 [4]. https://lkml.org/lkml/2017/2/23/40 [5]. https://lkml.org/lkml/2017/3/3/678 [6]. https://lkml.org/lkml/2017/3/7/866 [7]. http://timetobleed.com/a-closer-look-at-a-recent-privilege-escalation-bug-i… [8]. https://www.winehq.org/pipermail/wine-devel/2017-April/117159.html [10]. https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/um… [11]. https://github.com/01org/luv-yocto/commit/a72a7fe7d68693c0f4100ad86de6ecabd… Thanks and BR, Ricardo Changes since V6: *Reworded and addded more details on the special cases of ModRM and SIB bytes. To avoid confusion, I ommited mentioning the involved registers (EBP and ESP). *Replaced BUG() with printk_ratelimited in function get_reg_offset of insn-eval.c *Removed unused utility functions that obtain a register value from pt_regs given a SIB base and index. *Clarified nomenclature to call CS, DS, ES, FS, GS and SS segment registers and their values segment selectors. *Reworked function resolve_seg_register to issue an error when more than one segment overrides prefixes are used in the instruction. *Added logic in resolve_seg_register to ignore segment register when in long mode and not using FS or GS. *Added logic to ensure the effective address is within the limits of the segment in protected mode. *Added logic to ensure segment override prefixes are ignored when resolving the segment of EIP and EDI with string instructions. *Added code to make user_64bit_mode() available in CONFIG_X86_32... and make it return false, of course. *Merged the two functions that obtain the default address and operand size of a code segment into one as they are always used together. *Corrected logic of displacement-only addressing in long mode to make the displacement relative to the RIP of the next instruction. *Reworked logic to sign-extend 32-bit memory offsets into 64-bit signed memory offsets. This include more checks and putting all together in an utility function. *Removed the 'unlikely' of conditional statements as we are not in a critical path. *In virtual-8086 mode, ensure that effective addresses are always less than 0x10000, even when address override prefixes are used. Also, ensure that linear addresses have a size of 20-bits. Changes since V5: * Relocate the page fault error code enumerations to traps.h Changes since V4: * Audited patches to use braces in all the branches of conditional. statements, except those in which the conditional action only takes one line. * Implemented support in 64-builds for both 32-bit and 64-bit tasks in the instruction evaluating library. * Split segment selector function in the instruction evaluating library into two functions to resolve the segment type by instruction override or default and a separate function to actually read the segment selector. * Fixed a bug when evaluating 32-bit effective addresses with 64-bit kernels. * Split patches further for for easier review. * Use signed variables for computation of effective address. * Fixed issue with a spurious static modifier in function insn_get_addr_ref found by kbuild test bot. * Removed comparison between true and fixup_umip_exception. * Reworked check logic when identifying erroneous vs invalid values of the SiB base and index. Changes since V3: * Limited emulation to 32-bit and 16-bit modes. For 64-bit mode, a general protection fault is still issued when UMIP-protected instructions are executed with CPL > 0. * Expanded instruction-evaluating code to obtain segment descriptor along with their attributes such as base address and default address and operand sizes. Also, support for 16-bit encodings in protected mode was implemented. * When getting a segment descriptor, this include support to obtain those of a local descriptor table. * Now the instruction-evaluating code returns -EDOM when the value of registers should not be used in calculating the effective address. The value -EINVAL is left for errors. * Incorporate the value of the segment base address in the computation of linear addresses. * Renamed new instruction evaluation library from insn-kernel.c to insn-eval.c * Exported functions insn_get_reg_offset_* to obtain the register offset by ModRM r/m, SiB base and SiB index. * Improved documentation of functions. * Split patches further for easier review. Changes since V2: * Added new utility functions to decode the memory addresses contained in registers when the 16-bit addressing encodings are used. This includes code to obtain and compute memory addresses using segment selectors for real-mode address translation. * Added support to emulate UMIP-protected instructions for virtual-8086 tasks. * Added self-tests for virtual-8086 mode that contains representative use cases: address represented as a displacement, address in registers and registers as operands. * Instead of maintaining a static variable for the dummy base addresses of the IDT and GDT, a hard-coded value is used. * The emulated SMSW instructions now return the value with which the CR0 register is programmed in head_32/64.S This is: PE | MP | ET | NE | WP | AM. For x86_64, PG is also enabled. * The new file arch/x86/lib/insn-utils.c is now renamed as arch/x86/lib/ insn-kernel.c. It also has its own header. This helps keep in sync the the kernel and objtool instruction decoders. Also, the new insn-kernel.c contains utility functions that are only relevant in a kernel context. * Removed printed warnings for errors that occur when decoding instructions with invalid operands. * Added more comments on fixes in the instruction-decoding MPX functions. * Now user_64bit_mode(regs) is used instead of test_thread_flag(TIF_IA32) to determine if the task is 32-bit or 64-bit. * Found and fixed a bug in insn-decoder in which X86_MODRM_RM was incorrectly used to obtain the mod part of the ModRM byte. * Added more explanatory code in emulation and instruction decoding code. This includes a comment regarding that copy_from_user could fail if there exists a memory protection key in place. * Tested code with CONFIG_X86_DECODER_SELFTEST=y and everything passes now. * Prefixed get_reg_offset_rm with insn_ as this function is exposed via a header file. For clarity, this function was added in a separate patch. Changes since V1: * Virtual-8086 mode tasks are not treated in a special manner. All code for this purpose was removed. * Instead of attempting to disable UMIP during a context switch or when entering virtual-8086 mode, UMIP remains enabled all the time. General protection faults that occur are fixed-up by returning dummy values as detailed above. * Removed umip= kernel parameter in favor of using clearcpuid=514 to disable UMIP. * Removed selftests designed to detect the absence of SIGSEGV signals when running in virtual-8086 mode. * Reused code from MPX to decode instructions operands. For this purpose code was put in a common location. * Fixed two bugs in MPX code that decodes operands. Ricardo Neri (26): ptrace,x86: Make user_64bit_mode() available to 32-bit builds x86/mm: Relocate page fault error codes to traps.h x86/mpx: Use signed variables to compute effective addresses x86/mpx: Do not use SIB.index if its value is 100b and ModRM.mod is not 11b x86/mpx: Do not use SIB.base if its value is 101b and ModRM.mod = 0 x86/mpx, x86/insn: Relocate insn util functions to a new insn-eval file x86/insn-eval: Do not BUG on invalid register type x86/insn-eval: Add a utility function to get register offsets x86/insn-eval: Add utility function to identify string instructions x86/insn-eval: Add utility functions to get segment selector x86/insn-eval: Add utility function to get segment descriptor x86/insn-eval: Add utility functions to get segment descriptor base address and limit x86/insn-eval: Add function to get default params of code segment x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 5 x86/insn-eval: Incorporate segment base and limit in linear address computation x86/insn-eval: Support both signed 32-bit and 64-bit effective addresses x86/insn-eval: Handle 32-bit address encodings in virtual-8086 mode x86/insn-eval: Add support to resolve 16-bit addressing encodings x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings x86/cpufeature: Add User-Mode Instruction Prevention definitions x86: Add emulation code for UMIP instructions x86/umip: Force a page fault when unable to copy emulated result to user x86/traps: Fixup general protection faults caused by UMIP x86: Enable User-Mode Instruction Prevention selftests/x86: Add tests for User-Mode Instruction Prevention selftests/x86: Add tests for instruction str and sldt arch/x86/Kconfig | 10 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/insn-eval.h | 25 + arch/x86/include/asm/ptrace.h | 6 +- arch/x86/include/asm/traps.h | 18 + arch/x86/include/asm/umip.h | 15 + arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cpu/common.c | 16 +- arch/x86/kernel/traps.c | 4 + arch/x86/kernel/umip.c | 286 +++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-eval.c | 1066 +++++++++++++++++++++++++ arch/x86/mm/fault.c | 88 +- arch/x86/mm/mpx.c | 120 +-- tools/testing/selftests/x86/entry_from_vm86.c | 89 ++- 17 files changed, 1580 insertions(+), 177 deletions(-) create mode 100644 arch/x86/include/asm/insn-eval.h create mode 100644 arch/x86/include/asm/umip.h create mode 100644 arch/x86/kernel/umip.c create mode 100644 arch/x86/lib/insn-eval.c -- 2.9.3

5 80

Re: [PATCH] kernel32: Add support for detecting volume information with libudev.
by Alexandre Julliard July 28, 2017

July 28, 2017

Zebediah Figura <z.figura12(a)gmail.com> writes: > Using GetVolumeInformation may fail due to lack of permissions; e.g. > when the drive was mounted as root. This patch uses libudev, if it > is available, to retrieve the volume label, serial number, and type. > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/kernel32/Makefile.in | 3 +- > dlls/kernel32/volume.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 90 insertions(+), 1 deletion(-) libudev should be loaded dynamically, and that sort of thing should ideally be done in mountmgr. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] winmm: Load MCI drivers from MCI32 key.
by Andrew Eikum July 27, 2017

July 27, 2017

This looks good, but could you add some tests showing something that was wrong before but is now fixed? Andrew On Tue, Jul 25, 2017 at 09:18:15PM -0500, Zebediah Figura wrote: > MCI key/section is for 16-bit drivers, which can't be loaded by > 32-bit winmm. > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/winmm/mci.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/winmm/mci.c b/dlls/winmm/mci.c > index 56a537d..d770f6d 100644 > --- a/dlls/winmm/mci.c > +++ b/dlls/winmm/mci.c > @@ -66,10 +66,10 @@ WINE_DEFAULT_DEBUG_CHANNEL(mci); > #define MCI_MAGIC 0x0001 > > /* MCI settings */ > -static const WCHAR wszHklmMci [] = {'S','o','f','t','w','a','r','e','\\','M','i','c','r','o','s','o','f','t','\\','W','i','n','d','o','w','s',' ','N','T','\\','C','u','r','r','e','n','t','V','e','r','s','i','o','n','\\','M','C','I',0}; > +static const WCHAR wszHklmMci [] = {'S','o','f','t','w','a','r','e','\\','M','i','c','r','o','s','o','f','t','\\','W','i','n','d','o','w','s',' ','N','T','\\','C','u','r','r','e','n','t','V','e','r','s','i','o','n','\\','M','C','I','3','2',0}; > static const WCHAR wszNull [] = {0}; > static const WCHAR wszAll [] = {'A','L','L',0}; > -static const WCHAR wszMci [] = {'M','C','I',0}; > +static const WCHAR wszMci [] = {'M','C','I','3','2',0}; > static const WCHAR wszOpen [] = {'o','p','e','n',0}; > static const WCHAR wszSystemIni[] = {'s','y','s','t','e','m','.','i','n','i',0}; > > -- > 2.7.4 > > >

2 3

Re: [v2 PATCH] gdi32: Update metafile world transform immediately in winnt mode
by Alexandre Julliard July 27, 2017

July 27, 2017

Andrew Eikum <aeikum(a)codeweavers.com> writes: > The Chrome browser print function implements their own handling for > EMR_MODIFYWORLDTRANSFORM which calls ModifyWorldTransform on the HDC > directly without ever calling PlayEnhMetaFileRecord. In Wine, this > transformation would get discarded when the callback function returned, > causing the page to be printed at the wrong scale. > > Tests show that the transform is updated immediately during > PlayEnhMetaFileRecord. In addition, a modified transform persists > between callbacks until PlayEnhMetaFileRecord is called on a relevant > type of callback, at which point the transform is reverted before > playing back the record. > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > --- > > v2: Get rid of win9x checks in tests, and reformat test code. > > dlls/gdi32/enhmetafile.c | 41 ++++++- > dlls/gdi32/tests/metafile.c | 253 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 289 insertions(+), 5 deletions(-) This breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M gdiplus.dll -p gdiplus_test.exe.so metafile && touch metafile.ok wine: Unhandled exception 0xc0000093 in thread a0 at address 0x7e8f10c5 (thread 00a0), starting debugger... Unhandled exception: floating point underflow in 32-bit code (0x7e8f10c7). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7e8f10c7 ESP:0033f74c EBP:0033f768 EFLAGS:00010202( R- -- I - - - ) EAX:00000001 EBX:7e99b000 ECX:7e99b000 EDX:0033f7a8 ESI:7e99b000 EDI:0033f7a8 Stack dump: 0x0033f74c: 3f000000 00000000 00000000 3f000000 0x0033f75c: 7e99b000 00140bd0 0033f7a8 0033f7d8 0x0033f76c: 7e92e9f0 0033f7a8 0033f7a8 00140bd0 0x0033f77c: 00000000 3f800000 00000000 002f003e 0x0033f78c: 3f800000 3f800000 00000000 00000000 0x0033f79c: 3f800000 00000000 00000000 3f000000 Backtrace: =>0 0x7e8f10c7 CombineTransform+0x87() in gdi32 (0x0033f768) 1 0x7e92e9f0 EMF_Update_MF_Xform+0x6f(hdc=<is not available>, info=<is not available>) [/home/julliard/wine/wine/dlls/gdi32/enhmetafile.c:545] in gdi32 (0x0033f7d8) 2 0x7e930a4e PlayEnhMetaFileRecord+0x191d(hdc=<is not available>, handletable=<is not available>, mr=<is not available>, handles=<is not available>) [/home/julliard/wine/wine/dlls/gdi32/enhmetafile.c:1276] in gdi32 (0x0033f848) 3 0x7eca4fc1 GdipPlayMetafileRecord+0x170(metafile=<is not available>, recordType=<is not available>, flags=<is not available>, dataSize=<is not available>, data=<is not available>) [/home/julliard/wine/wine/dlls/gdiplus/metafile.c:1428] in gdiplus (0x0033f8c8) 4 0x7ed3887f test_gditransform_cb+0x2e(metafile=0x13f420, record_type=EmfRecordTypeGdiComment, flags=0, dataSize=0xc, pStr=") [/home/julliard/wine/wine/dlls/gdiplus/tests/metafile.c:2278] in gdiplus_test (0x0033f928) 5 0x7ed3881c play_metafile_proc+0x25b(record_type=<couldn't compute location>, flags=<couldn't compute location>, dataSize=<couldn't compute location>, pStr=<couldn't compute location>, userdata=<couldn't compute location>) [/home/julliard/wine/wine/dlls/gdiplus/tests/metafile.c:264] in gdiplus_test (0x0033f988) 6 0x7eca3495 enum_metafile_proc+0x64(hDC=<is not available>, lpHTable=<is not available>, lpEMFR=<is not available>, nObj=<is not available>, lpData=<is not available>) [/home/julliard/wine/wine/dlls/gdiplus/metafile.c:1841] in gdiplus (0x0033f9e8) 7 0x7e931af8 EnumEnhMetaFile+0x497() in gdi32 (0x0033faf8) 8 0x7eca5e56 GdipEnumerateMetafileSrcRectDestPoints+0x505() in gdiplus (0x0033fba8) 9 0x7ed39ea4 play_metafile.constprop+0x43() in gdiplus_test (0x0033fc08) 10 0x7ed43f42 func_metafile+0x2971() [/home/julliard/wine/wine/dlls/gdiplus/tests/metafile.c:2369] in gdiplus_test (0x0033fd48) 11 0x7eced39d main+0x25c(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/gdiplus/tests/../../../include/wine/test.h:603] in gdiplus_test (0x0033fdf8) 12 0x7ed5947b __wine_spec_exe_entry+0x4a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in gdiplus_test (0x0033fe38) 13 0x7b45e85c call_process_entry+0xb() in kernel32 (0x0033fe58) 14 0x7b45f799 start_process+0x68(entry=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1116] in kernel32 (0x0033fe98) 15 0x7bc7ea9c call_thread_func_wrapper+0xb() in ntdll (0x0033feb8) 16 0x7bc81a59 call_thread_func+0xa8(entry=0x7b45f730, arg=0x7ed59430, frame=0x33ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2912] in ntdll (0x0033ffa8) 17 0x7bc7ea7a call_thread_entry_point+0x11() in ntdll (0x0033ffc8) 18 0x7bc53d43 start_process+0x12(arg=0xff987f08) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3083] in ntdll (0x0033ffe8) 19 0xf753b91d __x86.get_pc_thunk.di+0x2a() in libwine.so.1 (0x00000000) 20 0xf753ba80 wine_switch_to_stack+0x1f(func=0x7bc53d30, arg=0xff987f08, stack=0x340000) [/home/julliard/wine/wine/libs/wine/port.c:77] in libwine.so.1 (0xff987ed8) 21 0x7bc599fe LdrInitializeThunk+0x22d(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3144] in ntdll (0xff987f28) 22 0x7b4656ff __wine_kernel_init+0xa4e() [/home/julliard/wine/wine/dlls/kernel32/process.c:1310] in kernel32 (0xff988e18) 23 0x7bc5a853 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3353] in ntdll (0xff988e88) 24 0xf7539b83 wine_init+0x2a2(argc=0x3, argv=0xff9893d4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:974] in libwine.so.1 (0xff988ed8) 25 0x7c000b58 main+0x97(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:258] in <wine-loader> (0xff989328) 26 0xf7343276 __libc_start_main+0xf5() in libc.so.6 (0x00000000) 0x7e8f10c7 CombineTransform+0x87 in gdi32: flds 0xfffffff0(%ebp) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] gdi32: Update metafile world transform immediately in winnt mode
by Dmitry Timoshkov July 27, 2017

July 27, 2017

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > +#define IS_WIN9X() (GetVersion() & 0x80000000) ... > + if (IS_WIN9X()) > + /* win9x doesn't support world transforms */ > + return; The tests are supposed to get rid of win9x checks, not add new ones. -- Dmitry.

2 1

Re: [PATCH] gdiplus: Add stub for GdipGraphicsSetAbort
by Dmitry Timoshkov July 27, 2017

July 27, 2017

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > +static void test_GdipGraphicsSetAbort(void) > +{ > + HDC hdc = GetDC(hwnd); > + GpStatus status; > + GpGraphics *graphics; > + > + if (!pGdipGraphicsSetAbort) > + { > + win_skip("GdipGraphicsSetAbort() is not supported.\n"); > + return; hdc is leaked. > + } > + > + status = GdipCreateFromHDC(hdc, &graphics); > + expect(Ok, status); > + > + status = pGdipGraphicsSetAbort(NULL, NULL); > + expect(InvalidParameter, status); > + > + status = pGdipGraphicsSetAbort(graphics, NULL); > + expect(Ok, status); > + > + ReleaseDC(hwnd, hdc); > +} graphics is leaked. Also, it would be useful to test not invalid input as well. -- Dmitry.

2 1

Re: [PATCH] wmvcore/tests: add tests for WMReader methods
by Alistair Leslie-Hughes July 27, 2017

July 27, 2017

Hi Jefferson, Thanks for the updated patch. When applying your patch there lot of whitespace errors (mostly from the header). warning: squelched 3569 whitespace errors warning: 3574 lines add whitespace errors. After look at qedit/tests, include the wma directly as a resource. (unless someone else objects) >// MSDN says dwType is a QWORD, but it is actually a DWORD C++ style comments aren't allowed. > ok(dwType == WMT_TYPE_DWORD, "onStatus pValue not WMT_TYPE_QWORD (%d), but %d\n", (int)WMT_TYPE_DWORD, dwType); Again WMT_TYPE_QWORD is incorrect here, and remove the (int)WMT_TYPE_DWORD parameter. TestWMReaderCallback_AddRef/Release could just return 2/1 respectfully. The object doesn't need to be deleted nor is there any reference type checks. wmvcore.c: In function ‘test_wmreader_play_wma’: wmvcore.c:425:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ok((int)(onStatus_event = CreateEventW(NULL, FALSE, FALSE, NULL)), "Could not create event\n"); ^ You dont delete the wma file. Best Regards Alistair Leslie-Hughes

1 0

Re: [PATCH 2/7] regedit: Use a helper function to allocate memory and check for a valid pointer
by Alexandre Julliard July 27, 2017

July 27, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > +static void *heap_alloc(size_t size) > +{ > + void *buf; > + > + if (!(buf = HeapAlloc(GetProcessHeap(), 0, size))) > + { > + ERR("Out of memory!\n"); > + exit(1); > + } > + > + return buf; > +} That's not the standard heap_alloc(), so a different name would be preferable. I'd suggest heap_xalloc by analogy with xmalloc. -- Alexandre Julliard julliard(a)winehq.org

2 2

Unicode normalization for Wine
by Artur Świgoń July 26, 2017

July 26, 2017

Dear All, My name is Artur and I'm participating in Google Summer of Code 2017 for Wine. Under Nikolay's supervision, I'm working on implementation of Unicode normalization. I probably should have introduced myself some time ago to share results of my research and my ideas, but I also wanted to wait until I could illustrate my points with some code. I'm not sure whether everyone is familiar with Unicode normalization forms, so here's a short summary of concepts and terms I may use. For detailed information, please see [1]. - Characters that look the same on the screen may be encoded in a few different ways. Accented Latin letters may constitute a familiar example. The letter 'é' can be U+00E9 (LATIN SMALL LETTER E WITH ACUTE), but it also can be represented as the sequence U+0065 U+0301 (LATIN SMALL LETTER E, COMBINING ACUTE ACCENT). Many of 1114112 (if I remember the number correctly) Unicode characters are decomposable, i.e. they can also be represented by a different sequence of characters. - Text in normalization form NFD ('D' stands for 'decomposition') does not contain any decomposable characters, e.g. there is U+0065 U+0301 instead of U+00E9. The combining characters (such as the above-mentioned acute accent) have a well defined order, using the concept of combining classes. [2 §3.11] - Text in normalization form NFKD ('K' stands for 'compatibility') has the properties of NFD, plus characters that are typographical variants of other characters (e.g. superscripts, ligatures, etc.) are mapped to 'plain' characters. - Text that will be normalized into the form NFC and NFKC ('C' stands for 'composition') has to be fully decomposed first (NFD and NFKD, respectively) and starters (characters with a combining class zero) plus following non- starters (combining class greater than zero) can be composed into single characters provided that they exist in Unicode and are not present in [3]. I've developed a draft implementation of NFD & NFKD (mapping characters to decomposed sequences as well as reordering combining characters) and written a test program that uses official Unicode test data. [4] My goal was to provide support for codepoints greater than 0xFFFF, encoded in UTF-16 as surrogate pairs. More on that below. The attachment [gsoc-v2.patch] is a diff of my working branch against master. Most notable changes include: - Necessary changes to tools/make_unicode. - New function wine_decompose_string(). - Draft implementation of two Windows API functions: NormalizeString() and IsNormalizedString() (the latter temporarily returns TRUE). [5][6] Rationale and comments: - tools/make_unicode did not collect all necessary data (most notably, compatibility mappings), so a new data structure, @decomp_table_full has been added. Its unification with @decomp_table is yet to be resolved. - The procedure dump_decompose_table() in that script has been rewritten to accomodate all aspects described above and below. Two helper subroutines have been added. - However, the C code section embedded within the script has grown substantially, so it may be desirable to move it to a separate file. - Adding wine_decompose_string() makes sense since surrogate pairs behave like a string and the Unicode Canonical Ordering Algorithm (for combining characters) is an in-place bubble sort on the string, per Unicode specification. - While the code in libs/port/decompose.c (and embedded in tools/make_unicode) implements normalization, it currently serves the purpose of confirmation that the generated data is correct. It hasn't been yet optimized or cleaned up, because the organization of the data is open to discussion now, so the code may still change substantially. - It has been previously assumed that a decomposition mapping of any character is two characters long. This is certainly not true for NFKD, where a character like U+FDFA decomposes to a string of length 18. Therefore, the tables in libs/port/decompose.c contain pairs of offsets to null-terminated mappings in another table (decomp_data, first in that file), one entry for NFD and one for NFKD, instead of two-character mappings. Moreover, since many NFD and NFKD are identical, they have been placed in the same table, with identical mappings merged and fully expanded (i.e. any decomposable characters in the data have been replaced by fully decomposed sequences), to minimize runtime overhead. - The original idea of multi-stage tables (using the most significant bits of a codepoint to obtain an offset to another table etc.) has been preserved, although the tables are no longer combined into a single table. This is because some sub-tables can use a narrower data type, which saves space, especially when data for all Unicode codepoints is included. - Tables of combining classes have a similar structure. - Mappings for characters above 0xFFFF are encoded as UTF-16 (using surrogate pairs), but a single codepoint (UTF-32 if you like) is used for table indexing. Setting $utflim in make_unicode to 65536 is the simplest way to disable support for such characters, but supporting surrogate pairs should not affect any text-related Wine component in a negative way. - As composition depends directly on decomposition, it is the next thing to work on. The attachment [unorm_test.c] is my test program. It should build fine with mingw-w64 or winegcc without any specific compiler flags. It looks for [4] in its directory or accepts a path to that file as an argument. Option -d makes it run only decomposition tests, option -s limits the range to 0xFFFF. No tests should fail with the -s option and 80 of 187460 should fail without it due to incomplete support for surrogate pairs in the reordering part. For details of failed tests, please run with the -v option. Is there a place for such a program somewhere in the Wine source tree? I'd be more than happy to answer your questions, address your comments, and listen to your opinions regarding Unicode normalization. Regards, Artur Świgoń [1] http://www.unicode.org/reports/tr15/ [2] http://www.unicode.org/versions/Unicode10.0.0/ch03.pdf [3] http://www.unicode.org/Public/10.0.0/ucd/CompositionExclusions.txt [4] http://www.unicode.org/Public/10.0.0/ucd/NormalizationTest.txt [5] https://msdn.microsoft.com/en-us/library/windows/desktop/dd319093(v=vs.85).… [6] https://msdn.microsoft.com/en-us/library/windows/desktop/dd318671(v=vs.85).…

2 1

Unicode normalization for Wine - new patch
by Artur Świgoń July 26, 2017

July 26, 2017

I'm not sure whether I've sent the updated patch in my previous email. This one is the one that passes the number of tests I described in my previous message. Sorry for confusion. Artur

1 0

Re: [PATCH] wmvcore/tests: add tests for WMReader methods
by Alistair Leslie-Hughes July 25, 2017

July 25, 2017

Hi Jefferson, > > +typedef struct { > + IWMReaderCallback IWMReaderCallback_iface; > + LONG ref; > + HRESULT (*onStatusCallback)(WMT_STATUS, HRESULT, WMT_ATTR_DATATYPE, BYTE*, void*, void*); > + HRESULT (*onSampleCallback)(DWORD, QWORD, QWORD, DWORD, INSSBuffer*, void*, void*); > + void *pvCallbackContext; > +} TestWMReaderCallback; I'm still a little confused as to why you need this structure when the IWMReaderCallbackVtbl with a few globals would work just as well. > +static HRESULT onStatus_test_wmreader_play_wma( > + WMT_STATUS status, > + HRESULT hr, > + WMT_ATTR_DATATYPE dwType, > + BYTE *pValue, > + void *pvContext, > + void *pvCallbackContext) > +{ > + struct callback_context_test_wmreader_play_wma *pTestContext = > + (struct callback_context_test_wmreader_play_wma*)pvCallbackContext; > + DWORD *dwordValue; > + > + CHECK_EXPECT(onStatus); > + ok(status == onStatus_expected_statuses_test_wmreader_play_wma[pTestContext->onStatus_call_count], > + "onStatus called with unexpected status: %d\n", status); > + if (status == WMT_OPENED) { > + ok(pvContext == pTestContext->pvContextOpen, > + "onStatus was not passed pvContext: expected %p, actual %p\n", pTestContext->pvContextOpen, pvContext); > + } > + else /* status == WMT_STARTED, or later */ { > + ok(pvContext == pTestContext->pvContextStart, > + "onStatus was not passed pvContext: expected %p, actual %p\n", pTestContext->pvContextStart, pvContext); > + } > + switch (status) { > + case WMT_STARTED: > + // MSDN says dwType is a QWORD, but it is actually a DWORD > + ok(dwType == WMT_TYPE_DWORD, "onStatus pValue not WMT_TYPE_QWORD (%d), but %d\n", (int)WMT_TYPE_DWORD, dwType); WMT_TYPE_QWORD typo? > + dwordValue = (DWORD*)pValue; > + ok(*dwordValue == 0, "onStatus call for WMT_STARTED not passed correct starting timestamp: %u\n", *dwordValue); > + SET_EXPECT(onSample); > + break; > + default: > + break; > + } The switch and if could be merged > + /* Get format count. */ > + formatCount = 0; > + hr = IWMReader_GetOutputFormatCount(reader, 0, &formatCount); > + todo_wine ok(hr == S_OK, "Failed to get output format count: 0x%08x\n", hr); formatCount should be checked Best Regards Alistair Leslie-Hughes

2 2

Re: wined3d: Fix context backup window handling.
by Henri Verbeet July 25, 2017

July 25, 2017

On 25 July 2017 at 22:35, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > - if (dc == context->hdc && !context->hdc_is_private && WindowFromDC(dc) != context->win_handle) > + if (dc == context->hdc && !private && WindowFromDC(dc) != context->win_handle) While that works, I think I'd feel happier about the code if the "dc", "private" and "format" parameters just went away. I.e., the reason they still exist is mostly the backup window path in context_set_gl_context(), and I don't think there's a reason that particular path shouldn't just set the appropriate (hdc, hdc_is_private, hdc_has_format) fields in the context instead.

1 0

Re: [PATCH] gdiplus: Avoid division by zero in SOFTWARE_GdipDrawThinPath
by Fabian Maurer July 25, 2017

July 25, 2017

Or maybe we should draw this single pixel? Regards, Fabian Maurer

2 2

Re: [PATCH 4/4 v2] mshtml: Add IElementTraversal::get_firstElementChild implementation
by Marvin July 25, 2017

July 25, 2017

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=32476 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5092: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 3/4 v2] mshtml: Expose IElementTraversal interface to scripts
by Marvin July 25, 2017

July 25, 2017

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=32475 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5092: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 3/4 v2] mshtml: Expose IElementTraversal interface to scripts
by Jacek Caban July 25, 2017

July 25, 2017

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

1 0

Re: [PATCH 4/4] mshtml: Add IElementTraversal::get_firstElementChild implementation
by Marvin July 25, 2017

July 25, 2017

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=32474 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [PATCH 3/4] mshtml: Expose IElementTraversal interface to scripts
by Marvin July 25, 2017

July 25, 2017

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=32473 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [PATCH 1/5] po: Fix a typo in the Norwegian translation
by Kim Malmo July 25, 2017

July 25, 2017

Thank you kindly! How did you find it? I read through the patch 3 times and missed it. Kim --- Den 24. juli 2017 14:47, skrev Hugh McMaster: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > po/nb_NO.po | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/po/nb_NO.po b/po/nb_NO.po > index 2fa8d89863..0ad494b4f2 100644 > --- a/po/nb_NO.po > +++ b/po/nb_NO.po > @@ -12512,7 +12512,7 @@ msgstr "regedit: Registerverdien \"%1\" vil bli eksportert som binære data.\n" > > #: regedit.rc:427 > msgid "regedit: Invalid system key [%1]\n" > -msgstr "reg: Ugyldig systemnøkkel [%1]\n" > +msgstr "regedit: Ugyldig systemnøkkel [%1]\n" > > #: regedit.rc:428 > msgid ""

1 0

Re: [1/2] gdi32/tests: Add test for SetPixel erase with R2_XORPEN
by Huw Davies July 24, 2017

July 24, 2017

On Mon, Jul 24, 2017 at 12:57:30AM +1000, Tim Worthington wrote: > diff --git a/dlls/gdi32/tests/dib.c b/dlls/gdi32/tests/dib.c > --- a/dlls/gdi32/tests/dib.c > +++ b/dlls/gdi32/tests/dib.c > @@ -2703,6 +2703,26 @@ > ret = ExtFloodFill( hdc, -1, -1, RGB( 0, 0xff, 0 ), FLOODFILLSURFACE ); > ok (!ret, "got ret %d\n", ret); > > + /* SetPixel erase with R2_XORPEN */ > + if ( ( bmi->bmiHeader.biBitCount >= 16 ) > + || ( ( bmi->bmiHeader.biClrUsed == 256 ) && ( bmi->bmiHeader.biBitCount == 8 ) ) ) > + { > + int rop2; > + COLORREF set, get; > + > + rop2 = GetROP2( hdc ); > + for (i = 0; i < 256; i++) > + { > + SetROP2( hdc, R2_COPYPEN ); > + set = SetPixel( hdc, i * 2, 30, RGB( (i & 0x07) << 5, (i & 0x38) << 2, i & 0xc0 ) ); > + SetROP2( hdc, R2_XORPEN ); > + SetPixel( hdc, i * 2, 30, set ); > + get = GetPixel( hdc, i * 2, 30 ); > + ok( get == 0, "got %08x and %08x\n", set, get ); > + } > + SetROP2( hdc, rop2 ); > + } > + > SelectObject(hdc, orig_brush); > SelectObject(hdc, orig_pen); > DeleteObject(solid_brush); Hi Tim, Thank you for your contribution to Wine. There were a number of issues with this series, which by the time I'd reviewed them meant I'd essentially re-written the patches; so I just sent them in: https://source.winehq.org/patches/data/136093 https://source.winehq.org/patches/data/136094 This seemed more efficient than explaining the problems and suggesting alternative approaches. If you're interested, please free feel to look at my patches and ask if there's anything you're curious about. Huw.

2 1

Re: [PATCH] user32: In CURSORICON_FindBestCursor scale cursor correctly
by Fabian Maurer July 24, 2017

July 24, 2017

Was too slow, not needed anymore after d0e8170c90ef63363f8389be2619c9332ae2c371. Regards, Fabian Maurer

1 0

Re: [PATCH] wmvcore/tests: add tests for WMReader methods
by Alistair Leslie-Hughes July 24, 2017

July 24, 2017

Hi Jefferson, On 24/07/17 08:26, Jefferson Carpenter wrote: > Create a sample WMA file, which is saved into a temp directory at the > beginning of the wmvcore tests. > > Added a IWMReaderCallback implementation for use in conformance tests. > > Tested various playback-related WMReader methods. > > Changes in version 2 of this patch: Declared loop variable at top of > function, and using C89-style comments. The callback interface can just be static, see mshtml/tests/htmldoc.c for an example. Maybe using the CHECKED_CALLED syntax to check if something was been called. If the order of called is important then see msxml3/tests/saxreader.c for an example. You cannot use Sleep in tests, no matter how small it has to wait, instead use an Event+WaitForSingleObject. Use HeapAlloc/HeapFree instead of malloc/free, create a worker function if required. + IWMReader *reader; Leaking reader + /* Get output props. */ + hr = IWMReader_GetOutputProps(reader, 0, &props); + todo_wine ok(hr == S_OK, "Failed to get output props: 0x%08x\n", Leaking props here. .... + for (i = 0; i < formatCount; i++) { + /* Get output props for format. */ + hr = IWMReader_GetOutputFormat(reader, 0, i, &props); + todo_wine ok(hr == S_OK, "Failed to get output format: and here. Best Regards Alistair Leslie-Hughes

2 1

Re: mscoree: Update for mono profiler api v2.
by Vincent Povirk July 24, 2017

July 24, 2017

Please don't commit this. They just changed it again and put in compatibility functions for the old API.

1 0

Some clarification of msi messages for translation and pedantic remarks
by Julian Rüger July 24, 2017

July 24, 2017

Hi Zebediah (and list), I'd like some clarification of a few terms used in the new msi messages, to make sure I translate the correct meaning. :) #: msi.rc:103 msgid "Searching for related applications" ... #: msi.rc:111 msgid "Migrating feature states from related applications" related as in 'similar' or 'belonging together' or something else? I'd guess #2. #: msi.rc:113 msgid "Publishing assembly information" assembly as in 'binary/executable file/dll', 'the assembler language' or just 'putting together'? I strongly suspect #1, and that is a tough one. There is no fitting translation in German and this is not one of the many, many cases where you would just use the original English term. It sounds totally awkward. (Maybe because words ending in y are usually Germanized to use other suffixes. Just does not work with 'Assembly') EDIT: Never mind, I just looked it up and M$ does indeed use the untranslated original, even in compound words.. Ughhh! #: msi.rc:120 msgid "Registering Class servers" ... #: msi.rc:122 msgid "Registering extension servers" It's 'Server' in German as well for the hardware (machine/host) or applications/services like Apache, but this feels like a different thing. Am I being silly? Maybe this can only be answered by other German speakers. #: msi.rc:130 msi.rc:154 msgid "Updating environment strings" Can I just call this environment variables? Sounds more natural than the compound word with string ("Umgebungszeichenketten")... Thanks for your help and for all your work! Best, Julian PS: Some other questions/comments, unrelated to translation: #: msi.rc:168 msi.rc:171 msi.rc:175 msgid "File: [1], Directory: [9], Size: [6]" ... #: msi.rc:170 msgid "File: [1], Directory: [9], Size: [6]" Are these supposed to be separate, but identical? #: msi.rc:173 msgid "File: [1], Dependencies: [2]" ^^ Two spaces on purpose? #: msi.rc:176 msi.rc:177 msgid "Application Context:[1], Assembly Name:[2]" Missing spaces? #: msi.rc:189 msi.rc:209 msgid "Name: [1], Value: [2], Action [3]" Missing colon? (Action: [3])? #: msi.rc:178 msgid "File: [1], Directory: [2], Size: [3]" ... #: msi.rc:193 msi.rc:210 msgid "File: [1], Section: [2], Key: [3], Value: [4]" Duplicate spaces again?

2 1

Re: [PATCH 4/5] reg: Use a helper function to allocate and re-allocate memory
by Alexandre Julliard July 24, 2017

July 24, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -174,6 +177,26 @@ static BOOL ask_confirm(unsigned int msgid, WCHAR *reg_info) > } > } > > +#define CHECK_ENOUGH_MEMORY(p) \ > +if (!(p)) \ > +{ \ > + output_message(STRING_OUT_OF_MEMORY, __FILE__, __LINE__); \ > + exit(1); \ > +} > + > +static void *resize_buffer(void *buf, size_t count) > +{ > + void *new_buf; > + > + if (buf) > + new_buf = HeapReAlloc(GetProcessHeap(), 0, buf, count); > + else > + new_buf = HeapAlloc(GetProcessHeap(), 0, count); > + > + CHECK_ENOUGH_MEMORY(new_buf); > + return new_buf; > +} The macro is not needed, and the message doesn't need to be localized, since this would require allocating memory. I think you'll also want a separate wrapper for HeapAlloc. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] msvcrt: Don't set errno when calling trigonometric functions with NAN.
by Piotr Caban July 24, 2017

July 24, 2017

Hi, I've done some more reading about it and it looks like our implementation is not behaving in similar way as native does. The error handling should call _matherr function (see also __setusermatherr). Thanks to implementing it that way we easily write code that is compatible with older versions of C-runtime (by providing different default implementation of matherr function that prevents setting errno). I think it's best to implement it that way to avoid potential regressions. Thanks, Piotr

2 2

Re: ntdll: Add padding to the stack structure for quad-word alignment on ARM64
by Alexandre Julliard July 24, 2017

July 24, 2017

André Hentschel <nerv(a)dawncrow.de> writes: > EXCEPTION_RECORD is not correctly aligned and until bd1f7ef1868dd563a82eacd1bf414bf8d1a7254e, CONTEXT wasn't either, > which ended up in a correctly aligned structure, but the mentioned commit changed that. > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/ntdll/signal_arm64.c | 1 + > 1 file changed, 1 insertion(+) You should probably handle that in the existing alignment computation instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2 3/3] msvcr120: Add log1p.
by Piotr Caban July 24, 2017

July 24, 2017

On 07/14/17 07:14, Alex Henrie wrote: > +/********************************************************************* > + * log1pf (MSVCR120.@) > + */ > +float CDECL MSVCR120_log1pf(float x) > +{ > +#ifdef HAVE_LOG1PF > + return log1pf(x); > +#else > + return log(1 + x); > +#endif > +} Please also set errno in this function. Thanks, Piotr

2 3

Re: [PATCH] wmvcore/tests: add tests for WMReader methods
by Marvin July 23, 2017

July 23, 2017

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=32460 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH] gdiplus: free dash_pattern_scaled (Coverity)
by Vincent Povirk July 23, 2017

July 23, 2017

Thanks, Marcus. Unfortunately, with my patch for the same issue (caught by valgrind), this no longer applies. Can you rebase this please?

2 1

Re: ntdll: Fix stack alignment in RtlRaiseException assembly code.
by Alexandre Julliard July 21, 2017

July 21, 2017

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Please review carefully, don't want to break anything shortly before the > release. ;) > > dlls/ntdll/signal_i386.c | 41 ++++++++++++++++++++++++----------------- > 1 file changed, 24 insertions(+), 17 deletions(-) All it does is call other API functions that will align the stack anyway, so I'm not sure it's worth the trouble. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/2 v2] reg: Account for sizeof(WCHAR) when resizing the value name buffer during the query operation
by Alexandre Julliard July 21, 2017

July 21, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Changes since v1: > - Handle HeapReAlloc() failure This is a stand-alone app, so adding a couple of helpers that die on allocation failure would probably be a better choice than checking everywhere. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] mshtml: Added IHTMLDOMNode3::put_textContent implementation.
by Marvin July 21, 2017

July 21, 2017

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=32419 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5092: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 1/2] xmllite/reader: Implement MoveToAttributeByName()
by Marvin July 21, 2017

July 21, 2017

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=32415 Your paranoid android. === wxppro (32 bit reader) === reader.c:2597: Test failed: Unexpected hr 0x1. === w2003std (32 bit reader) === reader.c:2597: Test failed: Unexpected hr 0x1.

1 0

Re: [PATCH 2/8] d3d11: Fix race condition in d3d_blend_state_create().
by Henri Verbeet July 21, 2017

July 21, 2017

On 20 July 2017 at 14:10, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Arguably we could use a different mutex for "device->blend_states". > Yeah. Generally speaking we'd like wined3d locking to be more fine-grained, but there are probably a bunch of issues with that.

1 0

Re: [PATCH] reg: Account for sizeof(WCHAR) when resizing the value name buffer during the query operation
by Henri Verbeet July 21, 2017

July 21, 2017

On 21 July 2017 at 10:47, Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > - value_name = HeapReAlloc(GetProcessHeap(), 0, value_name, max_value_len); > + value_name = HeapReAlloc(GetProcessHeap(), 0, value_name, max_value_len * sizeof(WCHAR)); Note that this leaks the existing "value_name" allocation if the HeapReAlloc() call should fail.

1 0

Re: [PATCH 3/6] msi: Don't set _BrowseProperty.
by Zebediah Figura July 20, 2017

July 20, 2017

On 07/20/2017 11:43 PM, Zebediah Figura wrote: > This is a revert of 166a7e993cb0033fac7ec2712c346558fb7bd100, > which was introduced to fix bug #28219. _BrowseProperty is not set > by Windows, but should rather be set by the program in question, and > was not being set due to a bug in Wine, fixed by the previous patch. Sorry, typo—meant to say next patch (4/6).

1 0

Re: [PATCH 2/2] mshtml: Added IHTMLDOMNode3::get_textContent implementation.
by Marvin July 20, 2017

July 20, 2017

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=32404 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath === w864 (64 bit events) === events.c:987: Test failed: unexpected call img_onerror

1 0

Re: [v3] gdi32: return non-zero v-refresh value for display devices.
by Huw Davies July 20, 2017

July 20, 2017

On Thu, Jul 20, 2017 at 10:56:40PM +0900, Akihiro Sagawa wrote: > > To avoid division by zero (Bug 43369). > > In version 3, refine a testcase. > The refresh rate value is neither zero nor negative, thus we should test both. > Thanks for reviewing. > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/gdi32/driver.c | 2 +- > dlls/gdi32/tests/dc.c | 8 ++++++++ > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/dlls/gdi32/driver.c b/dlls/gdi32/driver.c > index fe7812c..6a3975a 100644 > --- a/dlls/gdi32/driver.c > +++ b/dlls/gdi32/driver.c > @@ -344,7 +344,7 @@ static INT nulldrv_GetDeviceCaps( PHYSDEV dev, INT cap ) > case PHYSICALOFFSETY: return 0; > case SCALINGFACTORX: return 0; > case SCALINGFACTORY: return 0; > - case VREFRESH: return 0; > + case VREFRESH: return GetDeviceCaps( dev->hdc, TECHNOLOGY ) == DT_RASDISPLAY ? 1 : 0; > case DESKTOPVERTRES: return GetDeviceCaps( dev->hdc, VERTRES ); > case DESKTOPHORZRES: return GetDeviceCaps( dev->hdc, HORZRES ); > case BLTALIGNMENT: return 0; > diff --git a/dlls/gdi32/tests/dc.c b/dlls/gdi32/tests/dc.c > index add2c04..d316f3f 100644 > --- a/dlls/gdi32/tests/dc.c > +++ b/dlls/gdi32/tests/dc.c > @@ -388,6 +388,7 @@ static void test_device_caps( HDC hdc, HDC ref_dc, const char *descr, int scale > { > INT precision = 0; > INT hdc_caps = GetDeviceCaps( hdc, caps[i] ); > + INT ref_caps; > > switch (caps[i]) > { > @@ -400,6 +401,13 @@ static void test_device_caps( HDC hdc, HDC ref_dc, const char *descr, int scale > case LOGPIXELSY: > hdc_caps *= scale; > break; > + case VREFRESH: > + ref_caps = GetDeviceCaps( ref_dc, caps[i] ); > + if (GetDeviceCaps( ref_dc, TECHNOLOGY ) == DT_RASDISPLAY) > + ok( ref_caps > 0, "expected a positive value on %s, got %d\n", descr, ref_caps ); > + else > + ok( ref_caps == 0, "expected 0 on %s, got %d\n", descr, ref_caps ); > + break; > } You don't want to use 'ref_dc' here, use 'hdc' instead. Also, note that 'hdc_caps' already contains the thing you want to test, so you don't need the first call to GetDeviceCaps(). Huw.

1 0

Re: [PATCH] widl: Handle C++ aggregate returns in a MSVC compatible way.
by Jacek Caban July 20, 2017

July 20, 2017

Hi Henri, On 20.07.2017 14:18, Henri Verbeet wrote: > This mainly affects 64-bit winelib applications, and potentially mingw-w64 > usage of the Wine headers. As explained in commit > fabfa59aea5c5b3201142382038beb3e76cb7567, MSVC returns aggregates through an > implicit parameter immediately after the this/interface pointer. GCC's > "ms_abi" attribute is supposed to match this, but unfortunately current > versions of g++ (confirmed up to at least g++ 6.3) place the implicit return > pointer before the this/interface pointer. See also > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52792. FWIW, here is a bug about 32-bit problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384 > This commit takes an approach similar to the earlier commit > fabfa59aea5c5b3201142382038beb3e76cb7567: For ABI compatibility the return > pointer is listed as an explicit parameter in the vtbl entry, while an inline > helper is provided for source code compatibility. While it fixes the problem for C++ callers, it breaks building classes implementing those interfaces. Implementation will try to override inline function instead of virtual one. Given that the workaround has bad side effects, I'd say that we should at least try harder to not use it. For example it could be #ifdefed to not be used by compilers doing the right thing. With that, using our headers would require modifications in compiled code compatible with MSVC, so there would be a point in having a nice to use macro that interface implementations could use to decide if they should apply needed changes. Obviously fixing compilers sounds much better. Jacek

2 3

Re: [PATCH] gdi32: Update enhanced metafile world transform immediately in winnt mode
by Huw Davies July 20, 2017

July 20, 2017

On Wed, Jul 19, 2017 at 02:06:29PM -0500, Andrew Eikum wrote: > /***************************************************************************** > * PlayEnhMetaFileRecord (GDI32.@) > @@ -1443,14 +1458,20 @@ BOOL WINAPI PlayEnhMetaFileRecord( > info->state.world_transform.eM11 = info->state.world_transform.eM22 = 1; > info->state.world_transform.eM12 = info->state.world_transform.eM21 = 0; > info->state.world_transform.eDx = info->state.world_transform.eDy = 0; > + if (!IS_WIN9X()) > + EMF_Update_MF_Xform(hdc, info); > break; > case MWT_LEFTMULTIPLY: > CombineTransform(&info->state.world_transform, &lpModifyWorldTrans->xform, > &info->state.world_transform); > + if (!IS_WIN9X()) > + ModifyWorldTransform(hdc, &lpModifyWorldTrans->xform, MWT_LEFTMULTIPLY); > break; > case MWT_RIGHTMULTIPLY: > CombineTransform(&info->state.world_transform, &info->state.world_transform, > &lpModifyWorldTrans->xform); > + if (!IS_WIN9X()) > + EMF_Update_MF_Xform(hdc, info); > break; > default: > FIXME("Unknown imode %d\n", lpModifyWorldTrans->iMode); > @@ -2216,6 +2237,13 @@ BOOL WINAPI PlayEnhMetaFileRecord( > LPtoDP(hdc, (POINT*)&tmprc, 2); > TRACE("L:0,0 - 1000,1000 -> D:%s\n", wine_dbgstr_rect(&tmprc)); > > + if (emr_modifies_transform( mr->iType ) && !IS_WIN9X()) > + { > + /* WinNT - update the transform (win9x updates when the next graphics > + output record is played). */ > + EMF_Update_MF_Xform(hdc, info); > + } > + > return TRUE; > } > I think it would be better to call EMF_Update_MF_Xform() in each 'case' block that needs it, just like you are doing for EMR_MODIFYWORLDTRANSFORM. Also, what about EMR_SETMAPMODE? > diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c > index eeec79c800..eaad666361 100644 > --- a/dlls/gdi32/tests/metafile.c > +++ b/dlls/gdi32/tests/metafile.c [snip] > START_TEST(metafile) > { > init_function_pointers(); > @@ -3928,6 +4430,9 @@ START_TEST(metafile) > test_emf_paths(); > test_emf_PolyPolyline(); > test_emf_GradientFill(); > + test_emf_WorldTransform_simple(); > + test_emf_WorldTransform_modify(); > + test_emf_WorldTransform_modified_playback(); > You have a lot of duplicated code here. It should be possible to have a single test_emf_WorldTransform() that uses a table to drive these three tests. Could you also make the matrices a little more interesting? Adding a translation would make them non-commuting which would be good to test. Huw.

1 0

Re: [PATCH 3/3] mshtml: Expose IHTMLDOMNode3 interface to scripts.
by Marvin July 19, 2017

July 19, 2017

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=32387 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [v2] gdi32: return non-zero v-refresh value for display devices.
by Huw Davies July 19, 2017

July 19, 2017

On Wed, Jul 19, 2017 at 11:28:58PM +0900, Akihiro Sagawa wrote: > diff --git a/dlls/gdi32/tests/dc.c b/dlls/gdi32/tests/dc.c > index add2c04..2b48542 100644 > --- a/dlls/gdi32/tests/dc.c > +++ b/dlls/gdi32/tests/dc.c > @@ -445,6 +445,7 @@ static void test_device_caps( HDC hdc, HDC ref_dc, const char *descr, int scale > if (type != COMPLEXREGION && type != ERROR) /* region can be complex on multi-monitor setups */ > { > RECT ref_rect; > + int rate = GetDeviceCaps( ref_dc, VREFRESH ); > > ok( type == SIMPLEREGION, "GetClipBox returned %d on %s\n", type, descr ); > if (GetDeviceCaps( ref_dc, TECHNOLOGY ) == DT_RASDISPLAY) > @@ -462,11 +463,15 @@ static void test_device_caps( HDC hdc, HDC ref_dc, const char *descr, int scale > SetRect( &ref_rect, GetSystemMetrics( SM_XVIRTUALSCREEN ), GetSystemMetrics( SM_YVIRTUALSCREEN ), > GetSystemMetrics( SM_XVIRTUALSCREEN ) + GetSystemMetrics( SM_CXVIRTUALSCREEN ), > GetSystemMetrics( SM_YVIRTUALSCREEN ) + GetSystemMetrics( SM_CYVIRTUALSCREEN ) ); > + > + ok( rate >= 1 && rate <= 85, "returned rate is out of range (1 -- 85), got %d\n", rate); Don't check the range, just that it's != 0. Also, please move this to a new VREFRESH case in the switch block higher up in this function. Huw.

1 0

Re: winhttp: Rename host_t to hostdata_t.
by Henri Verbeet July 19, 2017

July 19, 2017

On 19 July 2017 at 17:22, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Commit fa2cc9868b7db7a4cbf7d01a48500cb3f31e109a broke the compilation macOS > because host_t conflicts with a system header file: > > [19:31:41] In file included from ../../../wine/dlls/winhttp/session.c:50: > [19:31:41] ../../../wine/dlls/winhttp/winhttp_private.h:106:3: error: typedef redefinition with different types ('struct host_t' vs 'mach_port_t' (aka 'unsigned int')) > [19:31:41] } host_t; > [19:31:41] ^ > [19:31:41] /build/macos-rootfs/usr/include/mach/mach_types.h:120:22: note: previous definition is here > [19:31:41] typedef mach_port_t host_t; > [19:31:41] ^ > It may be too late for winhttp or Wine in general (although Michael does love these kinds of things), but note that the _t suffix is reserved by POSIX and should in principle be avoided on POSIX systems.

1 0

Re: gdi32: return non-zero v-refresh value for display devices.
by Huw Davies July 19, 2017

July 19, 2017

On Wed, Jul 19, 2017 at 12:11:28AM +0900, Akihiro Sagawa wrote: > > To avoid division by zero (Bug 43369). > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/gdi32/driver.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/gdi32/driver.c b/dlls/gdi32/driver.c > index fe7812c..6a3975a 100644 > --- a/dlls/gdi32/driver.c > +++ b/dlls/gdi32/driver.c > @@ -344,7 +344,7 @@ static INT nulldrv_GetDeviceCaps( PHYSDEV dev, INT cap ) > case PHYSICALOFFSETY: return 0; > case SCALINGFACTORX: return 0; > case SCALINGFACTORY: return 0; > - case VREFRESH: return 0; > + case VREFRESH: return GetDeviceCaps( dev->hdc, TECHNOLOGY ) == DT_RASDISPLAY ? 1 : 0; > case DESKTOPVERTRES: return GetDeviceCaps( dev->hdc, VERTRES ); > case DESKTOPHORZRES: return GetDeviceCaps( dev->hdc, HORZRES ); > case BLTALIGNMENT: return 0; Could you add a test (probably in dc.c:test_device_caps())? The values returned by the testbot range from 1 -- 85, so 1 is as good a choice as any. Huw.

2 2

Re: [v2 3/5] d3dx9: Support skip_constants parameter for effect.
by Matteo Bruni July 18, 2017

July 18, 2017

2017-07-11 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -6397,24 +6464,75 @@ static HRESULT d3dx9_base_effect_init(struct d3dx9_base_effect *base, > TRACE("Tag: %x\n", tag); > } > > + if (skip_constants_string) > + { > + skip_constants_buffer = HeapAlloc(GetProcessHeap(), 0, > + sizeof(*skip_constants_buffer) * (strlen(skip_constants_string) + 1)); I think you can get rid of the sizeof() in this case. If sizeof(*skip_constants_buffer) is not 1 we have bigger problems anyway... > + if (!skip_constants_buffer) > + { > + if (bytecode) > + ID3D10Blob_Release(bytecode); > + return E_OUTOFMEMORY; > + } > + strcpy(skip_constants_buffer, skip_constants_string); Ideally this one should be a memcpy(), reusing the string length computed above. > @@ -588,7 +588,8 @@ static unsigned int *parse_pres_ins(unsigned int *ptr, unsigned int count, struc > return ptr; > } > > -static HRESULT get_ctab_constant_desc(ID3DXConstantTable *ctab, D3DXHANDLE hc, D3DXCONSTANT_DESC *desc) > +static HRESULT get_ctab_constant_desc(ID3DXConstantTable *ctab, D3DXHANDLE hc, D3DXCONSTANT_DESC *desc, > + WORD *constantinfo_reserved) > { > const struct ctab_constant *constant = d3dx_shader_get_ctab_constant(ctab, hc); > > @@ -598,10 +599,13 @@ static HRESULT get_ctab_constant_desc(ID3DXConstantTable *ctab, D3DXHANDLE hc, D > return D3DERR_INVALIDCALL; > } > *desc = constant->desc; > + if (constantinfo_reserved) > + *constantinfo_reserved = constant->constantinfo_reserved; > return D3D_OK; > } For future reference: these (and related) changes should probably have been in a separate patch, or even part of the previous patch in the series. Also, as it becomes more obvious here, one could go one step further with this and directly return struct ctab_constant to the caller. That would essentially make the get_ctab_constant_desc() helper redundant so it could be merged into the callers and removed entirely. > + for (j = 0; j < skip_constants_count; ++j) > + { > + if (!strcmp(cdesc[index].Name, skip_constants[j])) > + { > + if (!constantinfo_reserved) > + { > + WARN("skip_constants parameter %s is not register bound.\n", > + cdesc[index].Name); > + hr = D3DERR_INVALIDCALL; > + goto cleanup; > + } > + TRACE("Skipping constant %s.\n", cdesc[index].Name); > + break; > + } > + } > + if (j < skip_constants_count) > + continue; > + ++out->input_count; > + if (inputs_param[index]->class == D3DXPC_OBJECT) > + continue; > + if (FAILED(hr = init_set_constants_param(out, ctab, hc, inputs_param[index]))) > + goto cleanup; > } > - out->input_count = desc.Constants; > if (out->const_set_count) > { > out->const_set = HeapReAlloc(GetProcessHeap(), 0, out->const_set, Not particularly important but we could shrink out->inputs and out->inputs_param to out->input_count if any parameter was skipped.

1 0

Re: [PATCH 7/7] d3dx9: Support skip_constants parameter for effect.
by Matteo Bruni July 18, 2017

July 18, 2017

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > HRESULT d3dx_create_param_eval(struct d3dx9_base_effect *base_effect, void *byte_code, > unsigned int byte_code_size, D3DXPARAMETER_TYPE type, > - struct d3dx_param_eval **peval, ULONG64 *version_counter) DECLSPEC_HIDDEN; > + struct d3dx_param_eval **peval, ULONG64 *version_counter, > + const char **skip_constants_names, unsigned int skip_constant_name_count) DECLSPEC_HIDDEN; I think you can get rid of the "_name" part in those parameters, for brevity. > +static HRESULT parse_skip_constants_string(char *skip_constants, const char ***names, > + unsigned int *name_count) It's a bit a matter of personal taste but triple pointers look quite ugly to me. In this case you could e.g. return "names" in place of HRESULT. > +{ > + const char *name; > + char *s; > + unsigned int size = INITIAL_CONST_NAMES_SIZE; > + > + *names = HeapAlloc(GetProcessHeap(), 0, sizeof(*names) * size); > + if (!*names) > + return E_OUTOFMEMORY; > + > + *name_count = 0; > + s = skip_constants; > + while ((name = next_valid_constant_name(&s))) > + { > + if (*name_count == size) > + { > + size *= 2; > + *names = HeapReAlloc(GetProcessHeap(), 0, *names, sizeof(*names) * size); > + if (!*names) > + return E_OUTOFMEMORY; I think you're leaking memory on failure here. > + } > + (*names)[(*name_count)++] = name; > + } > + *names = HeapReAlloc(GetProcessHeap(), 0, *names, *name_count * sizeof(*names)); > + if (!*names) > + return E_OUTOFMEMORY; And here. > + for (i = 0; i < skip_constants_name_count; ++i) > + { > + struct d3dx_parameter *param; > + > + param = get_parameter_by_name(base, NULL, skip_constants_names[i]); > + if (param) > + { > + for (j = 0; j < base->technique_count; ++j) > + { > + if (is_parameter_used(param, &base->techniques[j])) > + { > + WARN("Parameter %s found in skip_constants is used in technique %u.\n", > + debugstr_a(skip_constants_names[i]), j); > + HeapFree(GetProcessHeap(), 0, skip_constants_buffer); > + HeapFree(GetProcessHeap(), 0, skip_constants_names); > + d3dx9_base_effect_cleanup(base); > + return D3DERR_INVALIDCALL; > + } > + } > + } > + else > + { > + TRACE("Parameter %s found in skip_constants not found.\n", > + debugstr_a(skip_constants_names[i])); This one sounds a bit awkward ("found... not found"). Maybe just rewrite that as "skip_constants parameter %s not found". You could apply the same trick to the previous message too. > + for (j = 0; j < skip_constant_name_count; ++j) > + { > + if (!strcmp(cdesc[index].Name, skip_constants_names[j])) I assume the skip_constants thing isn't used often and, when it is, very few constants (1-3) are in the list. If that's not the case, we might want to use an rbtree for the constant names.

2 2

Re: [PATCH v2] user32: should restore owned window when restoring owner window.
by Andrew Eikum July 18, 2017

July 18, 2017

On Tue, Jul 18, 2017 at 04:47:05PM +0800, jiang.biao2(a)zte.com.cn wrote: > Is this the right place to commit patches for wine? > > could somebody help to review this patch? > This is the right place to send patches. Your patch needs tests to show that it is correct, and to detect regressions from future changes. Here are some good places to start: https://wiki.winehq.org/Developer_FAQ https://wiki.winehq.org/Submitting_Patches https://wiki.winehq.org/Conformance_Tests Andrew

1 0

Re: [PATCH 4/5] msvcr120: Don't set errno in expm1.
by Piotr Caban July 18, 2017

July 18, 2017

On 07/18/17 06:33, Alex Henrie wrote: > @@ -2421,7 +2421,6 @@ double CDECL MSVCR120_expm1(double x) > #else > double ret = exp(x) - 1; > #endif > - if (!isfinite(ret)) *MSVCRT__errno() = MSVCRT_ERANGE; > return ret; > } The function behaves differently depending on the reason of overflow. It doesn't set ERANGE errno if x == INFINITY (as your tests show). But it does set it when e.g. x == 10e100. Thanks, Piotr

1 0

Re: [PATCH 5/5] ucrtbase/tests: Add tests for errno with math functions.
by Piotr Caban July 18, 2017

July 18, 2017

On 07/18/17 06:33, Alex Henrie wrote: > +#define INF 1.0/0.0 Please define infinity in the same way as it's done in other tests. You can use __port_infinity or call p_strtod("inf"...) to obtain it. Thanks, Piotr

1 0

Re: [PATCH 2/8] regedit: Determine the number of values and subkeys before exporting any data
by Alexandre Julliard July 18, 2017

July 18, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 212 +++++++++++++++++++-------------------------- > 1 file changed, 91 insertions(+), 121 deletions(-) This doesn't seem to be an improvement. The registry can change while you are exporting it, you can't rely on querying things beforehand. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 4/6 v3] gdiplus: Store newer gdi+ version in created GdipRegions
by Vincent Povirk July 17, 2017

July 17, 2017

It'd be very surprising to me if native does this and also requires a recognized version number, as that would break compatibility with 1.0 for no good reason. Based on the spec, they might only be checking the top 20 bits.

2 1

D3D Shaders - how does it work?
by Thomas Berger July 17, 2017

July 17, 2017

Hi, i'm digging in the shader code for some hours right now, to understand what must be done to fix #41173 [1] and #40873 [2]. Right now, i don't really understand how the declaration of variables works in detail. Is there any documentation how the handling and registering of variables works, or should the could be documentation enough? [1] https://bugs.winehq.org/show_bug.cgi?id=41173 [2] https://bugs.winehq.org/show_bug.cgi?id=40873 Greetings, Thomas

4 5

Re: [PATCH] rsaenh: do not use stack variables out of frame (Coverity)
by Jacek Caban July 17, 2017

July 17, 2017

On 15.07.2017 10:07, Marcus Meissner wrote: > 1414721 Pointer to local outside scope > > These harmless looking assignments are of the form: > > algid = BCRYPT_SHA512_ALGORITHM; > > with ../../include/bcrypt.h:#define BCRYPT_SHA512_ALGORITHM (const WCHAR []){'S','H','A','5','1','2',0} > this is > algid = temporary allocated stack variable > > The stack array however goes invalid as soon as it leaves the "switch" case. > > Use a stack temporary array to avoid this confusion. This actually shows a huge problem with using (const WCHAR []){ .... } casts in Wine. In this case it's meant to replace L"..." for wide strings and that in mind, affected code is perfectly fine. It's definition in header that is not compatible. Sadly, I don't see a good solution for that. We could just not not use such casts and use static const variables in headers like we do in many other cases, but that has its own problems. Jacek

1 0

Wineconf sponsorship
by Jeremy White July 17, 2017

July 17, 2017

Hi folks, This is a reminder that the Wine Project uses it's donations to sponsor travel to the annual Wine conference for contributors to Wine. So if you think Wineconf sounds cool, but you can't afford to go, please think again. I can't promise that we'll sponsor everyone, or that we can cover the full cost, but we are very cheerful to try! I'd also invite people that contribute, but perhaps not as developers, to also write in. We are interested in expanding the voices at the conference, and you would be very welcome. You can email me directly to request a sponsorship (or, if you prefer, hit up any of the other committee members - Alexandre, Austin, Marcus, or Michael). Cheers, Jeremy

1 0

Re: [PATCH 3/3] dwrite: Explicitly check rendering parameters pointer passed to DrawGlyphRun()
by Marvin July 17, 2017

July 17, 2017

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=32333 Your paranoid android. === wvistau64 (32 bit font) === font.c:1348: Test failed: Unexpected hr 0. === w2008s64 (32 bit font) === font.c:1348: Test failed: Unexpected hr 0. === w8 (32 bit font) === font.c:5017: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f04:font: unhandled exception c0000005 at 004278C7 === w864 (32 bit font) === font.c:5017: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0eb0:font: unhandled exception c0000005 at 004278C7 === wvistau64 (64 bit font) === font.c:1348: Test failed: Unexpected hr 0. === w2008s64 (64 bit font) === font.c:1348: Test failed: Unexpected hr 0. === w864 (64 bit font) === font.c:5017: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0e8c:font: unhandled exception c0000005 at 00000000004235C2

1 0

Re: [PATCH 2/3] dwrite: Use antialias mode set for bitmap render target
by Marvin July 17, 2017

July 17, 2017

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=32332 Your paranoid android. === wvistau64 (32 bit font) === font.c:1349: Test failed: Unexpected hr 0. === w2008s64 (32 bit font) === font.c:1349: Test failed: Unexpected hr 0. === w8 (32 bit font) === font.c:5018: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f54:font: unhandled exception c0000005 at 004278F7 === w864 (32 bit font) === font.c:5018: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f74:font: unhandled exception c0000005 at 004278F7 === wvistau64 (64 bit font) === font.c:1349: Test failed: Unexpected hr 0. === w2008s64 (64 bit font) === font.c:1349: Test failed: Unexpected hr 0. === w864 (64 bit font) === font.c:5018: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f9c:font: unhandled exception c0000005 at 00000000004235F2

1 0

Re: [PATCH 1/3] dwrite: Improve rendering parameters validation
by Marvin July 17, 2017

July 17, 2017

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=32331 Your paranoid android. === w8 (32 bit font) === font.c:4957: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0ed8:font: unhandled exception c0000005 at 00427387 === w864 (32 bit font) === font.c:4957: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f54:font: unhandled exception c0000005 at 00427387 === w864 (64 bit font) === font.c:4957: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0e88:font: unhandled exception c0000005 at 0000000000423152

1 0

Re: [PATCH 2/6 v2] gdiplus: Test drawing metafile image to emf+ file
by Marvin July 15, 2017

July 15, 2017

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=32319 Your paranoid android. === wxppro (32 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === w2003std (32 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === wvistau64 (32 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === w2008s64 (32 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === wvistau64 (64 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === w2008s64 (64 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record

1 0

Re: [PATCH v2 1/3] explorerframe: Implement ITaskbarList::AddTab() and ::DeleteTab().
by Alexandre Julliard July 14, 2017

July 14, 2017

Zebediah Figura <zfigura(a)codeweavers.com> writes: > ITaskbarList is an interface which allows applications to manually > control which windows appear on the taskbar, as well as what state > they are in (e.g. activated, flashing, progress bar). It also exposes > a function to "redirect" activation to other windows in a process. > > In particular, when using multiple documents in Excel 2010, the > application will delete the button for its main window, and redirect > activation of dummy windows to the child windows containing the > documents. > > Version 2 of this patch: use an internal window message instead of > calling the graphics driver directly. This is necessary because the > interface allows modifying the buttons attached to other processes' > windows. This looks very ad-hoc. I'd like to see a design that would show a credible path towards implementing the entire interface. We can't add new private messages for every bit of functionality. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] gdiplus: Add support for creating image object containing metafile
by Vincent Povirk July 14, 2017

July 14, 2017

This could use a test, just to verify that native can read the emf we create. On Fri, Jul 14, 2017 at 8:18 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdiplus/metafile.c | 47 > ++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 44 insertions(+), 3 deletions(-) > > > > >

1 0

Re: [PATCH 1/2] msvcp140: Implement _Stat and _Lstat (v3).
by Piotr Caban July 14, 2017

July 14, 2017

Hi Stefan, On 07/13/17 17:40, Stefan Dösinger wrote: > +enum msvcp140_file_type { > + msvcp140_file_type_not_found = -1, msvcp140_file_type_none, msvcp140_file_type_regular, > + msvcp140_file_type_directory, msvcp140_file_type_symlink, msvcp140_file_type_block, > + msvcp140_file_type_character, msvcp140_file_type_fifo, msvcp140_file_type_socket, msvcp140_file_type_unknown > +}; Did you consider changing current structure instead of defining new one? I'm talking about something like: enum file_type { #if _MSVCP_VER < 140 status_unknown, file_not_found, #else file_not_found = -1, status_unknown, #endif regular_file, directory_file, ... } Thanks to it you will be able to use the same implementation of _Open_dir/_Read_dir in msvcp120 and msvcp140. > + *permissions = (attr & FILE_ATTRIBUTE_READONLY)?0555:0777; You should also handle permission==NULL case. Thanks, Piotr

2 2

Re: [PATCH 2/2] winhttp/tests: Make sure that all notifications were called before the end of a test.
by Marvin July 14, 2017

July 14, 2017

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=32295 Your paranoid android. === w8 (32 bit notification) === notification.c:602: Test failed: some notifications were missing: 800

1 0

Re: [PATCH 1/2] winhttp/tests: Use notification flags to explicitly mark notifications that should signal an event.
by Marvin July 14, 2017

July 14, 2017

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=32294 Your paranoid android. === w8 (32 bit notification) === notification.c:272: Test failed: got 00000102 notification.c:290: Test failed: unexpected function 8, expected 1. probably some notifications were missing notification.c:90: Test failed: 290: expected status 0x00000800 got 0x00000400 notification.c:91: Test failed: 290: expected function 8 got 1 notification.c:294: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:90: Test failed: 294: expected status 0x00000800 got 0x00000400 notification.c:91: Test failed: 294: expected function 8 got 2 notification.c:301: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:90: Test failed: 301: expected status 0x00000800 got 0x00000010 notification.c:91: Test failed: 301: expected function 8 got 3 notification.c:90: Test failed: 301: expected status 0x00000800 got 0x00000020 notification.c:91: Test failed: 301: expected function 8 got 3 notification.c:91: Test failed: 301: expected function 8 got 3 notification.c:91: Test failed: 301: expected function 8 got 3 notification.c:311: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:90: Test failed: 311: expected status 0x00000800 got 0x00000040 notification.c:91: Test failed: 311: expected function 8 got 4 notification.c:90: Test failed: 311: expected status 0x00000800 got 0x00000080 notification.c:91: Test failed: 311: expected function 8 got 4

1 0

wine-2.0.2-rc3 Available
by Michael Stefaniuc July 13, 2017

July 13, 2017

Hello guys, I have pushed wine-2.0.2-rc3 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Changes since rc2: - Added Steam fix bye michael

1 0

Re: [PATCH 2/6] gdiplus: Add helper for saving path objects in metafile
by Dmitry Timoshkov July 13, 2017

July 13, 2017

Piotr Caban <piotr(a)codeweavers.com> wrote: > +typedef struct EmfPlusPath > +{ > + DWORD Version; > + DWORD PathPointCount; > + DWORD PathPointFlags; > + /* PathPoints[] */ > + /* PathPointTypes[] */ > + /* AlignmentPadding */ > + BYTE data[1]; > +} EmfPlusPath; ... > +static GpStatus METAFILE_AddPathObject(GpMetafile *metafile, GpPath *path, DWORD *id) > +{ ... > + object_record->ObjectData.path.Version = 0xDBC01002; > + object_record->ObjectData.path.PathPointCount = path->pathdata.Count; > + object_record->ObjectData.path.PathPointFlags = 0; This looks very similar to the buffer format returned by GdipGetRegionData(), is it possible to use that API instead of a custom generator? -- Dmitry.

3 2

Meson buildsystem - does make it sense for Wine?
by David Heidelberg July 13, 2017

July 13, 2017

As I recently discovered Meson build system [1] (compatible with Linux, FreeBSD, Windows, Android etc.) which tends to be preferred replacement for autotools (at least recently by many projects). [2] I didn't found any discussion regarding to porting Wine build system. I wounder what is your opinion, could Meson can improve wine build times? Also maybe simplified crossbuilds? Thank you David [1] http://mesonbuild.com/ [2] https://www.youtube.com/watch?v=ae9_rNuFaQM

2 1

Re: [4/5] [v2] ntdll: Provide more accurate virtual memory counters. (rebased)
by Alex Henrie July 13, 2017

July 13, 2017

I don't think this patch is going to be accepted without showing that it makes some application usable that previously was not. -Alex

2 3

Re: [PATCH v2 1/2] explorer: Improve tray sizing and style.
by Alexandre Julliard July 13, 2017

July 13, 2017

Zebediah Figura <zfigura(a)codeweavers.com> writes: > v2: use appropriate system metrics. > Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > --- > programs/explorer/systray.c | 20 +++++++++++--------- > 1 file changed, 11 insertions(+), 9 deletions(-) It's mainly a matter of taste, but this doesn't look better to me. In particular having buttons remain pushed when active feels wrong. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] msvcp140: Implement _Stat and _Lstat (v2).
by Stefan Dösinger July 13, 2017

July 13, 2017

Am 2017-07-13 um 15:05 schrieb Stefan Dösinger: +enum msvcp140_file_type { + file_type_not_found = -1, file_type_none, file_type_regular, + file_type_directory, file_type_symlink, file_type_block, + file_type_character, file_type_fifo, file_type_socket, file_type_unknown +}; Please skip this patch for now, with the changes needed to handle _Open_dir I feel it'd be better to consistently use msvcp140_file_type for the name of the enum type and the enum values. I don't plan any functional changes beyond this cosmetic one, so it should be good to review though.

1 0

Re: [2/6] wsdapi: Add code to create SOAP envelope from header and body elements.
by Alexandre Julliard July 13, 2017

July 13, 2017

Owen Rudge <orudge(a)codeweavers.com> writes: > +#define WCHAR_URN_COLON 'u','r','n',':' > +#define WCHAR_HTTP_COLON_SLASH_SLASH 'h','t','t','p',':','/','/' > +#define WCHAR_SCHEMAS 's','c','h','e','m','a','s' > +#define WCHAR_SOAP 's','o','a','p' > +#define WCHAR_XMLSOAP 'x','m','l',WCHAR_SOAP > +#define WCHAR_ORG 'o','r','g' > +#define WCHAR_WS_SLASH 'w','s','/' > +#define WCHAR_SCHEMAS_DOT_XML_SOAP_DOT_ORG WCHAR_SCHEMAS,'.',WCHAR_XMLSOAP,'.',WCHAR_ORG > +#define WCHAR_DISCOVERY 'd','i','s','c','o','v','e','r','y' > +#define WCHAR_MESSAGE 'M','e','s','s','a','g','e' > +#define WCHAR_SEQUENCE 'S','e','q','u','e','n','c','e' > + > +static const WCHAR addressingNsUri[] = { > + WCHAR_HTTP_COLON_SLASH_SLASH, > + WCHAR_SCHEMAS_DOT_XML_SOAP_DOT_ORG,'/', > + WCHAR_WS_SLASH,'2','0','0','4','/','0','8','/','a','d','d','r','e','s','s','i','n','g', 0 }; > + > +static const WCHAR discoveryNsUri[] = { > + WCHAR_HTTP_COLON_SLASH_SLASH, > + WCHAR_SCHEMAS_DOT_XML_SOAP_DOT_ORG,'/', > + WCHAR_WS_SLASH,'2','0','0','5','/','0','4','/',WCHAR_DISCOVERY, 0 }; > + > +static const WCHAR envelopeNsUri[] = { > + WCHAR_HTTP_COLON_SLASH_SLASH, > + 'w','w','w','.','w','3','.',WCHAR_ORG,'/', > + '2','0','0','3','/','0','5','/',WCHAR_SOAP,'-','e','n','v','e','l','o','p','e', 0 }; > + > +static const WCHAR addressingPrefix[] = { 'w','s','a', 0 }; > +static const WCHAR discoveryPrefix[] = { 'w','s','d', 0 }; > +static const WCHAR envelopePrefix[] = { WCHAR_SOAP, 0 }; > +static const WCHAR headerString[] = { 'H','e','a','d','e','r', 0 }; > +static const WCHAR actionString[] = { 'A','c','t','i','o','n', 0 }; > +static const WCHAR messageIdString[] = { WCHAR_MESSAGE,'I','D', 0 }; > +static const WCHAR toString[] = { 'T','o', 0 }; > +static const WCHAR relatesToString[] = { 'R','e','l','a','t','e','s','T','o', 0 }; > +static const WCHAR appSequenceString[] = { 'A','p','p',WCHAR_SEQUENCE, 0 }; > +static const WCHAR instanceIdString[] = { 'I','n','s','t','a','n','c','e','I','d', 0 }; > +static const WCHAR messageNumberString[] = { WCHAR_MESSAGE,'N','u','m','b','e','r', 0 }; > +static const WCHAR sequenceIdString[] = { WCHAR_SEQUENCE,'I','d', 0 }; > +static const WCHAR emptyString[] = { 0 }; I think this would be more readable (and more greppable) without the #defines. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ws2_32: Set return size when calling WSAIoctl with WS_SIO_GET_EXTENSION_FUNCTION_POINTER.
by Sebastian Lackner July 13, 2017

July 13, 2017

On 13.07.2017 06:20, Alistair Leslie-Hughes wrote: > This is a backbort of the above change, borrowed from Codeweavers. :) > > Target: 2.0.* branch. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/ws2_32/socket.c | 1 + > 1 file changed, 1 insertion(+) > It probably does not matter in practice (and I don't think we have any tests for it yet), but please note that this not equivalent to the code we have in the development branch. It also changes error handling in a completely unrelated situation (when a extension is not found). Why not just backport 914e401aa9d5401893c3807d51e3f19fc7a7ab38 plus the fix?

2 1

Re: [PATCH 4/5 v3] msvcr120: Add acosh.
by Alex Henrie July 12, 2017

July 12, 2017

Alexandre, when you apply these patches, you don't have to keep the "From: Alex Henrie" line. The acosh and atanh implementations are now more Piotr's work than they are mine, although I'm happy to sign off on them. -Alex

1 0

Re: [PATCH 4/5 v2] msvcr120: Add acosh.
by Alex Henrie July 12, 2017

July 12, 2017

/********************************************************************* + * acosh (MSVCR120.@) + */ +double CDECL MSVCR120_acosh(double x) +{ + if (x < 1) { + *MSVCRT__errno() = MSVCRT_EDOM; + return NAN; + } +#ifdef HAVE_ACOSH + return acosh(x); +#else + if (!isfinite(x*x)) return log(2) + log(x); + return log(x + sqrt(x*x-1)); +#endif +} + +/********************************************************************* + * acoshf (MSVCR120.@) + */ +float CDECL MSVCR120_acoshf(float x) +{ +#ifdef HAVE_ACOSHF + return acoshf(x); +#else + return MSVCR120_acosh(x); +#endif +} Thanks for the help. Are you sure that acosh and atanh require bounds checking, but acoshf and atanhf do not? Also, aren't they supposed to set an exception flag if x is less than 1? -Alex

2 1

wine-2.0.2-rc2 Available
by Michael Stefaniuc July 12, 2017

July 12, 2017

Hello guys, I have pushed wine-2.0.2-rc2 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Changes rc1: - Added the commit "ddraw: Validate the "surface" pointer before creating the surface in CreateSurface()." Required by patches included in rc1 that were trading crashes for mem leaks (Thanks Sebastian and Henri). Please let me if you feel strongly about the inclusion of the outstanding Steam fix into wine-2.0.2. As it isn't in devel yet I would tend to defer it to 2.0.3 and I'm not opposed to do an earlier release for that in early to mid August. thanks bye michael

1 0

Re: [PATCH 8/9] msvcr120: Add expm1.
by Piotr Caban July 12, 2017

July 12, 2017

On 07/10/17 06:55, Alex Henrie wrote: > +float CDECL MSVCR120_expm1f(float x) > +{ > +#ifdef HAVE_EXPM1F > + return expm1f(x); > +#else > + return exp(x) - 1; > +#endif > +} Please set errno on invalid arguments. Thanks, Piotr

1 0

Re: [PATCH 2/3] Add mfuuid.lib
by Alexandre Julliard July 11, 2017

July 11, 2017

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > +DEFINE_GUID(CLSID_MFReadWriteClassFactory, 0x48e2ed0f, 0x98c2, 0x4a37, 0xbe, 0xd5, 0x16, 0x63, 0x12, 0xdd, 0xd8, 0x3f); > +DEFINE_GUID(CLSID_MFSourceReader, 0x1777133c, 0x0881, 0x411b, 0xa5, 0x77, 0xad, 0x54, 0x5f, 0x07, 0x14, 0xc4); > +DEFINE_GUID(CLSID_MFSinkWriter, 0xa3bbfb17, 0x8273, 0x4e52, 0x9e, 0x0e, 0x97, 0x39, 0xdc, 0x88, 0x79, 0x90); > + > +DEFINE_GUID(MF_SINK_WRITER_ASYNC_CALLBACK, 0x48cb183e, 0x7b0b, 0x46f4, 0x82, 0x2e, 0x5e, 0x1d, 0x2d, 0xda, 0x43, 0x54); > +DEFINE_GUID(MF_SINK_WRITER_DISABLE_THROTTLING, 0x08b845d8, 0x2b74, 0x4afe, 0x9d, 0x53, 0xbe, 0x16, 0xd2, 0xd5, 0xae, 0x4f); > +DEFINE_GUID(MF_SINK_WRITER_D3D_MANAGER, 0xec822da2, 0xe1e9, 0x4b29, 0xa0, 0xd8, 0x56, 0x3c, 0x71, 0x9f, 0x52, 0x69); > +DEFINE_GUID(MF_SINK_WRITER_ENCODER_CONFIG, 0xad91cd04, 0xa7cc, 0x4ac7, 0x99, 0xb6, 0xa5, 0x7b, 0x9a, 0x4a, 0x7c, 0x70); > + > +DEFINE_GUID(MF_READWRITE_DISABLE_CONVERTERS, 0x98d5b065, 0x1374, 0x4847, 0x8d, 0x5d, 0x31, 0x52, 0x0f, 0xee, 0x71, 0x56); > +DEFINE_GUID(MF_READWRITE_ENABLE_HARDWARE_TRANSFORMS, 0xa634a91c, 0x822b, 0x41b9, 0xa4, 0x94, 0x4d, 0xe4, 0x64, 0x36, 0x12, 0xb0); > +DEFINE_GUID(MF_READWRITE_MMCSS_CLASS, 0x39384300, 0xd0eb, 0x40b1, 0x87, 0xa0, 0x33, 0x18, 0x87, 0x1b, 0x5a, 0x53); > +DEFINE_GUID(MF_READWRITE_MMCSS_PRIORITY, 0x43ad19ce, 0xf33f, 0x4ba9, 0xa5, 0x80, 0xe4, 0xcd, 0x12, 0xf2, 0xd1, 0x44); > +DEFINE_GUID(MF_READWRITE_MMCSS_CLASS_AUDIO, 0x430847da, 0x0890, 0x4b0e, 0x93, 0x8c, 0x05, 0x43, 0x32, 0xc5, 0x47, 0xe1); > +DEFINE_GUID(MF_READWRITE_MMCSS_PRIORITY_AUDIO, 0x273db885, 0x2de2, 0x4db2, 0xa6, 0xa7, 0xfd, 0xb6, 0x6f, 0xb4, 0x0b, 0x61); > +DEFINE_GUID(MF_READWRITE_D3D_OPTIONAL, 0x216479d9, 0x3071, 0x42ca, 0xbb, 0x6c, 0x4c, 0x22, 0x10, 0x2e, 0x1d, 0x18); I don't see any of these in the PSDK mfuuid library. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2 2/2] user32: Activate another window upon minimizing.
by Marvin July 11, 2017

July 11, 2017

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=32251 Your paranoid android. === w7u (32 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00AC013C fg 000301B4 in hook HCBT_MINMAX win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000500D8 fg 000301B4 in hook HCBT_MINMAX === w7pro64 (32 bit win) === win.c:9852: Test failed: expected 000A015E, got 0006011E win.c:9858: Test failed: expected 000A015E, got 0006011E win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00070134 fg 00070160 in hook HCBT_MINMAX === w7pro64 (64 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000000000007015A fg 0000000000070160 in hook HCBT_MINMAX

1 0

Re: [PATCH v2 1/2] user32/tests: Add tests for activating windows.
by Marvin July 11, 2017

July 11, 2017

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=32250 Your paranoid android. === w7pro64 (32 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00070106 fg 00070160 in hook HCBT_MINMAX === w864 (32 bit win) === win.c:2331: Test failed: expected !100 win.c:2331: Test failed: expected !100 === w7pro64 (64 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0000000000070106 fg 0000000000070160 in hook HCBT_MINMAX

1 0

Re: [PATCH 3/3] user32/tests: Use todo_wine for failing z-order tests.
by Marvin July 11, 2017

July 11, 2017

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=32243 Your paranoid android. === wxppro (32 bit win) === win.c:9961: Test failed: GetActiveWindow() = 00020152 win.c:9961: Test failed: GetFocus() = 00020152 === w2003std (32 bit win) === win.c:9961: Test failed: GetActiveWindow() = 000400F6 win.c:9961: Test failed: GetFocus() = 000400F6 === wvistau64 (32 bit win) === win.c:9961: Test failed: GetActiveWindow() = 00050120 win.c:9961: Test failed: GetFocus() = 00050120 === w2008s64 (32 bit win) === win.c:9961: Test failed: GetActiveWindow() = 00080124 win.c:9961: Test failed: GetFocus() = 00080124 === w7u (32 bit win) === win.c:3001: Test failed: 0011013C: expected next 00000000, got 000301B8 win.c:3003: Test failed: 00100192: expected prev 000301AC, got 000A01B6 win.c:3004: Test failed: 000301AC: expected next 00100192, got 00000000 win.c:3005: Test failed: 000901BA: expected prev 000A01B6, got 0011013C win.c:3006: Test failed: 000A01B6: expected next 000901BA, got 00100192 win.c:3015: Test failed: 0011013C: expected next 00000000, got 000301B8 win.c:3016: Test failed: 00100192: expected prev 000301AC, got 000A01B6 win.c:3017: Test failed: 000301AC: expected next 00100192, got 00000000 win.c:3018: Test failed: 000901BA: expected prev 000A01B6, got 0011013C win.c:3019: Test failed: 000A01B6: expected next 000901BA, got 00100192 win.c:3001: Test failed: 0012013C: expected next 00000000, got 000301B8 win.c:3003: Test failed: 000B01B6: expected prev 000301AC, got 009E015A win.c:3004: Test failed: 000301AC: expected next 000B01B6, got 00000000 win.c:3005: Test failed: 000901BA: expected prev 009E015A, got 0012013C win.c:3006: Test failed: 009E015A: expected next 000901BA, got 000B01B6 win.c:3015: Test failed: 0012013C: expected next 00000000, got 000301B8 win.c:3016: Test failed: 000B01B6: expected prev 000301AC, got 009E015A win.c:3017: Test failed: 000301AC: expected next 000B01B6, got 00000000 win.c:3018: Test failed: 000901BA: expected prev 009E015A, got 0012013C win.c:3019: Test failed: 009E015A: expected next 000901BA, got 000B01B6 === w7pro64 (32 bit win) === win.c:9968: Test failed: expected 000B015E, got 00050024 === w8 (32 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0009012E fg 000400FA in hook HCBT_MINMAX === wvistau64 (64 bit win) === win.c:9961: Test failed: GetActiveWindow() = 0000000000050120 win.c:9961: Test failed: GetFocus() = 0000000000050120 === w2008s64 (64 bit win) === win.c:9961: Test failed: GetActiveWindow() = 0000000000080124 win.c:9961: Test failed: GetFocus() = 0000000000080124 === w7pro64 (64 bit win) === win.c:9968: Test failed: expected 00000000000B015E, got 000000000006011E === w864 (64 bit win) === win.c:9968: Test failed: expected 00000000000B015C, got 0000000000050028

1 0

Re: [PATCH 2/3] user32: Activate another window upon minimizing.
by Marvin July 11, 2017

July 11, 2017

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=32242 Your paranoid android. === wxppro (32 bit win) === win.c:9939: Test failed: GetActiveWindow() = 00020152 win.c:9939: Test failed: GetFocus() = 00020152 === w2003std (32 bit win) === win.c:9939: Test failed: GetActiveWindow() = 000400F6 win.c:9939: Test failed: GetFocus() = 000400F6 === wvistau64 (32 bit win) === win.c:9939: Test failed: GetActiveWindow() = 00050120 win.c:9939: Test failed: GetFocus() = 00050120 === w2008s64 (32 bit win) === win.c:9939: Test failed: GetActiveWindow() = 00080124 win.c:9939: Test failed: GetFocus() = 00080124 === w7pro64 (32 bit win) === win.c:9946: Test failed: expected 000B00FC, got 0006011E === w8 (32 bit win) === win.c:9946: Test failed: expected 000B0132, got 0006011A === w864 (32 bit win) === win.c:9946: Test failed: expected 000B015C, got 0004001C === wvistau64 (64 bit win) === win.c:9939: Test failed: GetActiveWindow() = 0000000000050120 win.c:9939: Test failed: GetFocus() = 0000000000050120 === w2008s64 (64 bit win) === win.c:9939: Test failed: GetActiveWindow() = 0000000000080124 win.c:9939: Test failed: GetFocus() = 0000000000080124 === w7pro64 (64 bit win) === win.c:9852: Test failed: expected 00000000000A015A, got 0000000000050024 win.c:9858: Test failed: expected 00000000000A015A, got 0000000000050024 win.c:9946: Test failed: expected 00000000000B015A, got 0000000000050024 === w864 (64 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0000000000050192 fg 0000000000050020 in hook HCBT_MINMAX === w1064 (64 bit win) === win.c:9946: Test failed: expected 0000000000080042, got 000000000003002E

1 0

Re: [PATCH 1/3] user32/tests: Add tests for activating windows.
by Marvin July 11, 2017

July 11, 2017

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=32241 Your paranoid android. === wxppro (32 bit win) === win.c:9940: Test failed: GetActiveWindow() = 00020152 win.c:9940: Test failed: GetFocus() = 00020152 === w2003std (32 bit win) === win.c:9940: Test failed: GetActiveWindow() = 000400F6 win.c:9940: Test failed: GetFocus() = 000400F6 === wvistau64 (32 bit win) === win.c:9940: Test failed: GetActiveWindow() = 00050120 win.c:9940: Test failed: GetFocus() = 00050120 === w2008s64 (32 bit win) === win.c:9940: Test failed: GetActiveWindow() = 00080124 win.c:9940: Test failed: GetFocus() = 00080124 === w7u (32 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00A70144 fg 000B0188 in hook HCBT_MINMAX win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000700F8 fg 000B0188 in hook HCBT_MINMAX win.c:9962: Test failed: expected 000B00F0, got 000801AA win.c:9981: Test failed: expected 000B00F0, got 000801AA === wvistau64 (64 bit win) === win.c:9940: Test failed: GetActiveWindow() = 0000000000050120 win.c:9940: Test failed: GetFocus() = 0000000000050120 === w2008s64 (64 bit win) === win.c:9940: Test failed: GetActiveWindow() = 0000000000080124 win.c:9940: Test failed: GetFocus() = 0000000000080124 === w7pro64 (64 bit win) === win.c:9947: Test failed: expected 00000000000B015E, got 0000000000050024

1 0

Re: [PATCH 3/6] gdiplus: Support GdipSetSmoothingMode in metafiles
by Vincent Povirk July 11, 2017

July 11, 2017

According to the spec, SmoothingModeHighSpeed also does no antialiasing.

2 1

Re: [PATCH 7/9] msvcr120: Add erfc.
by Piotr Caban July 11, 2017

July 11, 2017

On 07/10/17 06:55, Alex Henrie wrote: > /********************************************************************* > + * erfc (MSVCR120.@) > + */ > +double CDECL MSVCR120_erfc(double x) > +{ > +#ifdef HAVE_ERFC > + return erfc(x); > +#else > + FIXME( "not implemented\n" ); > + return 0.0; > +#endif You can return 1.0 - MSVCR120_erf(x) if erfc is not available. Thanks, Piotr

2 2

Re: winhttp/tests: Make notification tests more strict.
by Marvin July 11, 2017

July 11, 2017

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=32231 Your paranoid android. === w7pro64 (32 bit notification) === notification.c:219: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:89: Test failed: 219: expected status 0x00000800 got 0x00000400 notification.c:90: Test failed: 219: expected function 8 got 2 notification.c:226: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:89: Test failed: 226: expected status 0x00000800 got 0x00000010 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:89: Test failed: 226: expected status 0x00000800 got 0x00000020 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:236: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:89: Test failed: 236: expected status 0x00000800 got 0x00000040 notification.c:90: Test failed: 236: expected function 8 got 4 notification.c:89: Test failed: 236: expected status 0x00000800 got 0x00000080 notification.c:90: Test failed: 236: expected function 8 got 4 notification.c:248: Test failed: unexpected function 2, expected 8. probably some notifications were missing notification.c:89: Test failed: 248: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 248: expected function 2 got 8 notification.c:89: Test failed: 248: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 248: expected function 2 got 8 notification.c:282: Test failed: unexpected function 2, expected 1. probably some notifications were missing notification.c:90: Test failed: 282: expected function 2 got 1 notification.c:315: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:89: Test failed: 315: expected status 0x00000800 got 0x00000400 notification.c:90: Test failed: 315: expected function 8 got 2 notification.c:322: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:89: Test failed: 322: expected status 0x00000800 got 0x00000010 notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:89: Test failed: 322: expected status 0x00000800 got 0x00000020 notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:332: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:89: Test failed: 332: expected status 0x00000800 got 0x00000040 notification.c:90: Test failed: 332: expected function 8 got 4 notification.c:89: Test failed: 332: expected status 0x00000800 got 0x00000080 notification.c:90: Test failed: 332: expected function 8 got 4 notification.c:89: Test failed: 341: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 341: expected function 1 got 8 === w1064 (64 bit notification) === notification.c:219: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:89: Test failed: 219: expected status 0x00000800 got 0x00000400 notification.c:90: Test failed: 219: expected function 8 got 2 notification.c:226: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:89: Test failed: 226: expected status 0x00000800 got 0x00000010 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:89: Test failed: 226: expected status 0x00000800 got 0x00000020 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:90: Test failed: 219: expected function 8 got 2 notification.c:236: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:89: Test failed: 236: expected status 0x00000800 got 0x00000040 notification.c:90: Test failed: 236: expected function 8 got 4 notification.c:89: Test failed: 236: expected status 0x00000800 got 0x00000080 notification.c:90: Test failed: 236: expected function 8 got 4 notification.c:248: Test failed: unexpected function 2, expected 8. probably some notifications were missing notification.c:89: Test failed: 248: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 248: expected function 2 got 8 notification.c:89: Test failed: 248: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 248: expected function 2 got 8 notification.c:282: Test failed: unexpected function 2, expected 1. probably some notifications were missing notification.c:90: Test failed: 282: expected function 2 got 1 notification.c:315: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:89: Test failed: 315: expected status 0x00000800 got 0x00000400 notification.c:90: Test failed: 315: expected function 8 got 2 notification.c:322: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:89: Test failed: 322: expected status 0x00000800 got 0x00000010 notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:89: Test failed: 322: expected status 0x00000800 got 0x00000020 notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:332: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:89: Test failed: 332: expected status 0x00000800 got 0x00000040 notification.c:90: Test failed: 332: expected function 8 got 4 notification.c:89: Test failed: 332: expected status 0x00000800 got 0x00000080 notification.c:90: Test failed: 332: expected function 8 got 4

1 0

Re: [PATCH 4/4] msvcp140: Implement _Stat and _Lstat.
by Marvin July 11, 2017

July 11, 2017

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=32230 Your paranoid android. === wvistau64 (32 bit msvcp140) === 0504:msvcp140: unhandled exception c0000005 at 00000000 === wvistau64 (64 bit msvcp140) === 0504:msvcp140: unhandled exception c0000005 at 0000000000000000

1 0

Re: [PATCH 1/2] advapi32/tests: Statically link to ConvertSidToStringSidA()
by Dmitry Timoshkov July 11, 2017

July 11, 2017

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > -static BOOL (WINAPI *pConvertSidToStringSidA)( PSID pSid, LPSTR *str ); > static BOOL (WINAPI *pConvertStringSidToSidA)( LPCSTR str, PSID pSid ); ... > - pConvertSidToStringSidA = (void *)GetProcAddress(hmod, "ConvertSidToStringSidA"); > pConvertStringSidToSidA = (void *)GetProcAddress(hmod, "ConvertStringSidToSidA"); ... > - if( !pConvertSidToStringSidA || !pConvertStringSidToSidA ) > + if( !pConvertStringSidToSidA ) What's so special about ConvertSidToStringSidA and why same logic won't apply to ConvertStringSidToSidA and possibly others? -- Dmitry.

2 2

Re: [PATCH 7/7] gdiplus: Add EMF+ properties records tests
by Piotr Caban July 11, 2017

July 11, 2017

On 07/11/17 11:42, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdiplus/tests/metafile.c | 78 > +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 78 insertions(+) > I've sent it incorrectly so it wasn't picked by testbot. Here are the results: https://testbot.winehq.org/JobDetails.pl?Key=32226 Thanks, Piotr

1 0

Re: [PATCH 2/6] gdiplus: Support GdipSetPixelOffsetMode in metafiles
by Dmitry Timoshkov July 11, 2017

July 11, 2017

Piotr Caban <piotr(a)codeweavers.com> wrote: > + if(graphics->pixeloffset == mode) > + return Ok; This particular change would need an approproate test case to confirm that repetitive GdipSetPixelOffsetMode() calls with the same value won't generate new records. Same applies to other patches in the series. -- Dmitry.

1 1

Re: [PATCH 1/7] d3dx9/tests: Add test for skip_constants effect parameter.
by Matteo Bruni July 11, 2017

July 11, 2017

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +static void test_effect_skip_constants(IDirect3DDevice9 *device) > +{ > + HRESULT hr; > + ID3DXEffect *effect; > + unsigned int passes_count; > + D3DXVECTOR4 fvect; > + unsigned int i; > + > + hr = D3DXCreateEffectEx(device, test_effect_skip_constants_blob, sizeof(test_effect_skip_constants_blob), > + NULL, NULL, "v3", 0, NULL, &effect, NULL); > + todo_wine > + ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > + if (SUCCEEDED(hr)) > + effect->lpVtbl->Release(effect); > + hr = D3DXCreateEffectEx(device, test_effect_skip_constants_blob, sizeof(test_effect_skip_constants_blob), > + NULL, NULL, "v4", 0, NULL, &effect, NULL); > + todo_wine > + ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > + if (SUCCEEDED(hr)) > + effect->lpVtbl->Release(effect); > + > + hr = D3DXCreateEffectEx(device, test_effect_skip_constants_blob, sizeof(test_effect_skip_constants_blob), > + NULL, NULL, " v1#,.+-= &\t\nv2*/!\"'v5 v6[1]", 0, NULL, &effect, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); Maybe also add a test with the "expected" syntax for the skip_constants parameters? MSDN mentions a semicolon-separated list. Of course it's not strictly needed, given this test... > + > + todo_wine > + ok(!effect->lpVtbl->IsParameterUsed(effect, "v1", "tech0"), > + "Unexpected IsParameterUsed result.\n"); > + todo_wine > + ok(!effect->lpVtbl->IsParameterUsed(effect, "v2", "tech0"), > + "Unexpected IsParameterUsed result.\n"); > + ok(effect->lpVtbl->IsParameterUsed(effect, "v3", "tech0"), > + "Unexpected IsParameterUsed result.\n"); > + ok(effect->lpVtbl->IsParameterUsed(effect, "v4", "tech0"), > + "Unexpected IsParameterUsed result.\n"); > + ok(!effect->lpVtbl->IsParameterUsed(effect, "v5", "tech0"), > + "Unexpected IsParameterUsed result.\n"); What about "v6"?

2 1

Re: [PATCH 5/7] d3dx9: Fail effect creation when shader parameter evaluator creation fails.
by Matteo Bruni July 11, 2017

July 11, 2017

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -6099,8 +6100,9 @@ static HRESULT d3dx9_parse_resource(struct d3dx9_base_effect *base, const char * > { > if (FAILED(hr = d3dx9_create_object(base, object))) > return hr; > - d3dx_create_param_eval(base, object->data, object->size, param->type, > - &param->param_eval, get_version_counter_ptr(base)); > + if (FAILED(hr = d3dx_create_param_eval(base, object->data, object->size, param->type, > + &param->param_eval, get_version_counter_ptr(base)))) > + return hr; > } > break; > > @@ -6138,8 +6140,11 @@ static HRESULT d3dx9_parse_resource(struct d3dx9_base_effect *base, const char * It looks like you missed another call to d3dx_create_param_eval() in between these two.

2 1

Re: [PATCH 2/5] regedit: Use 'return' statements in delete_registry_key() to allow for memory clean-up
by Alexandre Julliard July 11, 2017

July 11, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -1593,11 +1593,11 @@ void delete_registry_key(WCHAR *reg_key_name) > > if (!(key_class = parse_key_name(reg_key_name, &key_name))) { > output_message(STRING_INCORRECT_REG_CLASS, reg_key_name); > - exit(1); > + return; > } > if (!*key_name) { > output_message(STRING_DELETE_REG_CLASS_FAILED, reg_key_name); > - exit(1); > + return; If the process is going to exit anyway, freeing memory is a waste of time. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 3/9] msvcr120: Remove precompiler check for asinh.
by Piotr Caban July 11, 2017

July 11, 2017

On 07/10/17 06:55, Alex Henrie wrote: > asinh is part of C89, so it is guaranteed to be present. Are you sure about it? As far as I know it's part of C99. The manual for asinh looks strange (it says that it conforms to C89 and gives test macro that checks for never standards). Thanks, Piotr

4 7

Re: [PATCH 6/7] d3dx9: Implement d3dx_shader_get_raw_constant_info() function.
by Matteo Bruni July 10, 2017

July 10, 2017

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/d3dx9_private.h | 3 +++ > dlls/d3dx9_36/shader.c | 18 ++++++++++++++++++ > 2 files changed, 21 insertions(+) > > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index db80490..bfb3909 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -355,4 +355,7 @@ HRESULT d3dx_param_eval_set_shader_constants(ID3DXEffectStateManager *manager, s > struct d3dx_param_eval *peval, BOOL update_all) DECLSPEC_HIDDEN; > BOOL is_param_eval_input_dirty(struct d3dx_param_eval *peval, ULONG64 update_version) DECLSPEC_HIDDEN; > > +const D3DXSHADER_CONSTANTINFO *d3dx_shader_get_raw_constant_info(ID3DXConstantTable *iface, > + D3DXHANDLE constant) DECLSPEC_HIDDEN; > + > #endif /* __WINE_D3DX9_PRIVATE_H */ > diff --git a/dlls/d3dx9_36/shader.c b/dlls/d3dx9_36/shader.c > index 4dbecb1..11527c8 100644 > --- a/dlls/d3dx9_36/shader.c > +++ b/dlls/d3dx9_36/shader.c > @@ -682,6 +682,7 @@ HRESULT WINAPI D3DXPreprocessShaderFromResourceW(HMODULE module, const WCHAR *re > } > > struct ctab_constant { > + const D3DXSHADER_CONSTANTINFO *raw_constant_info; > D3DXCONSTANT_DESC desc; > struct ctab_constant *constants; > }; > @@ -946,6 +947,22 @@ static HRESULT WINAPI ID3DXConstantTableImpl_GetDesc(ID3DXConstantTable *iface, > return D3D_OK; > } > > +const D3DXSHADER_CONSTANTINFO *d3dx_shader_get_raw_constant_info(ID3DXConstantTable *iface, D3DXHANDLE constant) > +{ > + struct ID3DXConstantTableImpl *const_table = impl_from_ID3DXConstantTable(iface); > + struct ctab_constant *c = get_valid_constant(const_table, constant); > + > + TRACE("const_table %p, constant %p.\n", const_table, constant); > + > + if (!c) > + { > + WARN("Invalid argument specified.\n"); > + return NULL; > + } > + > + return c->raw_constant_info; > +} > + > static HRESULT WINAPI ID3DXConstantTableImpl_GetConstantDesc(ID3DXConstantTable *iface, D3DXHANDLE constant, > D3DXCONSTANT_DESC *desc, UINT *count) > { > @@ -2052,6 +2069,7 @@ HRESULT WINAPI D3DXGetShaderConstantTableEx(const DWORD *byte_code, DWORD flags, > { > object->constants[i].desc.RegisterCount = constant_info[i].RegisterCount; > } > + object->constants[i].raw_constant_info = &constant_info[i]; > } > > *constant_table = &object->ID3DXConstantTable_iface; I don't like this all that much. If you need access to the original D3DXSHADER_CONSTANTINFO only for the Reserved field, as in the next patch, I'd say just store that one in struct ctab_constant. Then, for the retrieval part, I don't think it makes much sense to hide our internals from ourselves. You could move the definition of struct ctab_constant to d3dx9_private.h and introduce an internal function to return it from the constant table. You could then entirely replace the use of ID3DXConstantTable_GetConstantDesc(), if you want. Otherwise you can keep that part as-is for the time being and make use of the new function only to get to the Reserved data. Actually, if you go with the latter, it probably makes sense to merge this patch into the next.

1 0

Re: [PATCH 4/7] d3dx9: Get rid of init_set_constants() function.
by Matteo Bruni July 10, 2017

July 10, 2017

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 58 ++++++++++++++--------------------------------- > 1 file changed, 17 insertions(+), 41 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index cabddcd..1aaf59d 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -305,7 +305,8 @@ static unsigned int get_reg_components(unsigned int table) > > #define PRES_BITMASK_BLOCK_SIZE (sizeof(unsigned int) * 8) > > -static HRESULT init_set_constants(struct d3dx_const_tab *const_tab, ID3DXConstantTable *ctab); > +static HRESULT init_set_constants_param(struct d3dx_const_tab *const_tab, ID3DXConstantTable *ctab, > + D3DXHANDLE hc, struct d3dx_parameter *param); With some function reordering this forward declaration shouldn't be necessary at all.

1 0

Re: [PATCH 3/7] d3dx9: Simplify init and cleanup in get_constants_desc().
by Matteo Bruni July 10, 2017

July 10, 2017

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 17 +++-------------- > 1 file changed, 3 insertions(+), 14 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 2fb14ab..cabddcd 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -618,10 +618,6 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > D3DXHANDLE hc; > unsigned int i; > > - out->inputs = cdesc = NULL; > - out->inputs_param = NULL; > - out->input_count = 0; > - inputs_param = NULL; > hr = D3DXGetShaderConstantTable(byte_code, &ctab); > if (FAILED(hr) || !ctab) > { > @@ -635,8 +631,8 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > goto err_out; > } > > - cdesc = HeapAlloc(GetProcessHeap(), 0, sizeof(*cdesc) * desc.Constants); > - inputs_param = HeapAlloc(GetProcessHeap(), 0, sizeof(*inputs_param) * desc.Constants); > + out->inputs = cdesc = HeapAlloc(GetProcessHeap(), 0, sizeof(*cdesc) * desc.Constants); > + out->inputs_param = inputs_param = HeapAlloc(GetProcessHeap(), 0, sizeof(*inputs_param) * desc.Constants); > if (!cdesc || !inputs_param) > { > hr = E_OUTOFMEMORY; > @@ -678,16 +674,9 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > } > } > out->input_count = desc.Constants; > - out->inputs = cdesc; > - out->inputs_param = inputs_param; > hr = init_set_constants(out, ctab); > - ID3DXConstantTable_Release(ctab); > - return hr; > err_out: > - HeapFree(GetProcessHeap(), 0, cdesc); > - HeapFree(GetProcessHeap(), 0, inputs_param); > - if (ctab) > - ID3DXConstantTable_Release(ctab); > + ID3DXConstantTable_Release(ctab); > return hr; > } It would be a nice cleanup to rename the err_out: label to cleanup:, done: or similar.

1 0

Re: [PATCH 1/2] widl: Only generate Proxy Stubs when functions have the call_as attribute
by Nikolay Sivov July 10, 2017

July 10, 2017

On 10.07.2017 7:43, Alistair Leslie-Hughes wrote: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=43302 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > tools/widl/header.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/widl/header.c b/tools/widl/header.c > index 7b97158..e48b488 100644 > --- a/tools/widl/header.c > +++ b/tools/widl/header.c > @@ -1172,7 +1172,7 @@ static void write_method_proto(FILE *header, const type_t *iface) > { > const var_t *func = stmt->u.var; > > - if (!is_local(func->attrs)) { > + if (is_callas(func->attrs)) { > const char *callconv = get_attrp(func->type->attrs, ATTR_CALLCONV); > if (!callconv) callconv = "STDMETHODCALLTYPE"; > /* proxy prototype */ > This is wrong, 'call_as' is used to map different method to be used for remote calls. Midl certainly does not limit prototype generation like that. You mentioned 'odl' attribute on bug report, it's irrelevant too.

2 2

Re: [v2 PATCH] widl: Only generate Proxy Stubs when functions have the call_as attribute
by Huw Davies July 10, 2017

July 10, 2017

On Mon, Jul 10, 2017 at 10:11:42AM +0000, Alistair Leslie-Hughes wrote: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=43302 > > v2: Merge two matches together. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > include/unknwn.idl | 10 ++++++++++ > tools/widl/header.c | 2 +- > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/include/unknwn.idl b/include/unknwn.idl > index 78a2d9db18..7856a7f504 100644 > --- a/include/unknwn.idl > +++ b/include/unknwn.idl > @@ -46,6 +46,16 @@ interface IUnknown > ULONG Release(); > } > > +cpp_quote("HRESULT STDMETHODCALLTYPE IUnknown_QueryInterface_Proxy(IUnknown* This, REFIID riid, void **ppvObject);") > +cpp_quote("void __RPC_STUB IUnknown_QueryInterface_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > +cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_AddRef_Proxy(IUnknown* This);") > +cpp_quote("void __RPC_STUB IUnknown_AddRef_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > +cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_Release_Proxy(IUnknown* This);") > +cpp_quote("void __RPC_STUB IUnknown_Release_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > + > cpp_quote("#ifdef SAVE_WIDL_C_INLINE_WRAPPERS") > cpp_quote("#define WIDL_C_INLINE_WRAPPERS") > cpp_quote("#endif") > diff --git a/tools/widl/header.c b/tools/widl/header.c > index 7b971582db..e48b488ae3 100644 > --- a/tools/widl/header.c > +++ b/tools/widl/header.c > @@ -1172,7 +1172,7 @@ static void write_method_proto(FILE *header, const type_t *iface) > { > const var_t *func = stmt->u.var; > > - if (!is_local(func->attrs)) { > + if (is_callas(func->attrs)) { > const char *callconv = get_attrp(func->type->attrs, ATTR_CALLCONV); > if (!callconv) callconv = "STDMETHODCALLTYPE"; > /* proxy prototype */ On further testing with midl v7, /Os does emit Proxy/Stub prototypes for all functions. Since widl essentially runs in this mode, I'd prefer to keep this behaviour if possible. In the bug you mention redefinition errors in qmgrprxy. How are you getting these? Huw.

1 1

Wine appimage request
by Dpto Catastro Topografia MuniSantaCruz July 10, 2017

July 10, 2017

Hello, I have used this software and it has been very useful to me, I am a surveyor engineer and free software user. A year ago in the world linux have agreed to generate universal packages self-contained with everything they need to install on any linux distribution. Of which there are today 3; Simon Peter's appimage, Gnome flatpak and Canonical snaps. The advantage of these packages is that they use everything in the same package to work, libraries and so on. Hence they can be installed in any linux distribution. It would be great to see the WINE in appimage or in flatpak or snap, and avoid using the terminal for new users. I somehow defend myself with the terminal but sometimes it is still somewhat annoying and tedious. I leave you the links of these new packaging technologies, so that you can analyze them and may in the not too distant future offer some of these simple packages. In fact I prefer appimage, I downloaded several of these applications with this type of package and is simple to use and distribute. Flatpak and snap are still using the terminal to install them, the snaps are fairly simple (it will be installed in the gnome and kde software center in 2018), flatpak the gnome desktop and kde install it from the software center to install packages Flatpak. Appimage has its own charm and does not use the terminal, just make executable and run. Thank you Links Http://appimage.org/ Http://flatpak.org/ Https://snapcraft.io/ atte Luis V --

1 0

Re: [PATCH 5/5] d3drm: Assign animation key ids
by Henri Verbeet July 10, 2017

July 10, 2017

On 10 July 2017 at 12:40, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static BOOL d3drm_animation_get_next_key_id(struct d3drm_animation_keys *keys, DWORD *id) > +{ > + DWORD i; > + > + if (keys->next_unused <= keys->last_id) > + { > + *id = keys->next_unused++; > + return TRUE; > + } > + > + if (keys->next_free <= keys->last_id) > + { > + *id = keys->next_free; > + keys->next_free = ~0u; > + return TRUE; > + } > + > + if (keys->count == keys->last_id - keys->first_id + 1) > + return FALSE; > + > + /* Worst case, look for the spot from the beginning. */ > + for (i = 0, *id = keys->first_id; i < keys->count; i++, ++*id) > + { > + if (*id != keys->keys[i].id) > + break; > + } Does that work? The keys aren't necessarily ordered by ID, right? Regardless, it may be easier to make use of the fact that we never shrink the keys array.

1 0

Re: server: Don't allow APCs on objects associated with completion port.
by Marvin July 10, 2017

July 10, 2017

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=32203 Your paranoid android. === w7u (32 bit sock) === sock.c:6121: Test failed: Expected event sequence [FD_WRITE(0)], got [] sock.c:6142: Test failed: Expected event sequence [FD_READ(0) FD_CLOSE(0)], got [FD_WRITE(0) FD_CLOSE(10053)] sock.c:6145: Test failed: Failed to empty buffer: -1 - 10054 sock.c:6146: Test failed: Expected event sequence [FD_READ(0)], got [] sock.c:6149: Test failed: Failed to empty buffer: -1 - 10054

1 0

Re: [PATCH 2/2] msvcp140: Implement _File_size.
by Piotr Caban July 10, 2017

July 10, 2017

On 07/09/17 22:14, Stefan Dösinger wrote: > static int (__cdecl *p_To_wide)(const char *src, WCHAR *dst); > +static ULONGLONG(__cdecl *p_File_size)(WCHAR const*); Please add a space after ULONGLONG. > +static void test_File_size(void) > +{ > + ULONGLONG val; > + HANDLE file; > + LARGE_INTEGER file_size; > + WCHAR test_f1_W[] = {'t','r','2','_','t','e','s','t','_','d','i','r','/','f','1',0}; > + WCHAR test_f2_W[] = {'t','r','2','_','t','e','s','t','_','d','i','r','/','f','2',0}; > + WCHAR test_dir_W[] = {'t','r','2','_','t','e','s','t','_','d','i','r',0}; > + WCHAR test_ne_W[] = {'t','r','2','_','t','e','s','t','_','d','i','r','/','n','e',0}; > + CreateDirectoryW(test_dir_W, NULL); Could you please create the test files in temp directory? Also please rename the directory (these are no longer tr2 namespace tests). > +/* _File_size, msvcp140 version. Different error handling. */ > +ULONGLONG __cdecl _File_size(WCHAR const* path) > +{ > + WIN32_FILE_ATTRIBUTE_DATA fad; > + > + TRACE("(%s)\n", debugstr_w(path)); > + if(!GetFileAttributesExW(path, GetFileExInfoStandard, &fad)) > + return ~0ULL; > + if(fad.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) > + return 0; We don't need to handle the directory separately here. It will have file size set to 0 anyway. Thanks, Piotr

1 0

Re: advapi32/tests: Add tests for RegSetValueExW and RegQueryValueExW.
by Alexandre Julliard July 10, 2017

July 10, 2017

Jactry Zeng <jzeng(a)codeweavers.com> writes: > Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com> > --- > dlls/advapi32/tests/registry.c | 46 > +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 45 insertions(+), 1 deletion(-) I don't see how this is different from the existing tests. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: user.exe16: Fix an incorrect use of ADD_TO_T in FormatMessage16.
by Henri Verbeet July 10, 2017

July 10, 2017

On 9 July 2017 at 18:53, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > ADD_TO_T actually consists of two statements > > #define ADD_TO_T(c) \ > *t++=c;\ > if (t-target == talloced) {\ > target = HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,target,talloced*2);\ > t = target+talloced;\ > talloced*=2;\ > } > > so > > for (x=b; *x; x++) ADD_TO_T(*x); > > does _not_ actually do what one might expect/hope. > > Fixed thusly, in line with other usage. > Alternatively, it shouldn't be hard to either fix the macro or replace it with a function.

1 0

Re: [PATCH 2/2] include: Add Proxy stubs for IUnknown
by Huw Davies July 10, 2017

July 10, 2017

On Mon, Jul 10, 2017 at 04:43:49AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > include/unknwn.idl | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/include/unknwn.idl b/include/unknwn.idl > index 78a2d9d..7856a7f 100644 > --- a/include/unknwn.idl > +++ b/include/unknwn.idl > @@ -46,6 +46,16 @@ interface IUnknown > ULONG Release(); > } > > +cpp_quote("HRESULT STDMETHODCALLTYPE IUnknown_QueryInterface_Proxy(IUnknown* This, REFIID riid, void **ppvObject);") > +cpp_quote("void __RPC_STUB IUnknown_QueryInterface_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > +cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_AddRef_Proxy(IUnknown* This);") > +cpp_quote("void __RPC_STUB IUnknown_AddRef_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > +cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_Release_Proxy(IUnknown* This);") > +cpp_quote("void __RPC_STUB IUnknown_Release_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") What do you need these for? Huw.

1 0

Re: msvcp140: implement _To_byte
by Nikolay Sivov July 9, 2017

July 9, 2017

On 08.07.2017 22:33, Mikhail Paulyshka wrote: > Signed-off-by: Mikhail Paulyshka <me(a)mixaill.tk> > --- > dlls/msvcp140/msvcp140.spec | 2 +- > dlls/msvcp140/tests/msvcp140.c | 49 ++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcp90/locale.c | 10 +++++++++ > 3 files changed, 60 insertions(+), 1 deletion(-) > Hi, and thanks for the patch. Some comments in addition to Stefan's reply: > + static const WCHAR test_2[] = {0xfe95, 0xfea0, 0xfea6, 0}; //some arabic glyphs These are characters, not glyphs. Also please use C-style comments - /**/.

3 2

Re: notepad: Fix string length calculating.
by Nikolay Sivov July 9, 2017

July 9, 2017

Do we have RegSetValueExW tests to justify this?

3 2

Re: msvcp140: implement _To_byte
by Stefan Dösinger July 9, 2017

July 9, 2017

Hi, I was about to implement this function too, but it seems you've beaten me by two days :-) . Am 2017-07-08 um 17:55 schrieb Mikhail Paulyshka: > + WCHAR longstr[MAX_PATH + 3]; > + memset(longstr, 'A', sizeof(longstr)); This memset doesn't do what you probably expect. It doesn't fill the string with 'A's, but instead with U+4141 characters (䅁, http://www.fileformat.info/info/unicode/char/4141/index.htm) > + if (!src || !dst) > + return 0; This is redundant. WideCharToMultiByte checks this for you and returns 0. I noticed this after sending the _To_wide patch and will send a patch removing the redundant check from _To_wide.

2 3

Re: [PATCH] notepad: Use the default window position and size.
by Henri Verbeet July 8, 2017

July 8, 2017

On 8 July 2017 at 01:58, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > @@ -775,17 +774,9 @@ int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE prev, LPSTR cmdline, int show) > info.cbSize = sizeof(info); > GetMonitorInfoW( monitor, &info ); > > - x = main_rect.left; > - y = main_rect.top; > - if (main_rect.left >= info.rcWork.right || > - main_rect.top >= info.rcWork.bottom || > - main_rect.right < info.rcWork.left || > - main_rect.bottom < info.rcWork.top) > - x = y = CW_USEDEFAULT; > - > Globals.hMainWnd = > - CreateWindowW(className, winName, WS_OVERLAPPEDWINDOW, x, y, > - main_rect.right - main_rect.left, main_rect.bottom - main_rect.top, > + CreateWindowW(className, winName, WS_OVERLAPPEDWINDOW, > + CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, > NULL, NULL, Globals.hInstance, NULL); > if (!Globals.hMainWnd) > { Why would you want to do that? But if we're going to ignore it, we probably shouldn't bother saving and loading the window position to/from the registry either.

3 3

Compile MFC application
by MAX Trifonov July 8, 2017

July 8, 2017

Hello I try compile my application with winemaker ... winemaker --lower-uppercase --mfc -I/home/max/libffc-master/Include -I/home/max/wine/include DN After make I have got result: wineg++ -c -I/home/max/libffc-master/Include -I/home/max/wine/include -I. -o Big.o Big.cpp In file included from /home/max/wine/include/windows.h:70:0, from /home/max/libffc-master/Include/FFC/Globals.h:6, from /home/max/libffc-master/Include/afx.h:13, from /home/max/libffc-master/Include/afxwin.h:13, from StdAfx.h:16, from Big.cpp:2: /home/max/wine/include/winscard.h:22:20: fatal error: wtypes.h: Why wtypes.h not included ? -- MAX Trifonov

1 0

Re: [PATCH 1/2] explorer: Improve tray sizing and style.
by Dmitry Timoshkov July 8, 2017

July 8, 2017

Zebediah Figura <zfigura(a)codeweavers.com> wrote: > - SetWindowPos( win->button, 0, pos, 0, start_button_width, tray_height, > + SetWindowPos( win->button, 0, pos, 0, start_button_width, tray_height - 4, > SWP_NOZORDER | SWP_NOACTIVATE | SWP_SHOWWINDOW ); ... > - SetWindowPos( win->button, 0, pos, 0, width, tray_height, > + SetWindowPos( win->button, 0, pos, 0, width, tray_height - 4, > SWP_NOZORDER | SWP_NOACTIVATE | SWP_SHOWWINDOW ); ... > tray_width = GetSystemMetrics( SM_CXSCREEN ); > tray_height = max( icon_cy, size.cy ); > + tray_height = max( tray_height, 26 ); ... > start_button_width = size.cx; > - SetWindowPos( tray_window, HWND_TOPMOST, 0, GetSystemMetrics( SM_CYSCREEN ) - tray_height, > - tray_width, tray_height, SWP_NOACTIVATE | SWP_SHOWWINDOW ); > + SetWindowPos( tray_window, HWND_TOPMOST, -2, GetSystemMetrics(SM_CYSCREEN) - tray_height - 2, > + tray_width + 4, tray_height + 4, SWP_NOACTIVATE | SWP_SHOWWINDOW ); I guess that magic -4/-2 are caused by added WS_THICKFRAME style, if that's the case an appropriate system metric should be used instead to make the code work for different visual themes. 26 above also needs to be changed to an appropriate system metric. -- Dmitry.

1 0

Re: [PATCH 3/3] mfplat/tests: Add MFCreateAttributes test
by Marvin July 7, 2017

July 7, 2017

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=32169 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH] include: Support all version of BackgroundCopyManager from bits.h
by Alexandre Julliard July 7, 2017

July 7, 2017

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -22,12 +22,6 @@ > > #include "bits.idl" > > -#define DO_NO_IMPORTS > -#include "bits1_5.idl" > -#include "bits2_0.idl" > -#include "bits2_5.idl" > -#include "bits3_0.idl" This breaks the registration: ../../../tools/runtest -q -P wine -T ../../.. -M qmgr.dll -p qmgr_test.exe.so job && touch job.ok job.c:700: Test failed: Tests need BITS 2.0 or higher job.c:719: Test failed: Tests need BITS 2.5 or higher Makefile:285: recipe for target 'job.ok' failed make: *** [job.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ntdll: Handle IMAGE_REL_BASED_DIR64 for arm64 in the same way as for x86_64
by Jacek Caban July 7, 2017

July 7, 2017

Hi Martin, On 07.07.2017 12:39, Martin Storsjo wrote: > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 518a99f..3b784bf 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2476,7 +2476,7 @@ IMAGE_BASE_RELOCATION * WINAPI LdrProcessRelocationBlock( void *page, UINT count > case IMAGE_REL_BASED_HIGHLOW: > *(int *)((char *)page + offset) += delta; > break; > -#ifdef __x86_64__ > +#if defined(__x86_64__) || defined(__aarch64__) Could it use simply #ifdef _WIN64? Thanks, Jacek

1 0

Re: [1/2] vcomp: Add ARM64 support
by Alexandre Julliard July 7, 2017

July 7, 2017

Sebastian Lackner <sebastian(a)fds-team.de> writes: > On 05.07.2017 21:23, André Hentschel wrote: >> Signed-off-by: André Hentschel <nerv(a)dawncrow.de> >> --- >> dlls/vcomp/main.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 45 insertions(+) >> > > I have no ARM64 setup available, so please double-check that it actually > compiles before applying the patch. ;) It doesn't: aarch64-linux-android-clang -c -o main.o ../../../wine/dlls/vcomp/main.c -I. -I../../../wine/dlls/vcomp -I../../include \ -I../../../wine/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing \ -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits \ -Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf -g -O2 -fno-caret-diagnostics -Wno-tautological-constant-out-of-range-compare -Wno-enum-conversion -Wno-sometimes-uninitialized -Wno-ignored-attributes -Wno-array-bounds -Wno-absolute-value -Wno-unused-function -Wno-incompatible-pointer-types -Wno-invalid-source-encoding <inline asm>:36:2: error: too few operands for instruction Makefile:166: recipe for target 'main.o' failed make: *** [main.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] vcomp: Add ARM64 support
by Sebastian Lackner July 7, 2017

July 7, 2017

On 05.07.2017 21:23, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/vcomp/main.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > Just recently it was mentioned on the mailing lists that compilers do not support ms_va_list on ARM64 yet. Does your code rely on any compiler patches, or do you assume that va_list == ms_va_list?

2 2

Re: [PATCH 3/6] msi: Correctly format the template field for MsiProcessMessage().
by Hans Leidekker July 7, 2017

July 7, 2017

This one no longer applies after [PATCH v2 2/6] msi: Implement UI messages for dialogs: $ curl --silent -o - https://source.winehq.org/patches/data/135555 | git apply --verbose Checking patch dlls/msi/dialog.c... Checking patch dlls/msi/msi.rc... Checking patch dlls/msi/msipriv.h... Checking patch dlls/msi/package.c... Checking patch dlls/msi/resource.h... Checking patch dlls/msi/tests/package.c... error: while searching for: MsiCloseHandle(hpkg); ok_sequence(closehandle_sequence, "MsiCloseHandle()", TRUE); CoUninitialize(); DeleteFileA(msifile); DeleteFileA("forcecodepage.idt"); error: patch failed: dlls/msi/tests/package.c:9552 error: dlls/msi/tests/package.c: patch does not apply

1 0

Re: [PATCH 3/5] msi: Implement UI messages for dialogs.
by Alexandre Julliard July 6, 2017

July 6, 2017

Zebediah Figura <z.figura12(a)gmail.com> writes: > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/msi/action.c | 74 +++++++++++++-------------- > dlls/msi/custom.c | 2 +- > dlls/msi/dialog.c | 55 +++++++++++++++++++- > dlls/msi/msi.rc | 3 +- > dlls/msi/msipriv.h | 1 + > dlls/msi/package.c | 7 +++ > dlls/msi/resource.h | 1 + > dlls/msi/tests/package.c | 130 +++++++++++++++++++++++++++++++++++++++++++++-- > 8 files changed, 225 insertions(+), 48 deletions(-) This is causing the test to leave behind a winetest-package.msi file. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ws2_32/tests: A spelling fix in a comment.
by Marvin July 6, 2017

July 6, 2017

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=32127 Your paranoid android. === wvistau64 (64 bit sock) === sock.c:8273: Test failed: bytesReturned isn't supposed to be 1 sock.c:8297: Test failed: GetOverlappedResult failed, error 997

1 0

Re: [PATCH 2/2] regedit: Null-terminate REG_EXPAND_SZ and REG_MULTI_SZ data if the parsed hex data does not end in a null-te
by Marvin July 6, 2017

July 6, 2017

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

1 0

Re: [PATCH 1/2] regedit: Hex data lines may be terminated by a semicolon
by Marvin July 6, 2017

July 6, 2017

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

1 0

Re: [PATCH 4/5] msi: Don't increment the refcount when creating dialogs.
by Hans Leidekker July 6, 2017

July 6, 2017

On Wed, 2017-07-05 at 23:31 -0500, Zebediah Figura wrote: > We should only ever have one dialog anyway, and this is destroyed > when we close the package. It causes a crash in a random installer here: $ ./wine msiexec /i "XPSEP XP and Server 2003 32 bit.msi" fixme:ntdll:NtLockFile I/O completion on lock not implemented yet err:msi:msiobj_addref Invalid handle! err:msi:msiobj_addref Invalid handle! wine: Unhandled page fault on read access to 0x57e5896d at address 0x7ed68688 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x57e5896d in 32-bit code (0x7ed68688). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ed68688 ESP:0032d078 EBP:0032d088 EFLAGS:00210202( R- -- I - - - ) EAX:57e5896d EBX:7edaf2f4 ECX:00151018 EDX:7ed686d0 ESI:57e58949 EDI:00000045 Stack dump: 0x0032d078: 00150c40 7edaee74 00150c40 00150c40 0x0032d088: 0032d0e8 7ed6b4ae 7ed84b14 00000016 0x0032d098: 0032d0c8 7edaee40 4d430003 00000000 0x0032d0a8: 00000000 00000000 00000000 00000000 0x0032d0b8: 4d430000 0014947c 0000001c 7bc4fc76 0x0032d0c8: 0032d0f0 7edaf2f4 7edaee40 00150c40 Backtrace: =>0 0x7ed68688 find_cached_table+0x28(db=<is not available>, name="EventMapping") [/home/hans/wine/dlls/msi/../../include/wine/unicode.h:216] in msi (0x0032d088) 1 0x7ed6b4ae get_table+0x1d() in msi (0x0032d0e8) 2 0x7ed6c9e8 TABLE_CreateView+0xe7(db=0x7edaee40, name="EventMapping", view=0x14946c) [/home/hans/wine/dlls/msi/table.c:2179] in msi (0x0032d128) 3 0x7ed72857 WHERE_CreateView+0xe6(db=0x7edaee40, view=0x32d1e4, tables="EventMapping", cond=0x149400) [/home/hans/wine/dlls/msi/where.c:1242] in msi (0x0032d178) fixme:dbghelp_dwarf:compute_location Only supporting one reg (ebp/22 -> -2) 4 0x7ed75cd2 sql_parse+0xd71(info=0x32d9f4) [/home/hans/wine/dlls/msi/sql.y:506] in msi (0x0032d9d8) 5 0x7ed763af MSI_ParseSQL+0x4e(db=0x7edaee40, command="SELECT * FROM `EventMapping` WHERE `Dialog_` = 'ProgressForm' AND `Control_` = 'NextButton'", phview=0x154370, mem=0x15437c) [/home/hans/wine/dlls/msi/sql.y:1002] in msi (0x0032da18) 6 0x7ed49012 MSI_DatabaseOpenViewW+0x71() in msi (0x0032da58) 7 0x7ed4911f MSI_OpenQuery+0x8e(db=0x7edaee40, view=0x32dac4, fmt="SELECT * FROM `EventMapping` WHERE `Dialog_` = '%s' AND `Control_` = '%s'") [/home/hans/wine/dlls/msi/msiquery.c:163] in msi (0x0032da98) 8 0x7ed21ce2 dialog_map_events+0x31(dialog=<is not available>, control=<is not available>) [/home/hans/wine/dlls/msi/dialog.c:761] in msi (0x0032dad8) 9 0x7ed26a9e msi_dialog_add_control+0xad(dialog=0x15e0b8, rec=0x154218, szCls="BUTTON", style=0x18010000) [/home/hans/wine/dlls/msi/dialog.c:791] in msi (0x0032db18) 10 0x7ed28dfa msi_dialog_button_control+0xf9(dialog=0x15e0b8, rec=0x154218) [/home/hans/wine/dlls/msi/dialog.c:1011] in msi (0x0032db58) 11 0x7ed22070 msi_dialog_create_controls+0xaf(rec=0x154218, param=0x15e0b8) [/home/hans/wine/dlls/msi/dialog.c:3475] in msi (0x0032db88) 12 0x7ed49a2a MSI_IterateRecords+0x79(view=0x1f0e48, count=0x0(nil), func=0x7ed21fc0, param=0x15e0b8) [/home/hans/wine/dlls/msi/msiquery.c:188] in msi (0x0032dbd8) 13 0x7ed264f2 MSIDialog_WndProc+0xb71(hwnd=<couldn't compute location>, msg=<couldn't compute location>, wParam=<couldn't compute location>, lParam=<couldn't compute location>) [/home/hans/wine/dlls/msi/dialog.c:3502] in msi (0x0032dcd8) 14 0x7e9ee37a WINPROC_wrapper+0x19() in user32 (0x0032dd18) 15 0x7e9ee9ba call_window_proc+0x49(hwnd=0x2005a, msg=0x1, wp=0, lp=0x32e050, result=0x32dde8, arg=0x7ed25980) [/home/hans/wine/dlls/user32/winproc.c:245] in user32 (0x0032dd68) 16 0x7e9f0ce5 WINPROC_call_window+0xc4(hwnd=0x2005a, msg=0x1, wParam=0, lParam=0x32e050, result=0x32dde8, unicode=0x1, mapping=2124605252) [/home/hans/wine/dlls/user32/winproc.c:920] in user32 (0x0032ddb8) 17 0x7e9b4b14 call_window_proc+0x63(hwnd=0x2005a, msg=0x1, wparam=0, lparam=0x32e050, unicode=0x1, same_thread=0x1, mapping=2124605252) [/home/hans/wine/dlls/user32/message.c:2224] in user32 (0x0032de18) 18 0x7e9bbb0e send_message+0x1bd(info=0x32dea4, res_ptr=0x32dea0, unicode=0x1) [/home/hans/wine/dlls/user32/message.c:3269] in user32 (0x0032de88) 19 0x7e9bbd61 SendMessageW+0x50(hwnd=<couldn't compute location>, msg=<couldn't compute location>, wparam=<couldn't compute location>, lparam=<couldn't compute location>) [/home/hans/wine/dlls/user32/message.c:3469] in user32 (0x0032ded8) 20 0x7e9e54aa WIN_CreateWindowEx+0xba9(cs=0x32e050, className="MsiDialogCloseClass", module=(nil), unicode=0x1) [/home/hans/wine/dlls/user32/win.c:1641] in user32 (0x0032e038) 21 0x7e9df098 CreateWindowExW+0x72(exStyle=<couldn't compute location>, className=<couldn't compute location>, windowName=<couldn't compute location>, style=<couldn't compute location>, x=<couldn't compute location>, y=<couldn't compute location>, width=<couldn't compute location>, height=<couldn't compute location>, parent=<couldn't compute location>, menu=<couldn't compute location>, instance=<couldn't compute location>, data=<couldn't compute location>) [/home/hans/wine/dlls/user32/win.c:1776] in user32 (0x0032e088) 22 0x7ed231c6 dialog_run_message_loop+0x65() in msi (0x0032e0f8) 23 0x7ed2ad43 event_do_dialog+0x42(package=0x13f538, name=<is not available>, parent=(nil), destroy_modeless=0x1) [/home/hans/wine/dlls/msi/dialog.c:4349] in msi (0x0032e128) 24 0x7ed2c0e9 ACTION_DialogBox+0x48(package=0x13f538, dialog="ProgressForm") [/home/hans/wine/dlls/msi/dialog.c:4567] in msi (0x0032e168) 25 0x7ed4c8ca MSI_ProcessMessage+0x5d9(package=0x13f538, eMessageType=INSTALLMESSAGE_SHOWDIALOG, record=0x146d60) [/home/hans/wine/dlls/msi/package.c:1794] in msi (0x0032f288) 26 0x7ed2bfc7 ACTION_ShowDialog+0x76(package=0x13f538, dialog="ProgressForm") [/home/hans/wine/dlls/msi/dialog.c:4522] in msi (0x0032fac8) 27 0x7ecfad88 ACTION_HandleCustomAction.part+0x77() in msi (0x0032faf8) 28 0x7ed0ab3c ACTION_PerformUIAction+0xab() in msi (0x0032fb38) 29 0x7ed0acdc ITERATE_Actions+0x13b(row=0x152b60, param=0x13f538) [/home/hans/wine/dlls/msi/action.c:499] in msi (0x0032fb78) 30 0x7ed49a2a MSI_IterateRecords+0x79(view=0x146928, count=0x0(nil), func=0x7ed0aba0, param=0x13f538) [/home/hans/wine/dlls/msi/msiquery.c:188] in msi (0x0032fbc8) 31 0x7ed0b463 MSI_InstallPackage+0x4f2(package=0x13f538, szPackagePath="XPSEP XP and Server 2003 32 bit.msi", szCommandLine=0x0(nil)) [/home/hans/wine/dlls/msi/action.c:604] in msi (0x0032fc18) 32 0x7ed3dd51 MsiInstallProductW+0xc0(szPackagePath=<is not available>, szCommandLine=<is not available>) [/home/hans/wine/dlls/msi/msi.c:251] in msi (0x0032fc68) 33 0x7efefbee WinMain+0x73d(hInstance=<is not available>, hPrevInstance=<is not available>, lpCmdLine=<is not available>, nCmdShow=<is not available>) [/home/hans/wine/programs/msiexec/msiexec.c:994] in msiexec (0x0032fd48) 34 0x7efee904 main+0xc3(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/hans/wine/dlls/winecrt0/exe_main.c:49] in msiexec (0x0032fde8) 35 0x7eff12ff __wine_spec_exe_entry+0x6e(peb=<couldn't compute location>) [/home/hans/wine/dlls/winecrt0/exe_entry.c:36] in msiexec (0x0032fe38) 36 0x7b45ee6c call_process_entry+0xb() in kernel32 (0x0032fe58) 37 0x7b45fe09 start_process+0x68(entry=<couldn't compute location>) [/home/hans/wine/dlls/kernel32/process.c:1116] in kernel32 (0x0032fe98) 38 0x7bc7e5b0 call_thread_func_wrapper+0xb() in ntdll (0x0032feb8) 39 0x7bc813a1 call_thread_func+0xb0(entry=0x7b45fda0, arg=0x7eff1290, frame=0x32ffc8) [/home/hans/wine/dlls/ntdll/signal_i386.c:2759] in ntdll (0x0032ffa8) 40 0x7bc7e58e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 41 0x7bc53473 start_process+0x12(arg=0xffaf6bd8) [/home/hans/wine/dlls/ntdll/loader.c:3083] in ntdll (0x0032ffe8) 42 0xf757d81d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 43 0xf757d980 wine_switch_to_stack+0x1f(func=0x7bc53460, arg=0xffaf6bd8, stack=0x330000) [/home/hans/wine/libs/wine/port.c:77] in libwine.so.1 (0xffaf6ba8) 44 0x7bc5911a LdrInitializeThunk+0x239(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/hans/wine/dlls/ntdll/loader.c:3144] in ntdll (0xffaf6bf8) 45 0x7b465c33 __wine_kernel_init+0x962() [/home/hans/wine/dlls/kernel32/process.c:1310] in kernel32 (0xffaf7ae8) 46 0x7bc59ee3 __wine_process_init+0x152() [/home/hans/wine/dlls/ntdll/loader.c:3353] in ntdll (0xffaf7b58) 47 0xf757bbe3 wine_init+0x292(argc=0x4, argv=0xffaf8094, error="", error_size=0x400) [/home/hans/wine/libs/wine/loader.c:974] in libwine.so.1 (0xffaf7ba8) 48 0x7c000aaa main+0x79(argc=<is not available>, argv=<is not available>) [/home/hans/wine/loader/main.c:258] in <wine-loader> (0xffaf7fe8) 49 0xf739ea63 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x7ed68688 find_cached_table+0x28 [/home/hans/wine/dlls/msi/../../include/wine/unicode.h:216] in msi: cmpw 0x24(%esi),%di 216 while (*str1 && (*str1 == *str2)) { str1++; str2++; }

1 0

Re: [PATCH 2/5] msi: Add a basic internal UI implementation.
by Marvin July 5, 2017

July 5, 2017

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=32104 Your paranoid android. === w7u (32 bit msi) === The task timed out

1 0

Re: [2/2] vcomp/tests: Test more arguments with a callback
by Sebastian Lackner July 5, 2017

July 5, 2017

On 05.07.2017 21:23, André Hentschel wrote: > - p_vcomp_fork(TRUE, 5, fork_uintptr_cb, (UINT_PTR)1, (UINT_PTR)(MAXUINT_PTR - 2), > - (UINT_PTR)3, (UINT_PTR)(MAXUINT_PTR - 4), (UINT_PTR)5); > + p_vcomp_fork(TRUE, 12, fork_uintptr_cb, (UINT_PTR)1, (UINT_PTR)(MAXUINT_PTR - 2), > + (UINT_PTR)3, (UINT_PTR)(MAXUINT_PTR - 4), (UINT_PTR)5, > + (UINT_PTR)6, (UINT_PTR)7, (UINT_PTR)8, (UINT_PTR)9, > + (UINT_PTR)10, (UINT_PTR)11); Shouldn't the second argument be 11?

2 1

Re: [PATCH 3/3] d3dx9/tests: Add tests for array of samplers.
by Matteo Bruni July 5, 2017

July 5, 2017

2017-06-28 13:28 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: Sorry for the delayed reviews. I did it at last... > #define test_effect_preshader_compare_shader_bytecode(a, b, c, d) \ > @@ -4505,12 +4551,38 @@ static void test_effect_preshader(IDirect3DDevice9 *device) > hr = IDirect3DDevice9_GetSamplerState(device, 0, D3DSAMP_MAGFILTER, &value); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > todo_wine ok(value == 3, "Unexpected sampler 0 magfilter %u.\n", value); > + > + hr = IDirect3DDevice9_GetSamplerState(device, 1, D3DSAMP_MINFILTER, &value); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + ok(value == 1, "Unexpected sampler 1 minfilter %u.\n", value); > + hr = IDirect3DDevice9_GetSamplerState(device, 1, D3DSAMP_MAGFILTER, &value); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + todo_wine > + ok(value == 1, "Unexpected sampler 1 magfilter %u.\n", value); Not new or really related to this patch: any idea about what's going on with the magfilter state computation? I didn't really look into it, does it have to do with default parameter values by any chance?

2 7

Re: [PATCH] dmime: Rename IPersistStreamImpl_Load functions
by Michael Stefaniuc July 5, 2017

July 5, 2017

Hello Alistair, On 07/05/2017 08:17 AM, Alistair Leslie-Hughes wrote: > When a log had IPersistStreamImpl_Load entry from dmime, it's > quiet confusing to which of the _Load function was used. could you please change the "persist_stream" part of the new name to "IPersistStream"? That way it is consistent with the other method names. thanks bye michael > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dmime/lyricstrack.c | 4 ++-- > dlls/dmime/markertrack.c | 4 ++-- > dlls/dmime/paramcontroltrack.c | 4 ++-- > dlls/dmime/segment.c | 4 ++-- > dlls/dmime/segtriggertrack.c | 4 ++-- > dlls/dmime/seqtrack.c | 4 ++-- > dlls/dmime/sysextrack.c | 4 ++-- > dlls/dmime/tempotrack.c | 4 ++-- > dlls/dmime/timesigtrack.c | 4 ++-- > dlls/dmime/wavetrack.c | 4 ++-- > 10 files changed, 20 insertions(+), 20 deletions(-) > > diff --git a/dlls/dmime/lyricstrack.c b/dlls/dmime/lyricstrack.c > index 70382735d5..66293526dc 100644 > --- a/dlls/dmime/lyricstrack.c > +++ b/dlls/dmime/lyricstrack.c > @@ -240,7 +240,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI lyrics_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -252,7 +252,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + lyrics_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/markertrack.c b/dlls/dmime/markertrack.c > index 852948ab40..0fe72f9c91 100644 > --- a/dlls/dmime/markertrack.c > +++ b/dlls/dmime/markertrack.c > @@ -188,7 +188,7 @@ static const IDirectMusicTrackVtbl dmtrack_vtbl = { > IDirectMusicTrackImpl_Clone > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI marker_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -200,7 +200,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + marker_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/paramcontroltrack.c b/dlls/dmime/paramcontroltrack.c > index affea1da90..a7bc873c97 100644 > --- a/dlls/dmime/paramcontroltrack.c > +++ b/dlls/dmime/paramcontroltrack.c > @@ -240,7 +240,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI param_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -252,7 +252,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + param_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/segment.c b/dlls/dmime/segment.c > index ad8561fcae..be4a850556 100644 > --- a/dlls/dmime/segment.c > +++ b/dlls/dmime/segment.c > @@ -1171,7 +1171,7 @@ static inline IDirectMusicSegment8Impl *impl_from_IPersistStream(IPersistStream > return CONTAINING_RECORD(iface, IDirectMusicSegment8Impl, dmobj.IPersistStream_iface); > } > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *pStm) > +static HRESULT WINAPI seg_persist_stream_Load(IPersistStream *iface, IStream *pStm) > { > IDirectMusicSegment8Impl *This = impl_from_IPersistStream(iface); > HRESULT hr; > @@ -1248,7 +1248,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + seg_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/segtriggertrack.c b/dlls/dmime/segtriggertrack.c > index d1b208a6d0..17d5da2db5 100644 > --- a/dlls/dmime/segtriggertrack.c > +++ b/dlls/dmime/segtriggertrack.c > @@ -456,7 +456,7 @@ static inline IDirectMusicSegTriggerTrack *impl_from_IPersistStream(IPersistStre > return CONTAINING_RECORD(iface, IDirectMusicSegTriggerTrack, dmobj.IPersistStream_iface); > } > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *pStm) > +static HRESULT WINAPI trigger_persist_stream_Load(IPersistStream *iface, IStream *pStm) > { > IDirectMusicSegTriggerTrack *This = impl_from_IPersistStream(iface); > DMUS_PRIVATE_CHUNK Chunk; > @@ -505,7 +505,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + trigger_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/seqtrack.c b/dlls/dmime/seqtrack.c > index 2d80db75cd..7e74fa6036 100644 > --- a/dlls/dmime/seqtrack.c > +++ b/dlls/dmime/seqtrack.c > @@ -242,7 +242,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI track_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -254,7 +254,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + track_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/sysextrack.c b/dlls/dmime/sysextrack.c > index 431fca7227..ba7a8fdc7c 100644 > --- a/dlls/dmime/sysextrack.c > +++ b/dlls/dmime/sysextrack.c > @@ -242,7 +242,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI sys_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -254,7 +254,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + sys_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/tempotrack.c b/dlls/dmime/tempotrack.c > index 70de44228f..3c6f957571 100644 > --- a/dlls/dmime/tempotrack.c > +++ b/dlls/dmime/tempotrack.c > @@ -320,7 +320,7 @@ static inline IDirectMusicTempoTrack *impl_from_IPersistStream(IPersistStream *i > return CONTAINING_RECORD(iface, IDirectMusicTempoTrack, dmobj.IPersistStream_iface); > } > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *pStm) > +static HRESULT WINAPI tempo_persist_stream_Load(IPersistStream *iface, IStream *pStm) > { > IDirectMusicTempoTrack *This = impl_from_IPersistStream(iface); > DMUS_PRIVATE_CHUNK Chunk; > @@ -375,7 +375,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + tempo_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/timesigtrack.c b/dlls/dmime/timesigtrack.c > index 9bd7450264..72fdac8cbe 100644 > --- a/dlls/dmime/timesigtrack.c > +++ b/dlls/dmime/timesigtrack.c > @@ -189,7 +189,7 @@ static const IDirectMusicTrackVtbl dmtack_vtbl = { > IDirectMusicTrackImpl_Clone > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI time_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -201,7 +201,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + time_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/wavetrack.c b/dlls/dmime/wavetrack.c > index bc6e3ca413..20656a9362 100644 > --- a/dlls/dmime/wavetrack.c > +++ b/dlls/dmime/wavetrack.c > @@ -249,7 +249,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI wave_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -261,7 +261,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + wave_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; >

1 0

Re: [PATCH] mmdevapi/tests: Use standard wine_dbgstr_longlong.
by Marvin July 4, 2017

July 4, 2017

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=32062 Your paranoid android. === w7u (32 bit render) === render.c:1029: Test failed: Position 6592 too far after playing 100ms === w864 (32 bit render) === render.c:1255: Test failed: GetBuffer large (20671) at iteration 2

1 0

Re: [PATCH 2/5] msi: Add a basic internal UI implementation.
by Marvin July 4, 2017

July 4, 2017

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=32025 Your paranoid android. === w7u (32 bit msi) === The task timed out

3 3

Re: [1/5] libwine: Added a wine_mmap_is_in_reserved_area_ex function which returns boundary address.
by Alexandre Julliard July 4, 2017

July 4, 2017

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > include/wine/library.h | 1 + > libs/wine/mmap.c | 23 ++++++++++++++++++++++- > libs/wine/wine.map | 1 + > 3 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/include/wine/library.h b/include/wine/library.h > index 242bb69..0920c60 100644 > --- a/include/wine/library.h > +++ b/include/wine/library.h > @@ -79,6 +79,7 @@ extern void *wine_anon_mmap( void *start, size_t size, int prot, int flags ); > extern void wine_mmap_add_reserved_area( void *addr, size_t size ); > extern void wine_mmap_remove_reserved_area( void *addr, size_t size, int unmap ); > extern int wine_mmap_is_in_reserved_area( void *addr, size_t size ); > +extern int wine_mmap_is_in_reserved_area_ex( void *addr, size_t size, void **boundary ); > extern int wine_mmap_enum_reserved_areas( int (*enum_func)(void *base, size_t size, void *arg), > void *arg, int top_down ); > I'm afraid we don't want to add functions either. It should be possible to implement what you want without changing the libwine interface. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Definition (or not) of IDXGIResource methods
by Ben "Root" Anderson July 4, 2017

July 4, 2017

On Mon, Jul 3, 2017 at 1:52 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > I expect ultimately you'll need some way to get at the underlying > OpenGL object. One way to go about that may to for example extend the > IWineDXGIDevice interface in include/wine/winedxgi.idl with a method > to retrieve the underlying OpenGL object of a resource. Thanks for the tip. It'll likely make a good temporary hack until I put together the (sizable) proper solution. The added functions may even wind up being a part of said solution. > There are some details to take care of there though. For one, while > wined3d is implemented on top OpenGL, that's an implementation detail > and may not be true forever. A D3D surface/texture could be backed by > an OpenGL texture, an OpenGL renderbuffer, both, or something else > entirely, so you'll probably want some kind of interface to negotiate > the kind of representation you're requesting. Even if for simplicity > we assume we have a D3D texture backed by an OpenGL texture, that > doesn't guarantee that at any given time that OpenGL texture is > current/coherent. (See also, wined3d_texture_load_location(), > wined3d_texture_validate_location(), > wined3d_texture_invalidate_location(), etc.) So you may need a way to > flush/synchronise that OpenGL texture as well. And while > IWineDXGIDevice may be a good way to prove the concept, that's an > internal interface that doesn't make any guarantees about interface > stability, so for something that you'd want to use to interface with > external software, it would be best to create a separate interface > that does make those kinds of guarantees. Yeah, I definitely want to avoid interfaces that aren't agnostic to the underlying implementation, at which point it makes more sense to instead implement the relevant Windows APIs. My current plan is to make and submit a patch to wine-staging that implements VK_KHX_external_memory_win32 and the Direct3D/DXGI functionality needed to interact with that extension from Direct3D; this implementation would very probably lean on GL_EXT_memory_object and related extensions. Then, I'd use those interfaces to import the textures into a Vulkan instance, which is then passed to the compositor. > Finally, does this need to work with arbitrary resources, or do you > only need this for e.g. swapchain buffers? It needs to work not with swapchain buffers, but a pair of ID3D11Texture2D objects that are created by the application for the express purpose of being passed to the API I'm wrapping. One or both of these textures may or may not also be presented by the application in its own window through the usual D3D process, but I do not know and am not supposed to know whether they are, and shouldn't care. (Some apps actually render and present a completely separate scene in their window.) I need to ultimately pass the textures to the native Linux version of the compositor in a form it can digest (specifically, either a GL texture or render buffer name, or a VkImage and associated instance structs), which then (among other things) presents it in the HMD using its own (Vulkan) swapchains.

2 1

Re: [PATCH 3/4] d3drm: Initial support for storing animation keys
by Henri Verbeet July 4, 2017

July 4, 2017

On 4 July 2017 at 09:43, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static int d3drm_animation_cmp_min(const struct d3drm_animation_keys *keys, D3DVALUE left, D3DVALUE right, DWORD *cur) > +{ > + if (left == right) > + { > + while (*cur > 0 && left == keys->keys[*cur - 1].time) > + (*cur)--; > + return 0; > + } Does this really need to happen inside the comparison function? I.e., couldn't you just use a single comparison function, bsearch(), and do the fixup for duplicates afterwards? > +static DWORD d3drm_animation_get_index(struct d3drm_animation_keys *keys, D3DVALUE time, > + int (*compare_func)(const struct d3drm_animation_keys *keys, D3DVALUE left, D3DVALUE right, DWORD *cur)) > +{ > + int min = 0, max = keys->count - 1; unsigned/SIZE_T, right? > +static BOOL d3drm_animation_get_range(struct d3drm_animation_keys *keys, D3DVALUE time_min, D3DVALUE time_max, > + DWORD *min, DWORD *max) > +{ > + if (keys->count == 0) > + return FALSE; > + > + if (time_min > keys->keys[keys->count - 1].time || time_max < keys->keys[0].time) > + return FALSE; > + > + *min = d3drm_animation_get_index(keys, time_min, d3drm_animation_cmp_min); > + *max = d3drm_animation_get_index(keys, time_max, d3drm_animation_cmp_max); This is pretty minor, but note that to find *max you'd only have to search through *min to the end, instead of through the entire range. > + if (!key || key->dwSize != sizeof(*key)) > + return E_INVALIDARG; We usually print a WARN for cases where the application passes us questionable data. That's certainly not a strict requirement, but on occasion it does tend to make it slightly easier to figure out where things start failing. > + memmove(keys->keys + index + 1, keys->keys + index, sizeof(*keys->keys) * (keys->count - index)); We'd typically write those as "&keys->keys[index + 1]", etc. That's purely stylistic, of course. > + if (d3drm_animation_get_range(&animation->rotate, time_min, time_max, &min, &max)) > + { > + *count += max - min + 1; > + > + for (i = min; i <= max && keys; i++, cur++) > + { > + keys[cur].dwSize = sizeof(*keys); > + keys[cur].dwKeyType = D3DRMANIMATION_ROTATEKEY; > + keys[cur].dvTime = animation->rotate.keys[i].time; > + keys[cur].dwID = 0; /* FIXME */ > + keys[cur].u.dqRotateKey = animation->rotate.keys[i].u.rotate; > + } > + } Minor, but note that it would probably be more convenient if d3drm_animation_get_range() returned a pointer to animation->rotate.keys[min] and a count.

1 0

Re: [PATCH 5/5] msi: Correctly format the template field for MsiProcessMessage().
by Marvin July 3, 2017

July 3, 2017

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=32028 Your paranoid android. === wxppro (32 bit package) === 0a08:package: unhandled exception c0000005 at 00000738

1 0

Re: [PATCH 4/5] msi: Don't increment the refcount when creating dialogs.
by Marvin July 3, 2017

July 3, 2017

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=32027 Your paranoid android. === wxppro (32 bit package) === 09f0:package: unhandled exception c0000005 at 00000000

1 0

Re: [PATCH 3/5] msi: Implement UI messages for dialogs.
by Marvin July 3, 2017

July 3, 2017

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=32026 Your paranoid android. === wxppro (32 bit package) === 09f0:package: unhandled exception c0000005 at 00000000

1 0

wine-2.0.2-rc1 Available
by Michael Stefaniuc July 3, 2017

July 3, 2017

Hello guys, I have pushed wine-2.0.2-rc1 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ This version features 88 commits: - Some patches deferred from 2.0.1 - The compilation fixes for the prediluvian gcc 2.95 (but untested if those are enough) - Some simple "crash fix" commits that have no bugzilla entries - The usual assortment of bug fixes And now the interesting parts from the ANNOUNCE file: What's new in this release (see below for details): - Various bug fixes ---------------------------------------------------------------- Bugs fixed in 2.0.2 (total 61): 2624 In dialogs, an incorrect extra WM_ERASEBKGND is sent after WM_PAINT 10858 BlueByte Game Channel fails to install 14606 TreeView + right click doesn't work the way it does in native windows 20215 Extra mouse buttons do not work in Firefox 23302 Not standard background color in Wine configuration 25625 Implement PROPSHEET_InsertPage 30378 Xuzhou network client crashes at start 30764 regedit: a key created from right-click context menu is in incorrect position 33717 regedit: Sorting registry keys on refreshing 33987 Secret Files 3 demo shows only some parts of background in ConfigTool 35563 Custom game development library expects non-zero value for ProcessVmCounters info class member 'WorkingSetSize' 37404 A right click on a registry key does not select it 37976 Poedit 1.7.4 crashes on unimplemented function msvcr120.dll.??0_ReentrantBlockingLock(a)details@Concurrency@@QAE(a)XZ 39685 Multiple applications crash on startup, need unimplemented function msvcr120.dll.??0event(a)Concurrency@@QAE(a)XZ (Rollcage Redux v1.3.8, ARC client, Playstation Now) 39856 Regedit: Default registry key is not the same as on Windows 39895 MalwareBytes Anti-malware software needs msvcr100.dll.lldiv implementation 40629 Noto Nastaliq Urdu font crashes notepad during shaping 40798 ACDSee Pro 9 (64-bit) needs msvcr120.dll.??0event(a)Concurrency@@QEAA(a)XZ 40948 Multiple apps need api-ms-win-crt-locale-l1-1-0.dll.__initialize_lconv_for_unsigned_char 40956 unimplemented function msvcr110.dll._Lock_shared_ptr_spin_lock when starting Zoner Photo Studio 18 41408 Multiple applications crash on unimplemented function msvcp140.dll.??0task_continuation_context(a)Concurrency@@AAE(a)XZ 41472 kolotibablo needs ntoskrnl.exe.KeAcquireInStackQueuedSpinLock 41753 Steep (Ubisoft) needs iphlpapi.dll.GetUnicastIpAddressEntry 41928 Mortal Kombat X needs msvcr110.dll._get_dstbias 42017 Silence d3d11_immediate_context_OMSetBlendState spam at console 42129 Steam client - unimplemented function mfreadwrite.dll.MFCreateSourceReaderFromMediaSource 42138 bug when running reaktor 6: "Unhandled exception: unimplemented function concrt140.dll.??0_ReentrantBlockingLock(a)details@Concurrency@@QAE(a)XZ called in 32-bit code (0x7b43bf1c)." 42206 Gauntlet character screen background is corrupted. 42209 Native Instruments Native Access 1.0.25 (R37) crashes on unimplemented function concrt140.dll.??1_ReentrantBlockingLock(a)details@Concurrency@@QAE(a)XZ 42239 Kontact 5.6 needs api-ms-win-crt-time-l1-1-0.dll._Wcsftime 42240 Kontact 5.6 needs concrt140.dll.??0_ReentrantBlockingLock(a)details@Concurrency@@QEAA(a)XZ 42271 Final Fantasy X needs msvcr110.dll.__crtUnhandledException 42449 Multiple apps need function msvcr120.dll.fesetround (0 A.D., BeamNG.drive) 42463 ZmLearn crash at startup: "Assertion 'm->state == STATE_PASSIVE' failed at pulse/mainloop.c:787, function pa_mainloop_prepare(). Aborting." 42465 winhttp set_cookies() violates RFC6265 string comparison rules 42487 Free Devanagari font Samanata crashes during GPOS processing 42490 Assertion failure when clicking boxes in altWinDirStat 42510 InternetOpenUrl does not send query parameters for HTTPS urls 42559 Adobe Reader DC: No longer installs (Unimplemented function msi.dll.MsiGetComponentPathExW) 42575 Multiple applications need msvcp140.dll.?_LogScheduleTask(a)_TaskEventLogger@details(a)Concurrency@@QAEX_N(a)Z 42576 Poedit crashes on start on unimplemented function msvcp140.dll.?_Reset(a)_ContextCallback@details(a)Concurrency@@AAEXXZ 42578 WSAStringToAddress fails to parse IP v6 addresses with port number 42626 unimplemented function msvcr110.dll.__crtUnhandledException 42651 ViStart: fails to install, needs ntoskrnl.exe.IoReportResourceForDetection 42655 Aliens vs. Predator (2010) needs d3dx11_42.dll.D3DX11FilterTexture 42657 ACDSee Pro 9 needs msvcr120.dll.?Alloc(a)Concurrency@@YAPEAX_K(a)Z 42658 Playstation Now needs msvcr120.dll.?Alloc(a)Concurrency@@YAPAXI(a)Z 42688 Native Acces crashes on unimplemented msvcp140.dll.?__ExceptionPtrCompare@@YA_NPBX0(a)Z 42703 Excel 2010 does not work: unimplemented function oleaut32.dll.GetAltMonthNames 42736 scanf doesn't work as expected when using format string contains non-ascii chars 42774 WinHttpQueryAuthSchemes fails to return the correct supported value for multiple WWW-Authenticate 42798 MsiGetPatchInfoEx returns incorrect values for UNINSTALLABLE, PATCHSTATE properties 42834 Steuer-Spar-Erklärung 2017 crashes with critical error 42876 iTunes needs function msvcp140.dll._Lock_shared_ptr_spin_lock 42986 wine can't be compiled by gcc-2.95.4 (amstream/mediastream.c) 42991 wine can't be compiled by gcc-2.95.4 (dmusic/port.c) 42992 wine can't be compiled by gcc-2.95.4 (dwrite/opentype.c) 42993 wine can't be compiled by gcc-2.95.4 (gdiplus/metafile.c) 42994 wine can't be compiled by gcc-2.95.4 (mscoree/assembly.c) 42995 wine can't be compiled by gcc-2.95.4 (netprofm/list.c) 43127 Multiple 64-bit applications crash with stack overflow errors when Wine is compiled with GCC 7.x (set_context_reg in ntdll/signal_x86_64.c assumes Xmm registers are aligned) ---------------------------------------------------------------- Changes since 2.0.1: Alex Henrie (7): winecfg: Paint text on About tab with the right background color. ntdll: Implement ProcessVmCounters for Linux. user32: Translate WM_(NC)XBUTTONUP to WM_APPCOMMAND in DefWindowProc. comctl32: Return TRUE from LVM_REDRAWITEMS with bad indices. ddraw: Don't crash if writing out a new ddraw2 surface segfaults. ddraw: Don't crash if writing out a new ddraw4 surface segfaults. ddraw: Don't crash if writing out a new ddraw7 surface segfaults. Alistair Leslie-Hughes (3): winhttp/tests: Added multi Authenticate header test. include: Add mfreadwrite.idl. mfreadwrite: Add MFCreateSourceReaderFromMediaSource stub. Andrey Gusev (1): d3dx11: Add D3DX11FilterTexture stub. André Hentschel (4): include: Add the new version of the IP_ADAPTER_UNICAST_ADDRESS structure. iphlpapi: Add GetUnicastIpAddressEntry implementation. hidclass.sys: Fix compilation on systems that don't support nameless structs. winebus.sys: Fix compilation on systems that don't support nameless structs. Aric Stewart (1): usp10: Fix Contextual Shaping for Languages with RTL write order. Austin English (2): ntoskrnl.exe: Add KeAcquireInStackQueuedSpinLock stub. ntoskrnl.exe: Add IoReportResourceForDetection stub. Björn Bidar (1): wined3d: Add NVIDIA GTX 1080 Ti to the GPU list. Bruno Jesus (2): ws2_32/tests: Rework WSAStringToAddress tests. ws2_32: Fix WSAStringToAddress parsing for IPv6. Christopher Berner (1): wined3d: Add Nvidia TitanX (Pascal). Daniel Lehman (1): msvcrt: Add Concurrency::event stubs. Fabian Maurer (5): user32/tests: Add tests for windows when first shown with WS_VISIBLE or RedrawWindow. user32/tests: Add tests for windows when first shown with SetWindowPos. user32/tests: Add tests for windows when first shown if they have children. user32/tests: Add WM_NCPAINT tests for windows crossing screen or maximized. user32: Send WM_NCPAINT and WM_ERASEBKGND when window is shown. Gijs Vermeulen (1): msvcrt: Add stub for Concurrency::Alloc. Hans Leidekker (7): msi: Implement MsiGetComponentPathExA/W. winhttp: Parse cookie attributes. winhttp: Cookie attributes are case-insensitive. winhttp: Ignore unknown schemes in WinHttpQueryAuthSchemes. msi: Properly handle DWORD registry values in MsiGetPatchInfoEx. netprofm: Fix compilation on systems that don't support nameless unions. winhttp: Fix a memory leak in insert_header (Valgrind). Hugh McMaster (4): comctl32: Improve right-click handling in treeview controls. regedit: Call TrackPopupMenu() from WM_CONTEXTMENU. regedit: Select the targeted treeview item on right mouse click. regedit: Sort treeview children on refresh. Huw D. M. Davies (1): shell32: Avoid leaking icon handles. Jacek Caban (1): msvcrt: Added lldiv implementation. Jakub Bartmiński (1): regedit: Fall back to tree root on invalid path. Józef Kucia (11): d3d11: Try to avoid spurious blend state FIXMEs(). wined3d: Add ARB_texture_buffer_object extension. wined3d: Create dummy buffer textures. wined3d: Add initial support for shader buffer views. wined3d: Do not pass LOD to texelFetch() for buffer resources. wined3d: Implement buffer samplers. amstream: Fix compilation on systems that don't support nameless unions. dmusic: Fix compilation on systems that don't support nameless structs or unions. mscoree: Fix compilation on systems that don't support nameless unions. gdiplus: Fix compilation on systems that don't support nameless unions. dxgi: Fix HMODULE leak in register_d3d10core_layers(). Michael Müller (2): cabinet: Set index of folder in FDICopy callback. wininet: Handle query parameters for HTTPS urls in InternetOpenUrlW. Michael Stefaniuc (1): dmloader: Avoid a crash on a NULL string pointer. Nikolay Sivov (8): oleaut32: Implement GetAltMonthNames(). dwrite: Make CreateFontFaceFromHdc() properly fail on unsupported font format. regedit: Sort each of top level branches separately. usp10: Ignore device tables with invalid delta format. dwrite: Fix compilation failure regarding nameless unions. schedsvc: Fix xml buffer leak (Valgrind). dwrite: Fix file object leak. shell32: Fix string leak. Peter Hater (1): comctl32/propsheet: Added PSM_INSERTPAGE implementation. Piotr Caban (16): msvcp110: Add _Lock_shared_ptr_spin_lock implementation. msvcp140: Add task_continuation_context constructor implementation. msvcp140: Add _ContextCallback implementation. msvcp140: Add _TaskEventLogger class implementation. msvcr: Add _Wcsftime implementation. msvcr100: Add reader_writer_lock class stub. msvcr100: Add _ReentrantBlockingLock class implementation. msvcrt: Add __ExceptionPtrCopyException implementation. msvcrt: Add __ExceptionPtrCompare implementation. msvcr: Add __crtUnhandledException implementation. msvcr120: Add fesetround implementation. msvcrt: Fix handling of unsigned chars in scanf format. msvcrt: Fix wide characters handling in wscanf functions. msvcr: Add _get_dstbias implementation. ucrtbase: Add __initialize_lconv_for_unsigned_char implementation. msvcr110: Add _Lock_shared_ptr_spin_lock implementation. Sebastian Lackner (3): rasapi32: Set *lpcDevices in RasEnumDevicesA. ntdll: Do not cast unaligned pointer to M128A in set_context_reg. mmdevapi: Use InitOnce to initialize audio drivers. Thierry Vermeylen (1): wnaspi32: Do not crash on SC_GETSET_TIMEOUTS. Viktor Semykin (2): windowscodecs/tests: Test for png codec seeking too far. windowscodecs: Fixed loading png from streams. -- Michael Stefaniuc mstefani(a)winehq.org

1 0

Re: [PATCH 2/2] make_unicode: Update to Unicode to version 10 I added "Bottom_And_Left", but i have no idea, if my change is correct
by Aric Stewart July 3, 2017

July 3, 2017

Please do not change existing values. You can add new ones to the end. -aric On 7/2/17 5:23 PM, Detlef Riekenberg wrote: > -- > Bye bye ... Detlef > > Signed-off-by: Detlef Riekenberg <wine.dev(a)web.de> > --- > tools/make_unicode | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/tools/make_unicode b/tools/make_unicode > index f9c2917..5bbc5b8 100755 > --- a/tools/make_unicode > +++ b/tools/make_unicode > @@ -23,7 +23,7 @@ use strict; > > # base URLs for www.unicode.org files > my $MAPPINGS = "http://www.unicode.org/Public/MAPPINGS"; > -my $UNIDATA = "http://www.unicode.org/Public/9.0.0/ucd"; > +my $UNIDATA = "http://www.unicode.org/Public/10.0.0/ucd"; > my $REPORTS = "http://www.unicode.org/reports"; > my $RFCS = "http://www.rfc-editor.org/rfc"; > my $VERTICALPATH = "http://www.unicode.org/Public/vertical/revision-17"; > @@ -190,9 +190,10 @@ my %matra_types = > "Top_And_Left" => 0x09, > "Top_And_Left_And_Right" => 0x0a, > "Bottom_And_Right" => 0x0b, > - "Top_And_Bottom_And_Right" => 0x0c, > - "Overstruck" => 0x0d, > - "Invisible" => 0x0e > + "Bottom_And_Left" => 0x0c, > + "Top_And_Bottom_And_Right" => 0x0d, > + "Overstruck" => 0x0e, > + "Invisible" => 0x0f > ); > > my %nameprep_flags = >

1 0

Re: [4/7] ntdll: Allow map_view() to allocate fixed memory between reserved area and non-reserved area.
by Alexandre Julliard July 3, 2017

July 3, 2017

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -551,11 +551,12 @@ void wine_mmap_remove_reserved_area( void *addr, size_t size, int unmap ) > * Check if the specified range is included in a reserved area. > * Returns 1 if range is fully included, 0 if range is not included > * at all, and -1 if it is only partially included. > + * When returning -1, set the boundary address if the pointer is supplied. > * > * Note: the reserved areas functions are not reentrant, caller is > * responsible for proper locking. > */ > -int wine_mmap_is_in_reserved_area( void *addr, size_t size ) > +int wine_mmap_is_in_reserved_area( void *addr, size_t size, void **boundary ) libwine is supposed to be backwards compatible, you can't change its interface. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/4] msi: Add a basic internal UI implementation.
by Marvin July 3, 2017

July 3, 2017

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=31999 Your paranoid android. === w7u (32 bit msi) === The task timed out

3 2

Re: [PATCH] make_unicode: Update vertical spec to revision 17
by Alexandre Julliard July 3, 2017

July 3, 2017

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -26,7 +26,8 @@ my $MAPPINGS = "http://www.unicode.org/Public/MAPPINGS"; > my $UNIDATA = "http://www.unicode.org/Public/9.0.0/ucd"; > my $REPORTS = "http://www.unicode.org/reports"; > my $RFCS = "http://www.rfc-editor.org/rfc"; > -my $VERTICALDATA = "http://www.unicode.org/Public/vertical/revision-15"; > +my $VERTICALPATH = "http://www.unicode.org/Public/vertical/revision-17"; > +my $VERTICALFILE = "VerticalOrientation-17.txt"; This doesn't seem to make any difference in the generated file, should it? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 05/10 v4] gdiplus: Support SetTextRenderingHint in metafiles
by Nikolay Sivov July 3, 2017

July 3, 2017

On 06/30/2017 07:14 PM, Piotr Caban wrote: > +GpStatus METAFILE_AddSimpleProperty(GpMetafile *metafile, SHORT prop, SHORT val) > +{ > + EmfPlusRecordHeader *hint_record; > + GpStatus stat; > + > + if (metafile->metafile_type != MetafileTypeEmfPlusOnly && metafile->metafile_type != MetafileTypeEmfPlusDual) > + return Ok; > + > + stat = METAFILE_AllocateRecord(metafile, sizeof(*hint_record), (void**)&hint_record); > + if (stat != Ok) return stat; > + > + hint_record->Type = prop; > + hint_record->Flags = val; > + > + METAFILE_WriteRecords(metafile); > + return Ok; > +} This is not specific to text rendering hint parameter anymore, local variable should be just "record".

2 1

Re: [PATCH 03/10 v4] gdiplus: Add functions for managing metafile objects id
by Vincent Povirk July 3, 2017

July 3, 2017

This seems like overkill to me? I don't see the need for per-object refcounting. Every drawing operation that uses an object is just going to end with a series of releases, and after it returns all refcounts should be 0. + /* TODO: object id should be released on object dispose */ I don't think this approach is possible. It would require every object to be aware of which metafiles are using it, and every operation that modifies the object would have to release them. Bitmap objects can refer to an application buffer that could be modified without any call into gdiplus. (Or, Bitmaps could be modified by an ImageAttributes, in which case we can't reuse them except with an identical ImageAttributes.) If we wanted to reuse Bitmaps, we'd have to compare the data. For other large types like Paths, maybe keeping an id to detect whether it changed would make sense. For types of bounded size, it probably would be easier to store a complete copy.

2 2

Re: [PATCH] kernel32: Fix GetModuleHandleEx() spec file entry
by Chris Robinson July 2, 2017

July 2, 2017

On 07/02/2017 01:26 AM, Nikolay Sivov wrote: > -@ stdcall GetModuleHandleExA(long ptr ptr) > -@ stdcall GetModuleHandleExW(long ptr ptr) > +@ stdcall GetModuleHandleExA(long str ptr) > +@ stdcall GetModuleHandleExW(long wstr ptr) Depending on the flags, the second parameter might not actually be a string. e.g. if GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS is set, the second parameter is any address within the module's address space.

2 1