April 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: wrc: Allow quotes in resource nameID.
by Alexandre Julliard May 16, 2017

May 16, 2017

Artur Świgoń <artur.swigon(a)gmail.com> writes: > @@ -138,6 +142,14 @@ static int wbufalloc = 0; > > static int current_codepage = -1; /* use language default */ > > +/* Used for differentiating between single- and double-quoted nameID's */ > +static int id_dblquote = 0; > + > +/* Used for catching first (quoted) nameID before wanted_id is set. > + * This variable is reset to 0 once the first ID (quoted or not), string or > + * data has been encountered */ > +static int id_initial = 1; That's a bit hackish. Couldn't you simply set the initial state appropriately instead of introducing a separate variable? > @@ -402,8 +414,30 @@ static unsigned long xstrtoul(const char *nptr, char **endptr, int base) > 0[oO][0-7]+[lL]? { parser_lval.num = xstrtoul(yytext+2, 0, 8); > return (yytext[yyleng-1] == 'L' || yytext[yyleng-1] == 'l') ? tLNUMBER : tNUMBER; } > > +<tkid_dbl>[A-Za-z_0-9./\\\']+\" | > +<tkid_sgl>[A-Za-z_0-9./\\\"]+\' { There are more characters that should be allowed. Nested quotes are also supposed to work. -- Alexandre Julliard julliard(a)winehq.org

2 2

winetricks alldlls=builtin update based on wine-2.7
by wylda＠volny.cz May 16, 2017

May 16, 2017

______________________________________________________________ > Od: Austin English <austinenglish(a)gmail.com> > Komu: wylda(a)volny.cz > Datum: 20.02.2017 07:07 > Předmět: Re: winetricks alldlls=builtin update based on wine-2.2 > > CC: <wine-devel(a)winehq.org> On Sun, Feb 19, 2017 at 7:51 AM, <wylda(a)volny.cz> wrote: > Hi, > in case you find it useful... > > W. Hi Wylda, Please send a pull request to https://github.com/Winetricks/winetricks/ -- -Austin GPG: 14FB D7EA A041 937B ______________________________________________________________ Hi Austin, i updated alldlls=builtin function for wine-2.7 and also fixed few things: - generates properly indentioned library list - removed nonsensical library names like "./dlls" - script generates override list matching 1:1 to wine-2.7 available list Unfortunately i not able to create pull request in github even though i have created github account right now. It's still grey out and i don't know different way to upload a patch. Anyway is there a different way to get it in, so i don't need to maintain locally? (spent whole day on this and i have no plans to learn git "details" in near futures). Best regards, W.

2 1

[v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
by Ricardo Neri May 15, 2017

May 15, 2017

This is v6 of this series. The five previous submissions can be found here [1], here [2], here[3], here[4], and here[5]. This version addresses the comments received in v4 plus improvements of the handling of emulation in 64-bit builds. 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. 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? There is a caveat, however. Certain applications rely on some of these instructions to function. An example of this are applications that use WineHQ[6]. For instance, these applications rely on sidt returning a non- accessible memory location[8]. During the discussions, it was proposed that the fault could be relied to the user-space and perform the emulation in user-mode. However, this would break existing applications until, for instance, they update to a new WineHQ version. However, this approach would require UMIP to be disabled by default. The consensus in this forum is to always enable it. This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[8] does not support applications that use these instructions. It relies on WineHQ for this [9]. Furthermore, the applications for which the concern was raised run in protected mode [8]. 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. * STR and SLDT return 0 as the segment selector. This looks appropriate since we are providing a dummy value as the base address of the global descriptor table. * 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. === How is this series laid out? ++ 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, and not as part of this patchset, enabled UMIP support for 64-bit process with the intention 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]. [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 [7]. https://www.winehq.org/ [8]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html [9]. http://www.dosemu.org/ [9]. http://marc.info/?l=linux-kernel&m=147876798717927&w=2 [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 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 (21): x86/mpx: Use signed variables to compute effective addresses x86/mpx: Do not use SIB index if index points to R/ESP x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0 x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel x86/insn-eval: Add utility functions to get register offsets 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 function to get segment descriptor base address x86/insn-eval: Add functions to get default operand and address sizes x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero insn/eval: Incorporate segment base in address computation x86/insn: Support both signed 32-bit and 64-bit effective addresses 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/mm: Relocate page fault error codes to traps.h 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 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 | 23 + 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 | 298 +++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-eval.c | 832 ++++++++++++++++++++++++++ arch/x86/mm/fault.c | 88 ++- arch/x86/mm/mpx.c | 120 +--- tools/testing/selftests/x86/entry_from_vm86.c | 39 +- 16 files changed, 1301 insertions(+), 176 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

7 109

Re: [PATCH 2/9] winemac.drv: EnumDisplayDevices placeholder implementation
by Ken Thomases May 8, 2017

May 8, 2017

Hi, Thanks for taking this up again… On Apr 24, 2017, at 3:48 PM, Donat Enikeev <donat(a)enikeev.net> wrote: > > Based on Ken Thomases <ken(a)codeweavers.com> staging patches > > Signed-off-by: Donat Enikeev <donat(a)enikeev.net> > --- > dlls/winemac.drv/display.c | 51 +++++++++++++++++++++++++++++++++++++++ > dlls/winemac.drv/winemac.drv.spec | 1 + > 2 files changed, 52 insertions(+) This doesn't build: display.c:1007:13: error: use of undeclared identifier 'monitors' if (monitors[iDevNum].dwFlags & MONITORINFOF_PRIMARY) ^ display.c:1010:80: error: use of undeclared identifier 'monitors' memcpy(lpDisplayDevice->DeviceName, monitors[iDevNum].szDevice, sizeof(monitors[iDevNum].szDevice)); ^ display.c:1010:45: error: use of undeclared identifier 'monitors' memcpy(lpDisplayDevice->DeviceName, monitors[iDevNum].szDevice, sizeof(monitors[iDevNum].szDevice)); ^ Is this patch written on the assumption that some other staging patches have already been applied? Beyond that, can you explain the rationale of moving the implementation of EnumDisplayDevices to the drivers? My patches implemented it in user32 based on EnumDisplayMonitors() and GetMonitorInfoW(). It may be somewhat clunky, but has the advantage that it ensures all three functions return mutually consistent results. Since you appear to have dropped my patches which caused GetMonitorInfoW() to return unique names for the displays, they are no longer consistent. GetMonitorInfoW() always uses "\\.\DISPLAY1" for all monitors while this implementation of EnumDisplayDevices() attempts to use "\\.\DISPLAY2", etc., for secondary and subsequent monitors. For what it's worth, my original patches were rejected because Alexandre wanted the tracking and management of displays and display modes centralized in the explorer process[1]. I have my reservations about that approach, mind you. ;) [1] https://www.winehq.org/pipermail/wine-devel/2014-March/103680.html Issues with other patches in the series: Patch 1: \ No newline at end of file Patches 1 and 2 ought to come after 3. In the current order, they introduce dead code. -Ken

2 3

Wine native fps overlay
by CARLOS RODRIGUEZ May 3, 2017

May 3, 2017

Hi Could be possible add native fps overlay, maybe can usefull for many apps and without forget steam overlay give performance issues in certain apps (steam overlay dont work since wine 2.6) Thanks

3 2

pulse/alsa option in wine cfg audio tab
by CARLOS RODRIGUEZ May 3, 2017

May 3, 2017

Hi Seeking donat enikeev patch for add csmt option to graphics tab Could be possible add option for select which audio driver can be used aka alsa o pulse in winecfg audio tab ? Because various apps still needed alsa case tales of zestiria, alan wake and many others Thanks

2 1

Re: [PATCH] user32: Do not call SendMessage() to show a window that is already visible.
by Dmitry Timoshkov May 1, 2017

May 1, 2017

Kimmo Myllyvirta <kimmo.myllyvirta(a)gmail.com> wrote: > diff --git a/dlls/user32/winpos.c b/dlls/user32/winpos.c > index c2b35ec..64fdfe0 100644 > --- a/dlls/user32/winpos.c > +++ b/dlls/user32/winpos.c > @@ -1239,6 +1239,9 @@ BOOL WINAPI ShowWindow( HWND hwnd, INT cmd ) > if ((cmd == SW_HIDE) && !(GetWindowLongW( hwnd, GWL_STYLE ) & WS_VISIBLE)) > return FALSE; > > + if ((cmd == SW_SHOW) && (GetWindowLongW( hwnd, GWL_STYLE ) & WS_VISIBLE)) > + return TRUE; > + > return SendMessageW( hwnd, WM_WINE_SHOWWINDOW, cmd, 0 ); > } Please have a look at the show_window() implementation and try to cover all cases that trigger SWP_SHOWWINDOW flag passed to SetWindowPos() in order to actually show a window. In fact it's only SW_HIDE that leads to that, so perhaps just adding an 'else' to the SW_HIDE case is enough? -- Dmitry.

