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