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