2 1

Wine native fps overlay
by CARLOS RODRIGUEZ May 1, 2017

May 1, 2017

Hi Yes +fps option works but not all time, many times wine gives priority to some errors messages than fps counter However native fps overlay will be better because overlay appears independent wine message errors Without forget will be better for new users but need to some option for enable in winecfg Thanks

2 1

Re: version: Fix error in win 9x mode when a file was not found in GetFileVersionInfoSize.
by Nikolay Sivov April 30, 2017

April 30, 2017

On 28.04.2017 18:03, Sebastian Lackner wrote: > From: Michael Müller <michael(a)fds-team.de> > > Signed-off-by: Michael Müller <michael(a)fds-team.de> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/version/version.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/dlls/version/version.c b/dlls/version/version.c > index ed060c82b6..3ab53026e8 100644 > --- a/dlls/version/version.c > +++ b/dlls/version/version.c > @@ -705,7 +705,12 @@ DWORD WINAPI GetFileVersionInfoSizeExW( DWORD flags, LPCWSTR filename, LPDWORD h > return (len * 2) + 4; > > default: > - SetLastError( lzfd == HFILE_ERROR ? ofs.nErrCode : ERROR_RESOURCE_DATA_NOT_FOUND ); > + if (lzfd == HFILE_ERROR) > + SetLastError(ofs.nErrCode); > + else if (GetVersion() & 0x80000000) > + SetLastError(ERROR_FILE_NOT_FOUND); > + else > + SetLastError(ERROR_RESOURCE_DATA_NOT_FOUND); > return 0; > } > } > What depends on this? Is this function actually exported on Win9x? If not this fixup should happen in actual affected export I think.

2 1

Re: [PATCH v2] taskmgr/endproc.c: Implement ProcessPage_OnEndProcessTree()
by Bruno Jesus April 30, 2017

April 30, 2017

Hi, just a variable type change and minor style suggestions, some you can accept or ignore. > ... > > +static BOOL process_list_append(process_list *list, DWORD id) > +{ > + INT *temp; > + if (list->count == list->size) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > - return; > + list->size *= 2; > + temp = HeapReAlloc(GetProcessHeap(), 0, list->pid, list->size * sizeof(*list->pid)); > + if(!temp) > + return FALSE; > + > + list->pid = temp; > } > + list->pid[list->count++] = id; > + return TRUE; > +} Please use an empty line to separate variable declaration from code. Change "INT *temp" to "DWORD *temp" so it matches the same type from list->pid. You can also reduce the scope of the temp variable. There are 4 uses of "if(", please change to "if (". > - if (!TerminateProcess(hProcess, 0)) > +static void free_process_list(process_list *list) > +{ > + HeapFree(GetProcessHeap(), 0, list->pid); > +} > + > +static void enum_process_children(HANDLE snapshot, process_list *list, DWORD pid) > +{ > + PROCESSENTRY32 entry; > + SIZE_T start, end, i; > + > + start = list->count; > + entry.dwSize = sizeof(entry); > + > + if(!Process32First(snapshot, &entry)) > + return; > + > + do > + { > + if(entry.th32ParentProcessID == pid) > + { > + if(!process_list_append(list, entry.th32ProcessID)) > + { > + free_process_list(list); > + return; > + } > + } > + } while (Process32Next(snapshot, &entry)); > + > + end = list->count; > + for (i = start; i < end; ++i) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + enum_process_children(snapshot, list, list->pid[i]); > } You can drop the { } since there is a single line now, but it is just a suggestion. Other style suggestion is to merge the end attribution inside the for like "for (i = start, end = list-> count; ...". > - > - CloseHandle(hProcess); > } > > void ProcessPage_OnEndProcessTree(void) > @@ -100,11 +171,14 @@ void ProcessPage_OnEndProcessTree(void) > DWORD dwProcessId; > HANDLE hProcess; > WCHAR wstrErrorText[256]; > + process_list list; > + SIZE_T i; > + HANDLE snapshot; > > load_message_strings(); > > Count = SendMessageW(hProcessPageListCtrl, LVM_GETITEMCOUNT, 0, 0); > - for (Index=0; Index<Count; Index++) > + for (Index = 0; Index < Count; Index++) > { > lvitem.mask = LVIF_STATE; > lvitem.stateMask = LVIS_SELECTED; > @@ -116,7 +190,6 @@ void ProcessPage_OnEndProcessTree(void) > if (lvitem.state & LVIS_SELECTED) > break; > } > - > Count = SendMessageW(hProcessPageListCtrl, LVM_GETSELECTEDCOUNT, 0, 0); Please don't remove the empty line to separate the code from the "for" block. > ... On Sat, Apr 29, 2017 at 7:08 PM, Akarsha Sehwag <akarsha15010(a)iiitd.ac.in> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=39640 > > Implemented ProcessPage_OnEndProcessTree(). It now kills all the child processes along with the specified process. > > Signed-off-by: Akarsha Sehwag <akarsha15010(a)iiitd.ac.in> > --- > programs/taskmgr/endproc.c | 125 +++++++++++++++++++++++++++++++++++++-------- > 1 file changed, 105 insertions(+), 20 deletions(-) > > diff --git a/programs/taskmgr/endproc.c b/programs/taskmgr/endproc.c > index 89c2d7b..60df0d7 100644 > --- a/programs/taskmgr/endproc.c > +++ b/programs/taskmgr/endproc.c > @@ -31,11 +31,18 @@ > #include "wine/unicode.h" > #include "taskmgr.h" > #include "perfdata.h" > +#include "tlhelp32.h" > > static WCHAR wszWarnMsg[511]; > static WCHAR wszWarnTitle[255]; > static WCHAR wszUnable2Terminate[255]; > > +typedef struct process_list { > + DWORD *pid; > + SIZE_T count; /* index to maintain the last entry of the array */ > + SIZE_T size; > +} process_list; > + > static void load_message_strings(void) > { > LoadStringW(hInst, IDS_TERMINATE_MESSAGE, wszWarnMsg, sizeof(wszWarnMsg)/sizeof(WCHAR)); > @@ -43,6 +50,22 @@ static void load_message_strings(void) > LoadStringW(hInst, IDS_WARNING_TITLE, wszWarnTitle, sizeof(wszWarnTitle)/sizeof(WCHAR)); > } > > +static void kill_process(HANDLE hProcess, WCHAR *wstrErrorText) > +{ > + if (!hProcess) > + { > + GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > + MessageBoxW(hMainWnd, wstrErrorText, wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + return; > + } > + > + if (!TerminateProcess(hProcess, 0)) > + { > + GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > + MessageBoxW(hMainWnd, wstrErrorText, wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + } > +} > + > void ProcessPage_OnEndProcess(void) > { > LVITEMW lvitem; > @@ -54,7 +77,7 @@ void ProcessPage_OnEndProcess(void) > load_message_strings(); > > Count = SendMessageW(hProcessPageListCtrl, LVM_GETITEMCOUNT, 0, 0); > - for (Index=0; Index<Count; Index++) > + for (Index=0; Index < Count; Index++) > { > lvitem.mask = LVIF_STATE; > lvitem.stateMask = LVIS_SELECTED; > @@ -77,20 +100,68 @@ void ProcessPage_OnEndProcess(void) > > hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, dwProcessId); > > - if (!hProcess) > + kill_process(hProcess, wstrErrorText); > + CloseHandle(hProcess); > +} > + > +static BOOL init_process_list(process_list *list) > +{ > + list->size = 4; /* initialise size with 4. Will increase if necessary */ > + list->pid = HeapAlloc(GetProcessHeap(), 0, list->size * sizeof(*list->pid)); > + list->count = 0; > + > + return list->pid != NULL; > +} > + > +static BOOL process_list_append(process_list *list, DWORD id) > +{ > + INT *temp; > + if (list->count == list->size) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > - return; > + list->size *= 2; > + temp = HeapReAlloc(GetProcessHeap(), 0, list->pid, list->size * sizeof(*list->pid)); > + if(!temp) > + return FALSE; > + > + list->pid = temp; > } > + list->pid[list->count++] = id; > + return TRUE; > +} > > - if (!TerminateProcess(hProcess, 0)) > +static void free_process_list(process_list *list) > +{ > + HeapFree(GetProcessHeap(), 0, list->pid); > +} > + > +static void enum_process_children(HANDLE snapshot, process_list *list, DWORD pid) > +{ > + PROCESSENTRY32 entry; > + SIZE_T start, end, i; > + > + start = list->count; > + entry.dwSize = sizeof(entry); > + > + if(!Process32First(snapshot, &entry)) > + return; > + > + do > + { > + if(entry.th32ParentProcessID == pid) > + { > + if(!process_list_append(list, entry.th32ProcessID)) > + { > + free_process_list(list); > + return; > + } > + } > + } while (Process32Next(snapshot, &entry)); > + > + end = list->count; > + for (i = start; i < end; ++i) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + enum_process_children(snapshot, list, list->pid[i]); > } > - > - CloseHandle(hProcess); > } > > void ProcessPage_OnEndProcessTree(void) > @@ -100,11 +171,14 @@ void ProcessPage_OnEndProcessTree(void) > DWORD dwProcessId; > HANDLE hProcess; > WCHAR wstrErrorText[256]; > + process_list list; > + SIZE_T i; > + HANDLE snapshot; > > load_message_strings(); > > Count = SendMessageW(hProcessPageListCtrl, LVM_GETITEMCOUNT, 0, 0); > - for (Index=0; Index<Count; Index++) > + for (Index = 0; Index < Count; Index++) > { > lvitem.mask = LVIF_STATE; > lvitem.stateMask = LVIS_SELECTED; > @@ -116,7 +190,6 @@ void ProcessPage_OnEndProcessTree(void) > if (lvitem.state & LVIS_SELECTED) > break; > } > - > Count = SendMessageW(hProcessPageListCtrl, LVM_GETSELECTEDCOUNT, 0, 0); > dwProcessId = PerfDataGetProcessId(Index); > if ((Count != 1) || (dwProcessId == 0)) > @@ -125,20 +198,32 @@ void ProcessPage_OnEndProcessTree(void) > if (MessageBoxW(hMainWnd, wszWarnMsg, wszWarnTitle, MB_YESNO|MB_ICONWARNING) != IDYES) > return; > > - hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, dwProcessId); > + if (!init_process_list(&list)) > + return; > > - if (!hProcess) > + if (!process_list_append(&list, dwProcessId)) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + free_process_list(&list); > return; > } > > - if (!TerminateProcess(hProcess, 0)) > + snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); > + > + if (snapshot == INVALID_HANDLE_VALUE) > { > - GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); > - MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); > + free_process_list(&list); > + return; > } > + enum_process_children(snapshot, &list, dwProcessId); > + > + CloseHandle(snapshot); > > - CloseHandle(hProcess); > + for (i = 0; i < list.count; ++i) > + { > + hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, list.pid[i]); > + > + kill_process(hProcess, wstrErrorText); > + CloseHandle(hProcess); > + } > + free_process_list(&list); > } > -- > 2.9.3 > > >

1 0

Re: [v2 PATCH 1/4] mfplat: Implement MFTRegister
by Nikolay Sivov April 30, 2017

April 30, 2017

On 30.04.2017 6:29, Alistair Leslie-Hughes wrote: > + for (i = 0; i < cinput; i++) > + { > + memcpy(&types[2 * i], &input_types[i].guidMajorType, sizeof(GUID)); > + memcpy(&types[2 * i + 1], &input_types[i].guidSubtype, sizeof(GUID)); > + } This probably could be simplified even more, you can use MFT_REGISTER_TYPE_INFO for 'types' (that would make it 'type' actually), and do types[i] = input_types[i];, or even copy whole input_types array at once. Same applies to MFTEnum().

1 0

Re: [v2 PATCH 3/4] mfplat: Implement MFTEnum.
by Nikolay Sivov April 30, 2017

April 30, 2017

On 30.04.2017 6:29, Alistair Leslie-Hughes wrote: > + for (i = 0; i < size / sizeof(GUID); i += 2) > + { > + if (!IsEqualGUID(&guids[i], &type->guidMajorType) && > + !IsEqualGUID(&guids[i+1], &type->guidSubtype)) > + { > + ret = TRUE; > + break; > + } > + } This is confusing. Shouldn't it look for a match?

1 0

Re: [PATCH] user32: Do not call SendMessage() to show a window that is already visible.
by Marvin April 29, 2017

April 29, 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=30597 Your paranoid android. === w7pro64 (32 bit msg) === msg.c:5274: Test failed: RedrawWindow:show_popup_extreme_location: 12: the msg 0x001c was expected, but got msg 0x0085 instead

2 1

Re: [PATCH] glu32: avoid assert side effect (Coverity)
by Nikolay Sivov April 29, 2017

April 29, 2017

On 29.04.2017 20:34, Marcus Meissner wrote: > CID 401313 > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/glu32/sweep.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/glu32/sweep.c b/dlls/glu32/sweep.c > index a909e2be33..1248e9f050 100644 > --- a/dlls/glu32/sweep.c > +++ b/dlls/glu32/sweep.c > @@ -1287,7 +1287,8 @@ static void DoneEdgeDict( GLUtesselator *tess ) > */ > if( ! reg->sentinel ) { > assert( reg->fixUpperEdge ); > - assert( ++fixedEdges == 1 ); > + ++fixedEdges; > + assert( fixedEdges == 1 ); > } > assert( reg->windingNumber == 0 ); > DeleteRegion( tess, reg ); > This particular one has no side effects. I don't know what's the plan for glu, maybe it's a better idea to report/fix anything the comes up in mesa, and then import again.

2 1

Re: [4/6] secur32: Return PRF algorithm value when using GCM. (resend)
by Michael Müller April 29, 2017

April 29, 2017

This patch broke the compilation on Debian Wheezy and Ubuntu Trusty: schannel_gnutls.c: In function schannel_get_mac_algid: schannel_gnutls.c:329:10: error: ‘GNUTLS_MAC_AEAD undeclared (first use in this function) schannel_gnutls.c:329:10: note: each undeclared identifier is reported only once for each function it appears in Build overview: https://dev.wine-staging.com/builder/group/60/ (Click Downloads for build logs) Debian Wheezy build log: https://builds.wine-staging.com/2017-04-27-21-23-02-job-10597/build.log Regards, Michael

5 5

Re: [PATCH 4/4] dmloader/tests: Add some IDirectMusicLoader directory tests.
by Sebastian Lackner April 28, 2017

April 28, 2017

On 27.04.2017 19:15, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)winehq.org> > --- > dlls/dmloader/tests/loader.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > Your patch introduced a bunch of test failures here: loader.c:69: Test succeeded inside todo block: SetSearchDirectory failed with 0 loader.c:71: Test failed: Second SetSearchDirectory failed with 0 loader.c:73: Test failed: SetSearchDirectory failed with 0x1

2 1

Re: Review | endproc.c: Implement ProcessPage_OnEndProcessTree
by Aaryaman Vasishta April 28, 2017

April 28, 2017

Forgot to CC wine-devel.. On Fri, Apr 21, 2017 at 12:47 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > Hi, > > On Thu, Apr 20, 2017 at 6:51 AM, Akarsha Sehwag <akarsha15010(a)iiitd.ac.in> > wrote: > >> Hi >> Could someone take out a little time to review the code once? >> Bug I intend to solve: https://bugs.winehq.org/show_bug.cgi?id=39640 >> >> I am new to wine. So, I would appreciate suggestions regarding my coding >> style if that's not-so-perfect according to wine standards. Or any other >> problems with the code I have written. I apologize for submitting an >> untested code earlier. I hope now it works fine. >> > No worries! your efforts in contributing is always appreciated :) > > > /*-------------------------------------------CODE----------- >> ---------------------------------------*/ >> > Try using diffs/patches instead of manually copying them in this format. > Diffs are easier to apply and test with using git. That's how Stefan was > able to detect compilation errors in the patches you sent over on > wine-patches. I suggest sending another email with the changes in a diif > format if possible. > >> *//DOUBT: *Would sizeof(list->pid) be better or sizeof(int)? >> //Since in the former case, since list->pid is actually a pointer to >> DWORD, so //sizeof(list->pid) would return 8 bytes and not 4 bytes. >> >> } >> > Probably sizeof(DWORD) would be fine as well. In general, try following > what the surrounding, previously committed code is doing. > FWIW, pointers don't necessarily have to be 8 bytes in size. The size of a > pointer depends on whether your application is compiled as 32 or 64 bit. > It's possible to e.g. compile a program as 32 bit on a 64 bit machine. > For wine in 64 bit: https://wiki.winehq.org/FAQ#Is_there_a_64_bit_Wine.3F > > Cheers, > Aaryaman >

4 5

Re: [PATCH 4/4] mfplat/tests: Add tests.
by Andrew Eikum April 28, 2017

April 28, 2017

On Fri, Apr 28, 2017 at 04:29:07AM +0000, Alistair Leslie-Hughes wrote: > +static void test_register(void) > +{ > + static WCHAR name[] = {'W','i','n','e',' ','t','e','s','t',0}; > + MFT_REGISTER_TYPE_INFO input; > + MFT_REGISTER_TYPE_INFO output; > + CLSID *clsids; > + UINT32 count; > + HRESULT ret; > + > + memcpy(&input.guidMajorType, &DUMMY_GUID1, sizeof(GUID)); > + memcpy(&input.guidMajorType, &DUMMY_GUID2, sizeof(GUID)); > + memcpy(&output.guidSubtype, &DUMMY_GUID1, sizeof(GUID)); > + memcpy(&output.guidSubtype, &DUMMY_GUID3, sizeof(GUID)); > + Looks like some copy-paste errors here. Andrew

1 0

Re: ntdll: Use environment variable "WINESERVER" first on search for wineserver to start.
by Ralf Habacker April 28, 2017

April 28, 2017

Am 07.03.2017 um 15:20 schrieb Sebastian Lackner: > Was it intentional that you did not CC the wine-devel mailing list? no, I Just replyed to all; fixed that > > On 07.03.2017 10:22, Ralf Habacker wrote: >> In the opposite having wineserver environment variable set in users >> environment will make it sure to always starts wineserver with the >> requested settings. > Well, you could also change $PATH globally to let "wine" point to your > special wrapper executable. This would not really be different from using > a global WINESERVER variable. Really ? Adding an additional path looks more invasive in terms of security and maintenance as using a dedicated environment variable affecting only one executable. > > I think there is a misunderstanding here, each wineprefix uses its own > wineserver instance. Wineservers started for other prefixes will never > inherit any timeout settings. Thanks for this pointer, I wasn't aware of that. >> [...] >> >> With the mentioned patch applied to a local wine build (or with a >> renamed wineserver) the site now runs about two weeks and one noticable >> change is that the initial >> mentioned communication issue did not happens. This let me think that >> there may be a long time running issue with wineserver, which affects >> the dde interface. > It is nice that you have found a workaround, however we would also like > to fix such issues of course. If you find any way to trigger this issue, > please file a bug report. I will do but unfortunally I'm not at this point yet. Observations from the last weeks shows that the error happened two times: 1. wineserver is running 12 days and not restarted because one application showed a message box, therefore did not quit and blocked wineserver restart, which let other wine applications dde communication fail 20170309-061102.523831920: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> last wineserver restart 20170321-150057.967117185: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> manual restarted because of application freeze 2. wineserver is running 3 days and applications dde communications fails because wineserver has been restarted immediatly 20170322-061003.064358739: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> last restart .... 20170325-220751 -> print job starts 20170325-220753.202518273: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> wineserver has been restarted by timeout 20170325-220805 applications dde communication fails and wine reports wine: chdir to /tmp/.wine-37002/server-fd0a-9602cwine: : No such file or directory chdir to /tmp/.wine-37002/server-fd0a-9602c : No such file or directoryThis is expected and not a bug. It can happen when multiple wine > instances try to start up wineserver at the same time. Only the first > wineserver instance will be able to acquire the lock, all others will > exit and then connect to the existing wineserver. Sound reasonable Best regards Ralf

1 1

Re: [1/5] wsdapi: Implement WSD LinkedMemory functions [try 2]
by Alexandre Julliard April 28, 2017

April 28, 2017

Owen Rudge <orudge(a)codeweavers.com> writes: > +struct memory_allocation > +{ > + struct list entry; > + void *ptr; > + > + struct list children; > +}; > + > +static struct list memory_allocations = LIST_INIT(memory_allocations); > + > +static struct memory_allocation *find_allocation(struct list *searchList, void *parent) > +{ > + struct memory_allocation *allocation, *childAllocation; > + > + LIST_FOR_EACH_ENTRY(allocation, searchList, struct memory_allocation, entry) > + { > + if (allocation->ptr == parent) > + { > + return allocation; > + } > + > + /* Search the children */ > + childAllocation = find_allocation(&allocation->children, parent); > + > + if (childAllocation != NULL) > + { > + return childAllocation; > + } > + } > + > + return NULL; > +} You should probably store the child list at the start of the allocated block or something like that, you don't want to go through the entire list on every operation. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/4] mfplat/tests: Add tests.
by Nikolay Sivov April 28, 2017

April 28, 2017

On 28.04.2017 7:29, Alistair Leslie-Hughes wrote: > +BOOL init_function_ptrs(void) > +{ > + HMODULE mfplat = LoadLibraryA("mfplat.dll"); > + if (!mfplat) > + { > + win_skip("Could not load mfplat.dll\n"); > + return FALSE; > + } > + > + #define LOAD_FUNCPTR(f) p##f = (void*)GetProcAddress(mfplat, #f) > + LOAD_FUNCPTR(MFTEnum); > + LOAD_FUNCPTR(MFTRegister); > + LOAD_FUNCPTR(MFTUnregister); > + #undef LOAD_FUNCPTR > + > + return TRUE; > +} This looks redundant, why is it not statically linked?

1 0

Re: [PATCH 3/4] mfplat: Implement MFTEnum.
by Nikolay Sivov April 28, 2017

April 28, 2017

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > + for (i = 0; i < size / sizeof(GUID); i += 2) > + { > + if (!memcmp(&guids[i], &type->guidMajorType, sizeof(GUID)) && > + !memcmp(&guids[i+1], &type->guidSubtype, sizeof(GUID))) > + { > + ret = TRUE; > + break; > + } > + } IsEqualGUID could be used instead. > +HRESULT WINAPI MFTEnum(GUID category, UINT32 flags, MFT_REGISTER_TYPE_INFO *input_type, > + MFT_REGISTER_TYPE_INFO *output_type, IMFAttributes *attributes, > + CLSID **pclsids, UINT32 *pcount) I think it's better to print a fixme for non-zero flags and attributes, and use TRACE otherwise. > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, categories_keyW, &hcategory)) > + return E_FAIL; > + > + GUIDToString(buffer, &category); > + > + ret = RegOpenKeyW(hcategory, buffer, &hlist); > + RegCloseKey(hcategory); > + if (ret) return E_FAIL; This probably could be replaced with a single RegOpenKeyW(). > + PVOID tmp; Why void*?

1 0

Re: [PATCH 2/4] mfplat: Implement MFTUnregister.
by Nikolay Sivov April 28, 2017

April 28, 2017

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > + FIXME("(%s)\n", debugstr_guid(&clsid)); Same, why fixme?

1 0

Re: [PATCH 1/4] mfplat: Implement MFTRegister
by Nikolay Sivov April 28, 2017

April 28, 2017

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > From: Michael Müller <michael(a)fds-team.de> > > Changes > - Added pointer check output_types, input_types > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/mfplat/Makefile.in | 1 + > dlls/mfplat/main.c | 144 ++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/mfplat/mfplat.spec | 2 +- > loader/wine.inf.in | 4 ++ > 4 files changed, 150 insertions(+), 1 deletion(-) > > diff --git a/dlls/mfplat/Makefile.in b/dlls/mfplat/Makefile.in > index 2b5bd24..9679f53 100644 > --- a/dlls/mfplat/Makefile.in > +++ b/dlls/mfplat/Makefile.in > @@ -1,4 +1,5 @@ > MODULE = mfplat.dll > +IMPORTS = user32 advapi32 > > C_SRCS = \ > main.c > diff --git a/dlls/mfplat/main.c b/dlls/mfplat/main.c > index aae81f8..424c7f4 100644 > --- a/dlls/mfplat/main.c > +++ b/dlls/mfplat/main.c > @@ -23,15 +23,44 @@ > > #include "windef.h" > #include "winbase.h" > +#include "winuser.h" > +#include "winreg.h" > > #include "initguid.h" > #include "mfapi.h" > #include "mferror.h" > > #include "wine/debug.h" > +#include "wine/unicode.h" > > WINE_DEFAULT_DEBUG_CHANNEL(mfplat); > > +static WCHAR transform_keyW[] = {'S','o','f','t','w','a','r','e','\\','C','l','a','s','s','e','s', > + '\\','M','e','d','i','a','F','o','u','n','d','a','t','i','o','n','\\', > + 'T','r','a','n','s','f','o','r','m','s',0}; > +static WCHAR categories_keyW[] = {'S','o','f','t','w','a','r','e','\\','C','l','a','s','s','e','s', > + '\\','M','e','d','i','a','F','o','u','n','d','a','t','i','o','n','\\', > + 'T','r','a','n','s','f','o','r','m','s','\\', > + 'C','a','t','e','g','o','r','i','e','s',0}; > +static WCHAR inputtypesW[] = {'I','n','p','u','t','T','y','p','e','s',0}; > +static WCHAR outputtypesW[] = {'O','u','t','p','u','t','T','y','p','e','s',0}; Shouldn't those be constants too? > +static const WCHAR szGUIDFmt[] = > +{ > + '%','0','8','x','-','%','0','4','x','-','%','0','4','x','-','%','0', > + '2','x','%','0','2','x','-','%','0','2','x','%','0','2','x','%','0','2', > + 'x','%','0','2','x','%','0','2','x','%','0','2','x',0 > +}; > + > +static LPWSTR GUIDToString(LPWSTR lpwstr, REFGUID lpcguid) > +{ > + wsprintfW(lpwstr, szGUIDFmt, lpcguid->Data1, lpcguid->Data2, > + lpcguid->Data3, lpcguid->Data4[0], lpcguid->Data4[1], > + lpcguid->Data4[2], lpcguid->Data4[3], lpcguid->Data4[4], > + lpcguid->Data4[5], lpcguid->Data4[6], lpcguid->Data4[7]); > + > + return lpwstr; > +} It's easier to use sprintfW() here. Please for consistency remove the rest of LP* types and prefixed names. > + > BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, LPVOID reserved) > { > switch (reason) > @@ -46,6 +75,121 @@ BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, LPVOID reserved) > return TRUE; > } > > +static HRESULT register_transform(CLSID *clsid, WCHAR *name, > + UINT32 cinput, MFT_REGISTER_TYPE_INFO *input_types, > + UINT32 coutput, MFT_REGISTER_TYPE_INFO *output_types) > +{ > + HKEY htransform, hclsid = 0; > + WCHAR buffer[64]; > + GUID *types; > + DWORD size; > + LONG ret; > + UINT32 i; > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, transform_keyW, &htransform)) > + return E_FAIL; > + > + GUIDToString(buffer, clsid); > + ret = RegCreateKeyW(htransform, buffer, &hclsid); > + RegCloseKey(htransform); > + if (ret) return E_FAIL; > + > + size = (strlenW(name) + 1) * sizeof(WCHAR); > + if (RegSetValueExW(hclsid, NULL, 0, REG_SZ, (BYTE *)name, size)) > + goto err; > + > + if (cinput && input_types) > + { > + size = 2 * cinput * sizeof(GUID); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + for (i = 0; i < cinput; i++) > + { > + memcpy(&types[2 * i], &input_types[i].guidMajorType, sizeof(GUID)); > + memcpy(&types[2 * i + 1], &input_types[i].guidSubtype, sizeof(GUID)); > + } > + > + ret = RegSetValueExW(hclsid, inputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); > + if (ret) goto err; > + } > + > + if (coutput && output_types) > + { > + size = 2 * coutput * sizeof(GUID); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + for (i = 0; i < coutput; i++) > + { > + memcpy(&types[2 * i], &output_types[i].guidMajorType, sizeof(GUID)); > + memcpy(&types[2 * i + 1], &output_types[i].guidSubtype, sizeof(GUID)); > + } > + > + ret = RegSetValueExW(hclsid, outputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); > + if (ret) goto err; > + } > + > + RegCloseKey(hclsid); > + return S_OK; > + > +err: > + RegCloseKey(hclsid); > + return E_FAIL; > +} > + > +static HRESULT register_category(CLSID *clsid, GUID *category) > +{ > + HKEY hcategory, htmp1, htmp2; > + WCHAR buffer[64]; > + DWORD ret; > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, categories_keyW, &hcategory)) > + return E_FAIL; > + > + GUIDToString(buffer, category); > + ret = RegCreateKeyW(hcategory, buffer, &htmp1); > + RegCloseKey(hcategory); > + if (ret) return E_FAIL; > + > + GUIDToString(buffer, clsid); > + ret = RegCreateKeyW(htmp1, buffer, &htmp2); > + RegCloseKey(htmp1); > + if (ret) return E_FAIL; > + > + RegCloseKey(htmp2); > + return S_OK; > +} > + > +/*********************************************************************** > + * MFTRegister (mfplat.@) > + */ > +HRESULT WINAPI MFTRegister(CLSID clsid, GUID category, LPWSTR name, UINT32 flags, UINT32 cinput, > + MFT_REGISTER_TYPE_INFO *input_types, UINT32 coutput, > + MFT_REGISTER_TYPE_INFO *output_types, void *attributes) This should use proper type for last argument. > +{ > + HRESULT hr; > + > + FIXME("(%s, %s, %s, %x, %u, %p, %u, %p, %p)\n", debugstr_guid(&clsid), debugstr_guid(&category), > + debugstr_w(name), flags, cinput, input_types, > + coutput, output_types, attributes); > + Why FIXME? > + if (attributes) > + FIXME("attributes not yet supported.\n"); > + > + if (flags) > + FIXME("flags not yet supported.\n"); > + > + hr = register_transform(&clsid, name, cinput, input_types, coutput, output_types); > + > + if (SUCCEEDED(hr)) > + hr = register_category(&clsid, &category); > + > + return hr; > +}

1 0

Re: [PATCH 5/9] d3dx9: Store effect creation flags in struct d3dx_base_effect.
by Matteo Bruni April 27, 2017

April 27, 2017

2017-04-27 13:05 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/effect.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index c2fb1d0..7885241 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -154,6 +154,7 @@ struct d3dx9_base_effect > struct d3dx_object *objects; > > struct d3dx_effect_pool *pool; > + DWORD flags; > }; > > struct ID3DXEffectImpl > @@ -169,7 +170,7 @@ struct ID3DXEffectImpl > struct d3dx_technique *active_technique; > struct d3dx_pass *active_pass; > BOOL started; > - DWORD flags; > + DWORD begin_flags; begin_flags is quite ugly IMO. If you really want to change it from just flags, maybe call it creation_flags.

2 2

Re: [PATCH 4/9] d3dx9/tests: Add test for D3DXFX_LARGEADDRESSAWARE effect creation flag.
by Matteo Bruni April 27, 2017

April 27, 2017

2017-04-27 13:05 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/tests/effect.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index 997c1fc..a58352e 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -5743,6 +5743,30 @@ static void test_cross_effect_handle(IDirect3DDevice9 *device) > > effect2->lpVtbl->Release(effect2); > effect1->lpVtbl->Release(effect1); > + > + hr = D3DXCreateEffect(device, test_effect_preshader_effect_blob, sizeof(test_effect_preshader_effect_blob), > + NULL, NULL, D3DXFX_LARGEADDRESSAWARE, NULL, &effect1, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + param1 = effect1->lpVtbl->GetParameterByName(effect1, NULL, "g_iVect"); > + ok(!!param1, "GetParameterByName failed.\n"); > + > + hr = effect1->lpVtbl->SetValue(effect1, param1, expected_ivect, sizeof(expected_ivect)); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + hr = effect1->lpVtbl->GetValue(effect1, param1, ivect, sizeof(ivect)); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + ok(!memcmp(ivect, expected_ivect, sizeof(expected_ivect)), "Vector value mismatch.\n"); > + > + if (0) > + { > + /* Native d3dx crashes in GetValue(). */ > + hr = effect1->lpVtbl->GetValue(effect1, "g_iVect", ivect, sizeof(ivect)); > + ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > + } > + > + effect1->lpVtbl->Release(effect1); > } The test is okay but it doesn't feel right to put it in test_cross_effect_handle(). Probably just make a separate function.

1 0

Re: [PATCH 2/3] dwrite: Fix name section strings lookup
by Nikolay Sivov April 27, 2017

April 27, 2017

On 27.04.2017 17:03, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/dwrite/opentype.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > The problem with this patch is that we want to continue and add as many strings for different locales as possible. So the condition should set 'exists' to TRUE after first pair was added successfully and never touch it after.

2 3

Re: [PATCH 1/3] dwrite: Don't crash on uninitialized cached and factory fields in dwritefontface_Release
by Nikolay Sivov April 27, 2017

April 27, 2017

On 27.04.2017 17:03, Piotr Caban wrote: > > The function may be called with the fields uninitialized from > create_fontface when init_font_data fails. > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/dwrite/font.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > > - factory_release_cached_fontface(This->cached); > - IDWriteFactory4_Release(This->factory); > + if (This->cached) > + factory_release_cached_fontface(This->cached); > + if (This->factory) > + IDWriteFactory4_Release(This->factory); Yes, this makes sense. The problem with this change is that 'cached' and 'factory' are not necessarily NULL on this failure path. I think at this point it would be better to use heap_alloc_zero(), and remove all explicit 0 initialization from create_fontface(). By the way, did you check why init_font_data() fails? If it's because opentype_get_font_familyname() fails, I'm interested in a log, or font file that causes it.

2 3

Re: [PATCH 3/3] dwrite: Fix EUDC font collection use after free issue
by Nikolay Sivov April 27, 2017

April 27, 2017

On 27.04.2017 17:04, Piotr Caban wrote: > > Without this patch factory_detach_fontcollection incorrectly releases > factory reference. > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/dwrite/dwrite_private.h | 2 +- > dlls/dwrite/font.c | 6 ++++-- > dlls/dwrite/main.c | 15 ++++++++------- > 3 files changed, 13 insertions(+), 10 deletions(-) > This makes sense, thanks. Please add some test for that in test_GetEudc*, similar to what test_object_lifetime() does in the beginning - testing that collection gets factory reference, but only once.

1 0

Re: [PATCH 2/3] dwrite: Fix name section strings lookup
by Nikolay Sivov April 27, 2017

April 27, 2017

On 27.04.2017 17:03, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/dwrite/opentype.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > - if (!(exists = opentype_decode_namerecord(header, storage_area, i, *strings))) > - continue; > + if ((exists = opentype_decode_namerecord(header, storage_area, i, *strings))) > + break; What happens exactly? I guess I'll need a font file for that too.

1 0

Re: [PATCH 1/13] msidb: Add stub tool for manipulating MSI databases.
by Hans Leidekker April 27, 2017

April 27, 2017

On Sun, 2017-04-09 at 13:12 -0600, Erich E. Hoover wrote: > +static int open_database( struct msidb_state *state ) > +{ > + LPCWSTR db_mode = state->create_database ? MSIDBOPEN_CREATEDIRECT : MSIDBOPEN_DIRECT; > + UINT ret; > + > + ret = MsiOpenDatabaseW( state->database_file, db_mode, &state->database_handle ); Databases opened in direct mode should always be committed. You should either do that in following patches, or open them in transacted mode.

2 2

Re: [4/4] ole32: Fix IDataObject_GetDataHere may not implement
by Huw Davies April 27, 2017

April 27, 2017

On Wed, Apr 26, 2017 at 03:45:50PM +0800, Wei Xie wrote: > Fix cann't insert any HBITMAP in RichEdit control > From 2c5a9b4df394c6d50bcc24bcc7b489a864224155 Mon Sep 17 00:00:00 2001 > From: Wei xie <xiewei(a)linuxdeepin.com> > Date: Wed, 26 Apr 2017 15:24:00 +0800 > Subject: [PATCH 4/4] ole32: Fix IDataObject_GetDataHere may not implement > > Fix cann't insert any HBITMAP in RichEdit control > > Signed-off-by: Wei xie <xiewei(a)linuxdeepin.com> > --- > dlls/ole32/ole2impl.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/dlls/ole32/ole2impl.c b/dlls/ole32/ole2impl.c > index a0c4445..5ee031e 100644 > --- a/dlls/ole32/ole2impl.c > +++ b/dlls/ole32/ole2impl.c > @@ -115,6 +115,10 @@ static HRESULT get_storage(IDataObject *data, IStorage *stg, UINT *src_cf, BOOL > med.u.pstg = stg; > med.pUnkForRelease = NULL; > hr = IDataObject_GetDataHere(data, &fmt, &med); > + if (FAILED(hr)) > + { > + hr = IDataObject_GetData(data, &fmt, &med); > + } This can't work. The STGMEDIUM is an [out]-only parameter of _GetData(), meaning that the callee will return a new stg in the STGMEDIUM. If this is indeed called (we need tests to check), then you'd have to copy the returned stg into the original one. Huw.

1 0

Re: [3/4] ole32: Add init cache code after OleLoad in OleCreateFromDataEx
by Huw Davies April 27, 2017

April 27, 2017

On Wed, Apr 26, 2017 at 03:46:23PM +0800, Wei Xie wrote: > Fix cann't insert any HBITMAP in RichEdit control > From a96e73f270745f0694ea340eb8119566d75f1117 Mon Sep 17 00:00:00 2001 > From: Wei xie <xiewei(a)linuxdeepin.com> > Date: Wed, 26 Apr 2017 15:14:36 +0800 > Subject: [PATCH 3/4] ole32: Add init cache code after OleLoad in > OleCreateFromDataEx > > Fix cann't insert any HBITMAP in RichEdit control > > Signed-off-by: Wei xie <xiewei(a)linuxdeepin.com> > --- > dlls/ole32/ole2impl.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/dlls/ole32/ole2impl.c b/dlls/ole32/ole2impl.c > index ccf31fa..a0c4445 100644 > --- a/dlls/ole32/ole2impl.c > +++ b/dlls/ole32/ole2impl.c > @@ -181,6 +181,7 @@ HRESULT WINAPI OleCreateFromDataEx(IDataObject *data, REFIID iid, DWORD flags, > { > HRESULT hr; > UINT src_cf; > + IOleCache* ole_cache; > > FIXME("(%p, %s, %08x, %08x, %d, %p, %p, %p, %p, %p, %p, %p): stub\n", > data, debugstr_guid(iid), flags, renderopt, num_cache_fmts, adv_flags, cache_fmts, > @@ -193,6 +194,11 @@ HRESULT WINAPI OleCreateFromDataEx(IDataObject *data, REFIID iid, DWORD flags, > if(FAILED(hr)) return hr; > > /* FIXME: Init cache */ > + hr = IUnknown_QueryInterface((IUnknown*)*obj, &IID_IOleCache, (void**)&ole_cache); > + if (SUCCEEDED(hr)) > + { > + hr = IOleCache_InitCache(ole_cache, data); > + } You'll need to release the ole_cache. Again we'll need some tests. Huw.

1 0

Re: [2/4] ole32: Support HBITMAP format in DataCache_GetExtent and DataCache_Draw
by Huw Davies April 27, 2017

April 27, 2017

On Wed, Apr 26, 2017 at 03:44:01PM +0800, Wei Xie wrote: > Fix cann't insert any HBITMAP in RichEdit control > From 91b46bc9da357b76b8028d058a191743e9a31a32 Mon Sep 17 00:00:00 2001 > From: Wei xie <xiewei(a)linuxdeepin.com> > Date: Wed, 26 Apr 2017 15:05:59 +0800 > Subject: [PATCH 2/4] ole32: Support HBITMAP format in DataCache_GetExtent and > DataCache_Draw > > Fix cann't insert any HBITMAP in RichEdit control > > Signed-off-by: Wei xie <xiewei(a)linuxdeepin.com> > --- > dlls/ole32/datacache.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > > @@ -1908,6 +1926,40 @@ static HRESULT WINAPI DataCache_GetExtent( > > return S_OK; > } > + case CF_BITMAP: > + { > + HDC hdc; > + char dst_bmibuf[FIELD_OFFSET( BITMAPINFO, bmiColors[256] )]; > + BITMAPINFO *dst_info = (BITMAPINFO *)dst_bmibuf; > + BITMAPINFOHEADER *info; > + LONG x_pels_m, y_pels_m; > + > + if (cache_entry->stgmedium.tymed != TYMED_GDI) > + continue; > + > + hdc = GetDC(NULL); > + memset(dst_info, 0, sizeof(char)*FIELD_OFFSET( BITMAPINFO, bmiColors[256] )); > + dst_info->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + > + GetDIBits(hdc, cache_entry->stgmedium.u.hBitmap, 0, 1, NULL, dst_info, DIB_RGB_COLORS); > + > + info = &dst_info->bmiHeader; I'm not convinced adding the info variable helps here. Just use dst_info->bmiHeader throughout. Better still drop the 'dst_' and use BITMAPINFO *info = (BITMAPINFO *)bmibuf; > + x_pels_m = info->biXPelsPerMeter; > + y_pels_m = info->biYPelsPerMeter; > + > + /* Size in units of 0.01mm (ie. MM_HIMETRIC) */ > + if (x_pels_m != 0 && y_pels_m != 0) > + { > + lpsizel->cx = info->biWidth * 100000 / x_pels_m; > + lpsizel->cy = info->biHeight * 100000 / y_pels_m; > + } > + else > + { > + lpsizel->cx = info->biWidth * 2540 / GetDeviceCaps( hdc, LOGPIXELSX ); > + lpsizel->cy = info->biHeight * 2540 / GetDeviceCaps( hdc, LOGPIXELSY ); > + } You need a ReleaseDC(0, hdc); > + return S_OK; > + } > } > } > > -- > 2.10.2 > >

1 0

Re: [1/4] ole32: Implement DataCache_InitCache
by Huw Davies April 27, 2017

April 27, 2017

On Wed, Apr 26, 2017 at 03:42:59PM +0800, Wei Xie wrote: > Fix cann't insert any HBITMAP in RichEdit control Hi, Thanks for working on this. In general this series in going to need some unit tests to be submitted along with it. There are already some for the data-cache in dlls/ole32/tests/ole2.c. The documentation for IOleCache_InitCache() implies that it supposed to be used after first calling IOleCache_Cache() to specify which formats are to be cached, rather than the way you have implemented it. I'd imagine that OleCache_InitCache() would call IDataObject_GetData() on each of the wanted formats and pass that off to IOleCache_SetData(). Anyway, some tests will confirm this. I'll add a couple of comments to the other patches, but the tests need writing first. [Note, it's "can't" or "cannot", not "cann't"]. Huw.

1 0

Re: [PATCH 5/5] user32/tests: Try to read the dpi from the user key first
by Marvin April 27, 2017

April 27, 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=30508 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2517: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2528: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w1064 (32 bit sysparams) === sysparams.c:204: Test failed: Unexpected WM_DISPLAYCHANGE message

2 1

Re: [PATCH v2 08/11] d3d11/tests: Add test for state refcounting.
by Marvin April 27, 2017

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

1 0

Re: [PATCH 1/5] d3dx9/tests: Get rid of compare_rotation.
by Marvin April 27, 2017

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

2 1

Re: [PATCH 5/5] d3dx9/tests: Get rid of compare_planes.
by Marvin April 26, 2017

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

1 0

Re: [PATCH 4/5] d3dx9/tests: Cleanup compare_vectors.
by Marvin April 26, 2017

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

1 0

Re: [PATCH 3/5] d3dx9/tests: Get rid of compare_translation.
by Marvin April 26, 2017

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

1 0

Re: [PATCH 2/5] d3dx9/tests: Get rid of compare_scale.
by Marvin April 26, 2017

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

1 0

Re: [PATCH] d3dx9: Support parameters sharing in effect.
by Marvin April 26, 2017

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

1 0

Re: [PATCH] d3dx9/tests: Cleanup expect_vec3.
by Marvin April 26, 2017

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

1 0