June 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

[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 03/10 v4] gdiplus: Add functions for managing metafile objects id
by Vincent Povirk July 3, 2017

July 3, 2017

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

2 2

Definition (or not) of IDXGIResource methods
by Ben "Root" Anderson June 30, 2017

June 30, 2017

I've been studying the DXGI code with an eye for implementing the DirectX-side shared resource functionality so that an application would hopefully be able to share Direct3D textures with a Vulkan instance, and what I'm seeing has me rather confused. IDXGIResource appears to be declared, with a number of methods, in include/dxgi.idl. I'm not clear on what exactly an IDL file is, but my impression is it's similar to a specfile, except for headers of C++ interfaces. In any case, none of the methods declared appear to have any definition anywhere in Wine. The logical conclusion would be they're automatically generated stubs. But that doesn't make sense, because the DXGI test at dlls/dxgi/tests/device.c calls IDXGIResource_GetUsage and appears to expect it to succeed, implying that it's implemented *somewhere*. What am I missing?

2 1

Re: winedump: Add initial support for handling EMF+ records
by Dmitry Timoshkov June 30, 2017

June 30, 2017

Piotr Caban <piotr(a)codeweavers.com> wrote: > #define EMRCASE(x) case x: printf("%-20s %08x\n", #x, length); break > +#define EMRPLUSCASE(x) case x: printf(" %-20s %04x %08x\n", #x, header->Flags, header->Size); break; ';' at the end is redundant. EMRCASE macro intentionally omits it. > + /* Hand EMF+ records */ > + if (length >= 16 && !memcmp((char*)PRD(offset + 12, sizeof(unsigned int)), "EMF+", 4)) A typo in the comment. -- Dmitry.

2 1

Re: [PATCH 1/9 v3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Dmitry Timoshkov June 30, 2017

June 30, 2017

Piotr Caban <piotr(a)codeweavers.com> wrote: > +static GpStatus METAFILE_CreateCompressedImageStream(GpImage *image, IStream **stream, DWORD *size) > +{ > + static const CLSID png_clsid = { 0x557cf406, 0x1a04, 0x11d3, > + { 0x9a, 0x73, 0x0, 0x0, 0xf8, 0x1e, 0xf3, 0x2e } }; > + LARGE_INTEGER zero; > + STATSTG statstg; > + GpStatus stat; > + HRESULT hr; > + > + *size = 0; > + > + hr = CreateStreamOnHGlobal(NULL, TRUE, stream); > + if (FAILED(hr)) return hresult_to_status(hr); > + > + stat = GdipSaveImageToStream(image, *stream, &png_clsid, NULL); Even internally gdiplus shouldn't do this kind of hacks IMO, if there is a need for a shortcut for a particular encoder class id it's better to add a helper. Have a look at the encoder/decoder tests how it's supposed to look like. -- Dmitry.

2 3

Re: [PATCH 3/9 v3] gdiplus: Add support for ImageAttributes when drawing image to metafile
by Dmitry Timoshkov June 30, 2017

June 30, 2017

Piotr Caban <piotr(a)codeweavers.com> wrote: > @@ -259,7 +278,7 @@ static DWORD METAFILE_AddObjectId(GpMetafile *metafile) > id = 0; > for (i=1; i<sizeof(metafile->objects_table)/sizeof(metafile->objects_table[0]); i++) > { > - if (metafile->objects_table[id] < metafile->objects_table[i]) > + if (metafile->objects_table[id] > metafile->objects_table[i]) This looks strange to change this right in the next patch. -- Dmitry.

2 1

Re: [PATCH 3/4 v2] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Vincent Povirk June 29, 2017

June 29, 2017

+ draw_image_record->SrcRect.Width = units_to_pixels(srcwidth, srcUnit, metafile->image.xres);; + draw_image_record->SrcRect.Height = units_to_pixels(srcheight, srcUnit, metafile->image.yres);; One semicolon is probably enough. I think we should put a little more effort into object management up front. I would start it by having the Add*Object functions return an id to the caller, and adding a ReleaseObjects function to indicate that the current objects are no longer needed. For now, we could just implement this as a counter that we reset to 0.

1 0

Re: [PATCH 3/4] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Vincent Povirk June 29, 2017

June 29, 2017

I don't fully understand the spec, so I could be wrong about this, but I think for texture brushes we'll need the ability to create an EmfPlusImage structure without an EmfPlusObject record.

2 3

Re: [PATCH] libs/wine: Use Windows collation when sorting and comparing strings
by Alexandre Julliard June 29, 2017

June 29, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > This patch fixes bugs 10767 and 32490, amongst other bugs. > It also fixes subkey sorting issues in regedit's treeview control. > > From: Dmitry Timoshkov <dtimoshkov(a)codeweavers.com> > > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/kernel32/tests/locale.c | 9 +++---- > libs/wine/collation.c | 60 ++++++++++++++++++++++---------------------- > 2 files changed, 34 insertions(+), 35 deletions(-) That's a generated file, changes would have to be made in the generating script instead (tools/make_unicode). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] msi: Fix a buffer overrun.
by Austin English June 29, 2017

June 29, 2017

On Thu, Jun 29, 2017 at 12:09 AM, Zebediah Figura <z.figura12(a)gmail.com> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=43257 > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/msi/package.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/msi/package.c b/dlls/msi/package.c > index bf6ae10..3a75a1c 100644 > --- a/dlls/msi/package.c > +++ b/dlls/msi/package.c > @@ -1812,17 +1812,17 @@ INT MSI_ProcessMessage( MSIPACKAGE *package, INSTALLMESSAGE eMessageType, MSIREC > { > WCHAR template_s[1024]; > WCHAR *template_rec, *template; > - DWORD length; > > LoadStringW(msi_hInstance, IDS_INFO, template_s, 1024); > > - res = MSI_RecordGetStringW(record, 0, NULL, &length); > + res = MSI_RecordGetStringW(record, 0, NULL, &len); > if (res != ERROR_SUCCESS && res != ERROR_MORE_DATA) > return res; > len++; > template_rec = msi_alloc(len * sizeof(WCHAR)); > if (!template_rec) return ERROR_OUTOFMEMORY; > - MSI_RecordGetStringW(record, 0, template_rec, &length); > + MSI_RecordGetStringW(record, 0, template_rec, &len); > + len++; > > template = msi_alloc((len + strlenW(template_s)) * sizeof(WCHAR)); > if (!template) return ERROR_OUTOFMEMORY; > -- > 2.7.4 > > > Works for me, thanks. -- -Austin GPG: 14FB D7EA A041 937B

1 0

Re: [PATCH 1/6] include: Support wine_dbgstr_longlong in tests
by Michael Stefaniuc June 29, 2017

June 29, 2017

Hello Alistair, On 06/29/2017 02:43 AM, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > include/wine/test.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/include/wine/test.h b/include/wine/test.h > index af602c0..d8e5490 100644 > --- a/include/wine/test.h > +++ b/include/wine/test.h > @@ -68,6 +68,7 @@ extern const char *wine_dbgstr_wn( const WCHAR *str, int n ); > extern const char *wine_dbgstr_guid( const GUID *guid ); > extern const char *wine_dbgstr_rect( const RECT *rect ); > static inline const char *wine_dbgstr_w( const WCHAR *s ) { return wine_dbgstr_wn( s, -1 ); } > +extern const char *wine_dbgstr_longlong( ULONGLONG ll ); > > /* strcmpW is available for tests compiled under Wine, but not in standalone > * builds under Windows, so we reimplement it under a different name. */ > @@ -541,6 +542,17 @@ const char *wine_dbgstr_rect( const RECT *rect ) > return res; > } > > +const char *wine_dbgstr_longlong( ULONGLONG ll ) > +{ > + char *res; The other functions have an empty line after the variable declarations. > + res = get_temp_buffer( 17 ); > + if (sizeof(ll) > sizeof(unsigned long) && ll >> 32) > + sprintf(res, "%lx%08lx", (unsigned long)(ll >> 32), (unsigned long)ll); Either place a space after the opening parenthesis and before the closing one or don't but please stay consistent inside a function. The file prefers the variant with the spaces. > + else > + sprintf(res, "%lx", (unsigned long)ll); > + return res; The other debug functions with variable length output release the unused part of the temp buffer. You can waste up to 15 bytes here. > +} > + > /* Find a test by name */ > static const struct test *find_test( const char *name ) > { > thanks bye michael

1 0

Re: [PATCH] libs/wine: Use Windows collation when sorting and comparing strings
by Marvin June 29, 2017

June 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=31953 Your paranoid android. === w7u (32 bit locale) === locale.c:2927: Test failed: qsort using lstrcmpA failed for element 6 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 7 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 8 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 9 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 10 locale.c:2935: Test failed: qsort using CompareStringA failed for element 6 locale.c:2935: Test failed: qsort using CompareStringA failed for element 7 locale.c:2935: Test failed: qsort using CompareStringA failed for element 8 locale.c:2935: Test failed: qsort using CompareStringA failed for element 9 locale.c:2935: Test failed: qsort using CompareStringA failed for element 10 locale.c:2943: Test failed: qsort using sort keys failed for element 6 locale.c:2943: Test failed: qsort using sort keys failed for element 7 locale.c:2943: Test failed: qsort using sort keys failed for element 8 locale.c:2943: Test failed: qsort using sort keys failed for element 9 locale.c:2943: Test failed: qsort using sort keys failed for element 10

1 0

Re: [2/7] webservices: Add an index to the static dictionary.
by Alexandre Julliard June 29, 2017

June 29, 2017

Hans Leidekker <hans(a)codeweavers.com> writes: > +static const ULONG dict_sorted[] = > +{ > + 81, 91, 129, 314, 185, 164, 346, 66, 235, 305, 14, 6, 114, 97, 96, 94, 11, 95, 110, 451, > + 443, 121, 213, 7, 71, 82, 431, 343, 74, 75, 73, 59, 447, 445, 467, 163, 472, 463, 453, 409, Why is it so large? Shouldn't it be the same size as the strings array? -- Alexandre Julliard julliard(a)winehq.org

2 1

What are the -l options I should be using to assure I am using the Wine Staging 2.10 versions of the standard system libraries?
by Alan W. Irwin June 28, 2017

June 28, 2017

In the past (in the Wine 1.6 era) I used an old snapshot (4.7.2) of MinGW/MSYS on wine to build applications with success, and I would like to stick with that snapshot for Wine Staging 2.10 since I have found in the past later versions of MinGW/MSYS were not as reliable as 4.7.2. However, since that snapshot was initially installed with Wine 1.6 (or maybe even earlier) I assume its default header locations and library locations refer to some old wine version, and the general question is how do I override those to refer to the equivalent Wine Staging 2.10 locations. I have a simple test programme (attached) that illustrates the problem: bash.exe-3.1$ g++ /z/home/wine/wine_staging/test_rand_s.cxx z:/home/wine/wine_staging/test_rand_s.cxx: In function 'int main()': z:/home/wine/wine_staging/test_rand_s.cxx:18:5: error: 'errno_t' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:18:21: error: expected ';' before 'err' z:/home/wine/wine_staging/test_rand_s.cxx:23:9: error: 'err' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:23:31: error: 'rand_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:26:53: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:29:60: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:32:18: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:37:9: error: 'err' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:37:31: error: 'rand_s' was not declared in this scope (I presume those errors are due to those functions not being defined by Wine way back when). That compile issue is solved as follows: bash.exe-3.1$ g++ /z/home/wine/wine_staging/test_rand_s.cxx -I/z/opt/wine-staging/include/wine/msvcrt -I/z/opt/wine-staging/in clude/wine/windows C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x35): undefined reference to `rand_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x4c): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xa6): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xc6): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xdc): undefined reference to `rand_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xf3): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x124): undefined reference to `printf_s' z:/home/wine/wine_staging/mingw-4.7.2/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: C:\users\wine\Temp\cckTYgsp .o: bad reloc address 0x13 in section `.eh_frame' z:/home/wine/wine_staging/mingw-4.7.2/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation collect2.exe: error: ld returned 1 exit status However, that compile fix obviously leaves the above link issue which I attempted to solve by appending the options -L/z/opt/wine-staging/lib/wine -lmsvcrt which worked (in the sense that that library was found) but apparently that particular library does not implement rand_s and printf_s since the same link errors occurred as above. So what are the -l options I should be using to assure I am using the Wine Staging 2.10 versions of the standard system libraries? N.B. I realize this issue would likely be taken care of automatically if I installed the latest version of MinGW/MSYS on the Wine Staging 2.10 platform. But I have my reasons explained above why I would prefer to use the 4.7.2 snapshot of MinGW/MSYS instead. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

1 0

Re: [6/6] wsdapi/tests: Add tests for WSDXMLGetValueFromAny.
by Marvin June 28, 2017

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

1 0

Re: [4/6] wsdapi: Implement IWSDUdpAddress_Get/SetSockAddr.
by Marvin June 28, 2017

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

1 0

Re: [3/6] wsdapi: Implement IWSDUdpAddress_Get/SetMessageType.
by Marvin June 28, 2017

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

1 0

Re: [2/6] wsdapi: Implement IWSDUdpAddress_Get/SetPort.
by Marvin June 28, 2017

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

1 0

Re: [1/6] wsdapi: Implement IWSDUdpAddress_GetTransportAddress[Ex].
by Marvin June 28, 2017

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

1 0

Re: [PATCH 3/3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Vincent Povirk June 28, 2017

June 28, 2017

Can we keep the code for generating an EmfplusImage structure separate from this? We'll want to reuse it for EmfPlusDrawImage and EmfPlusTextureBrushOptionalData.

2 1

Re: [PATCH v2] gdiplus: Scale widened dashes to the pen width.
by Vincent Povirk June 28, 2017

June 28, 2017

I don't understand this part. On Tue, Jun 27, 2017 at 5:27 PM, Zebediah Figura <z.figura12(a)gmail.com> wrote: > @@ -2175,8 +2182,7 @@ static void widen_dashed_figure(GpPath *path, GpPen *pen, int start, int end, > if (dash_index % 2 == 0 && num_tmp_points != 0) > { > /* last dash overflows last segment */ > - tmp_points[num_tmp_points] = path->pathdata.Points[end]; > - widen_open_figure(tmp_points, pen, 0, num_tmp_points, > + widen_open_figure(tmp_points, pen, 0, num_tmp_points-1, > draw_start_cap ? pen->startcap : LineCapFlat, pen->customstart, > closed ? LineCapFlat : pen->endcap, pen->customend, last_point); > }

2 1

WineConf RSVP
by Jacek Caban June 28, 2017

June 28, 2017

Hi all, Jeremy has set up RSVP page for this year conference: https://www.winehq.org/wineconf/rsvp Please fill the form if you're planning to attend. The pool of rooms for participants is reserved until middle of October. However, some rooms will be released in the end of July unless we know that we need them. That said, an information about number of participants is important for organization reasons. Thanks, Piotr and Jacek

1 0

Re: [v2 PATCH] dmime: Query the Sound buffer for supported interfaces
by Michael Stefaniuc June 28, 2017

June 28, 2017

Hello Alistair, On 06/28/2017 08:46 AM, Alistair Leslie-Hughes wrote: > v2: Fix compile warning. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dmime/audiopath.c | 18 +++++++----------- > dlls/dmime/tests/dmime.c | 23 +++++++++++++++++++++++ > 2 files changed, 30 insertions(+), 11 deletions(-) > > diff --git a/dlls/dmime/audiopath.c b/dlls/dmime/audiopath.c > index 04f0af03d0..211f2156f2 100644 > --- a/dlls/dmime/audiopath.c > +++ b/dlls/dmime/audiopath.c > @@ -137,17 +137,13 @@ static HRESULT WINAPI IDirectMusicAudioPathImpl_GetObjectInPath (IDirectMusicAud > case DMUS_PATH_BUFFER: > if (This->pDSBuffer) > { > - if (IsEqualIID (iidInterface, &IID_IDirectSoundBuffer8)) { > - IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, &IID_IDirectSoundBuffer8, ppObject); > - TRACE("returning %p\n",*ppObject); > - return S_OK; > - } else if (IsEqualIID (iidInterface, &IID_IDirectSound3DBuffer)) { > - IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, &IID_IDirectSound3DBuffer, ppObject); > - TRACE("returning %p\n",*ppObject); > - return S_OK; > - } else { > - FIXME("Bad iid\n"); > - } you need to add tests for all the interfaces supported by the DirectSoundBuffer object too: IID_IDirectSoundNotify, IID_IDirectSound3DBuffer, IID_IKsPropertySet. But if native supports the query for those too this can be simplified even further to a return IDirectSoundBuffer8_QueryInterface(This->pDSBuffer, iidInterface, ppObject); The extra tracing isn't really needed as IDirectSoundBuffer8_QueryInterface() already does that. And any serious dmusic tracing needs to include the dsound debug channels anyway. > + if(IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, iidInterface, ppObject) == S_OK) { Just in case you insist on keeping the extra tracing: "if" is not a function so please have a space between it and the "(". And no space between the function name and "(". > + TRACE("returning %p\n",*ppObject); Please add a space after the "," thanks bye michael > + return S_OK; > + } > + > + WARN("Unsupported iid %s\n", debugstr_guid(iidInterface)); > + return E_NOINTERFACE; > } > break; > > diff --git a/dlls/dmime/tests/dmime.c b/dlls/dmime/tests/dmime.c > index a154eac50b..13c6afbfec 100644 > --- a/dlls/dmime/tests/dmime.c > +++ b/dlls/dmime/tests/dmime.c > @@ -23,6 +23,7 @@ > #include <wine/test.h> > #include <dmusici.h> > #include <audioclient.h> > +#include <guiddef.h> > > #define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0])) > > @@ -45,8 +46,11 @@ static void test_COM_audiopath(void) > IDirectMusicAudioPath *dmap; > IUnknown *unk; > IDirectMusicPerformance8 *performance; > + IDirectSoundBuffer *dsound; > + IDirectSoundBuffer8 *dsound8; > ULONG refcount; > HRESULT hr; > + DWORD buffer = 0; > > hr = CoCreateInstance(&CLSID_DirectMusicPerformance, NULL, CLSCTX_INPROC_SERVER, > &IID_IDirectMusicPerformance8, (void**)&performance); > @@ -89,6 +93,25 @@ static void test_COM_audiopath(void) > ok(refcount == 5, "refcount == %u, expected 5\n", refcount); > refcount = IUnknown_Release(unk); > > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IDirectSoundBuffer, (void**)&dsound); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IDirectSoundBuffer_Release(dsound); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IDirectSoundBuffer8, (void**)&dsound8); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IDirectSoundBuffer8_Release(dsound8); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IUnknown, (void**)&unk); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IUnknown_Release(unk); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &GUID_NULL, (void**)&dsound8); > + ok(hr == E_NOINTERFACE, "Failed: %08x\n", hr); > + > while (IDirectMusicAudioPath_Release(dmap) > 1); /* performance has a reference too */ > IDirectMusicPerformance8_CloseDown(performance); > IDirectMusicPerformance8_Release(performance); >

1 0

Rerun TestBot tasks that timeout?
by Francois Gouget June 28, 2017

June 28, 2017

The hope would be that the timeout was due to an external factor and that the task won't time out on the second try. But it's also quite likely that that the timeout is caused by an issue with the test itself and then it would time out again, and again. So with the default 3 tries this would result in tripling the time it takes to get the results (so 6 minutes and 3 reverts). Furthermore timeouts are not that common (particularly spurious ones) so it may not be worth changing anything. If we do want to do something the patch would be simple. I believe something like the patch below would do the trick. We could also have a single retry in such a case but this would require to special-case the code. diff --git a/testbot/bin/WineRunTask.pl b/testbot/bin/WineRunTask.pl index 1663c105..0cb0ea18 100755 --- a/testbot/bin/WineRunTask.pl +++ b/testbot/bin/WineRunTask.pl @@ -765,4 +765,5 @@ FatalTAError(undef, $TAError, $PossibleCrash) if (defined $TAError); # Wrap up # -WrapUpAndExit($NewStatus, $TaskFailures); +# Don't retry running a timed out test if it has failures anyway +WrapUpAndExit($NewStatus, $TaskFailures, ($TaskTimedOut and $TaskFailures == 1)); -- 2.11.0

1 0

Re: [v2 PATCH] oledb32: Support DBTYPE_DBTIMESTAMP to DBTYPE_WSTR in DataConvert
by Marvin June 28, 2017

June 28, 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=31909 Your paranoid android. === wxppro (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2003std (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === wvistau64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2008s64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7u (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7pro64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w8 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w864 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w1064 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4

1 0

Re: [PATCH] oledb32: Support DBTYPE_DBTIMESTAMP to DBTYPE_WSTR in DataConvert
by Marvin June 28, 2017

June 28, 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=31908 Your paranoid android. === wxppro (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2003std (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === wvistau64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2008s64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7u (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7pro64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w8 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w864 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w1064 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4

1 0

Re: [PATCH] gdiplus: Scale widened dashes to the pen width.
by Vincent Povirk June 27, 2017

June 27, 2017

If the dash_pos variable is relative to pen width, we need to fix the other references to it. It doesn't make sense to compare it directly with segment_length and segment_pos. Or we could scale the whole dash_pattern array by pen width at the start.

2 2

Fwd: Improvements to the heap allocator
by Andrea Canciani June 27, 2017

June 27, 2017

The original message was apparently blocked by the mailing list rules/filter. Now I am subscribed to wine-devel, sorry if you get the message twice. Andrea ---------- Forwarded message ---------- From: Andrea Canciani <ranma42(a)gmail.com> Date: Fri, Jun 23, 2017 at 9:29 AM Subject: Improvements to the heap allocator To: wine-devel(a)winehq.org Yesterday I opened a bug report about a performance issue in the wine heap allocator: https://bugs.winehq.org/show_bug.cgi?id=43224 Since I was also asking for some suggestions about what the preferred fix would be, Sebastian Lackner pointed to this mailing list. The bug report contains the source code for a program that has an allocation pattern that is very bad (for the current wine allocator). This appears to be a known problem, but I was unable to find any test/benchmark that shows such degenerate behavior. So far none of the attempts at fixing it seem to have landed. Some possible approaches are: 1. ensure that the freelist sizes cover all (alignment rounded) sizes up to a certain value; 2. when looking up for a free block, start from the freelist whose smallest element is at least as big as the desired block; 3. implement more complex free block management. #1 would fix the issue for some allocations sizes, but for bigger allocations the problem would stay the same. #2 would fix the performance problem at the cost of increased memory usage: for some sizes it would be possible that after a block is allocated and freed, the following allocation for that size does not re-use that memory (if the free block is stored in a freelist together with smaller blocks). #3 would increase the complexity of the code; to keep it under control, it might be possible to re-use the red-black tree implementation already available in wine. To avoid regressing performance, the smallest blocks might still be handled with simple freelists (fixed as in #1), while larger blocks are managed in a tree. Some of the current/previous attempts at tackling this issue are: - https://github.com/wine-compholio/wine-staging/blob/ master/patches/ntdll-Heap_FreeLists/0001-ntdll-Improve- heap-allocation-performance-by-using-m.patch (implements #1) - https://github.com/laino/wine-patches (IIUC, a combination of #1 and #3, in which the code tries to keep the freelist length under control, but AFAICT there is no guaranteed bound) I would like to try and work on fixing this, but there are some decision to make that might depend on constraints I am not aware of. Would the solution I propose (#3, rbtree based, with some tuning for small allocation sizes) be acceptable? Are there any benchmarks that a new implementation should strive to improve or at least avoid regressing? Suggestions and alternative solutions are welcome :) Sorry for the long message, thank you for your patience Andrea

1 0

Re: [v5 2/3] d3dx9: Get rid of constant's length checking for matrix in set_constants().
by Matteo Bruni June 27, 2017

June 27, 2017

2017-06-22 15:11 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > When count in const_upload_info is calculated precisely (considering actual > constant set length), boolean matrix setting fall in direct copy path, unless > transpose is required. The case of incomplete last row for matrix should be > handled in set_constants() for transposed boolean constant only. > > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v5: > - added check for constant size not exceeding parameter size. The check for > non array, non struct constants should be sufficient as the dimensions of > arrays and structs are derived from const_set data and register counts > from constant description is not used for them. I don't understand what you mean here. > @@ -1417,6 +1433,16 @@ static HRESULT init_set_constants_param(struct d3dx_const_tab *const_tab, ID3DXC > && !info.transpose && info.minor == info.major_stride > && info.count == get_offset_reg(const_set.table, const_set.register_count) > && info.count * sizeof(unsigned int) <= param->bytes; > + if (info.minor_remainder && !const_set.direct_copy && !info.transpose) > + FIXME("Incomplete last row for not transposed matrix which cannot be directly copied, parameter %s.\n", > + debugstr_a(param->name)); > + > + if (info.major_count > info.major > + || (info.major_count == info.major && info.minor_remainder)) > + { > + WARN("Constant dimensions exceed parameter size.\n"); > + return D3DERR_INVALIDCALL; > + } It seems to me that this catches all the problematic cases.

2 2

Re: [v5 1/3] d3dx9: Remove redundant parameter size check in set_constants().
by Matteo Bruni June 27, 2017

June 27, 2017

2017-06-22 15:11 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v5: > - Removed assert for parameter data length. The check for constant size not exceeding parameter size > is in the next patch. Otherwise the code would be changed right in the next patch after modifying > get_const_upload_info(), while before that the check is redundant. Yeah, it would have been slightly preferable with the check in a separate patch before this one. The check would have been redundant in practice but that's a bit of an "implementation detail". Certainly not a big deal though.

1 0

Re: [PATCH 2/2] d3drm: Store animation options
by Henri Verbeet June 27, 2017

June 27, 2017

On 27 June 2017 at 10:17, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_animation2_SetOptions(IDirect3DRMAnimation2 *iface, D3DRMANIMATIONOPTIONS options) > +{ > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation2(iface); > + static const DWORD supported_options = D3DRMANIMATION_OPEN | D3DRMANIMATION_CLOSED | D3DRMANIMATION_LINEARPOSITION > + | D3DRMANIMATION_SPLINEPOSITION | D3DRMANIMATION_SCALEANDROTATION | D3DRMANIMATION_POSITION; > + > + TRACE("iface %p, options %#x.\n", iface, options); > + > + if (options && !(options & supported_options)) > + return D3DRMERR_BADVALUE; Should that be "if (options & ~supported_options)"? The test is ambiguous about that. > @@ -6776,6 +6777,42 @@ static void test_animation(void) > IDirect3DRMFrame3_Release(frame3); > IDirect3DRMFrame_Release(frame); > > + /* Animation options. */ > + options = IDirect3DRMAnimation_GetOptions(animation); > + ok(options == (D3DRMANIMATION_CLOSED | D3DRMANIMATION_LINEARPOSITION), > + "Unexpected default options %#x.\n", options); > + > + /* Undefined mask value */ > + hr = IDirect3DRMAnimation_SetOptions(animation, 0xdeadbeef); > + ok(hr == D3DRMERR_BADVALUE, "Unexpected hr %#x.\n", hr); 0xdeadbeef is a bit of a poor test value here, since it will trigger both the "D3DRMANIMATION_OPEN | D3DRMANIMATION_CLOSED" and "D3DRMANIMATION_LINEARPOSITION | D3DRMANIMATION_SPLINEPOSITION" paths as well. Is it valid to set 0 as an option? Is it valid to set e.g. D3DRMANIMATION_OPEN, but not one of D3DRMANIMATION_LINEARPOSITION and D3DRMANIMATION_SPLINEPOSITION? I.e., is it just invalid to set conflicting options, or should always exactly one of OPEN/CLOSED and LINEARPOSITION/SPLINEPOSITION be set?

2 3

Re: [PATCH 1/2] d3drm: Store animated frame pointer in animation object
by Henri Verbeet June 27, 2017

June 27, 2017

On 27 June 2017 at 10:17, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > static HRESULT WINAPI d3drm_animation1_SetFrame(IDirect3DRMAnimation *iface, IDirect3DRMFrame *frame) > { > - FIXME("iface %p, frame %p.\n", iface, frame); > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation(iface); > + HRESULT hr = D3DRM_OK; > > - return E_NOTIMPL; > + TRACE("iface %p, frame %p.\n", iface, frame); > + > + if (frame) > + { > + hr = IDirect3DRMFrame_QueryInterface(frame, &IID_IDirect3DRMFrame3, (void **)&animation->frame); > + if (SUCCEEDED(hr)) > + IDirect3DRMFrame3_Release(animation->frame); > + } > + else > + animation->frame = NULL; > + > + return hr; > } There's nothing necessarily wrong with this, but I feel the following alternative is worth pointing out: struct d3drm_frame *f = unsafe_impl_from_IDirect3DRMFrame(frame); ... animation->frame = f ? &f->IDirect3DRMFrame3_iface : NULL; return D3DRM_OK; or even ... return d3drm_animation2_SetFrame(&animation->IDirect3DRMAnimation2_iface, f ? &f->IDirect3DRMFrame3_iface : NULL); which is a pattern that's used in ddraw for this kind of thing.

2 1

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Clemens Tamme June 27, 2017

June 27, 2017

ok, i will rewrite so the same terms are used in the docs of GdipAddPathLine and GdipAddPathEllipse 2017-06-26 22:18 GMT+02:00 Marvin <testbot(a)winehq.org>: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Assigned". > > This means that the patch has been assigned to a reviewer. If the > reviewer signs off on the patch, it will be committed, otherwise > you'll receive advice on how to improve it. If you don't hear anything > after a couple of weeks, please resend the patch. >

1 0

Re: [PATCH v3 1/4] msi/tests: Add tests for external UI callback.
by Marvin June 27, 2017

June 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=31868 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 3/4] msi: Implement INSTALLMESSAGE_INITIALIZE and INSTALLMESSAGE_TERMINATE.
by Marvin June 27, 2017

June 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=31865 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 2/4] msi: Send the correct UI messages upon calling MsiDoAction().
by Marvin June 27, 2017

June 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=31864 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 1/4] msi/tests: Add tests for external UI callback.
by Marvin June 27, 2017

June 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=31863 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [v3 2/2] user32/tests: Add test for GetWindowDisplayAffinity.
by Marvin June 26, 2017

June 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=31853 Your paranoid android. === w7u (32 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (32 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (64 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8

2 1

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Vincent Povirk June 26, 2017

June 26, 2017

This description is probably more complicated than it needs to be. If we want consistency with the GdipAddPathLine description, we can state it in terms of the newfigure value, which is ignored on input and TRUE on output. On Sat, Jun 24, 2017 at 11:26 AM, Clemens Tamme <clemens.tamme(a)gmail.com> wrote: > + * As an ellipse is always a new subpath the current subpath of the given path > + * cannot be continued afterwards. Additionally, the next thing added to the > + * path will be the start of the next subpath.

1 0

Re: [1/3] server: Add field for window display affinity.
by Alexandre Julliard June 26, 2017

June 26, 2017

Andrew Wesie <awesie(a)gmail.com> writes: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > include/wine/server_protocol.h | 9 ++++++--- > server/protocol.def | 3 +++ > server/request.h | 4 +++- > server/window.c | 4 ++++ > 4 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/include/wine/server_protocol.h b/include/wine/server_protocol.h > index d31579c..f442a94 100644 > --- a/include/wine/server_protocol.h > +++ b/include/wine/server_protocol.h > @@ -47,7 +47,7 @@ struct reply_header > > struct request_max_size > { > - int pad[16]; > + int pad[18]; > }; You can't change the request size. Also note that this is a generated file, updated by tools/make_requests. Do you have an app that uses this across processes? Otherwise you can probably simply store a local flag for now. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/5] msi/tests: Add tests for external UI callback.
by Hans Leidekker June 26, 2017

June 26, 2017

On Sun, 2017-06-25 at 21:13 -0500, Zebediah Figura wrote: > @@ -822,6 +823,8 @@ static UINT package_from_db(MSIHANDLE hdb, MSIHANDLE *handle) > CHAR szPackage[12]; > MSIHANDLE hPackage; > > + CoInitialize(NULL); > + > sprintf(szPackage, "#%u", hdb); > res = MsiOpenPackageA(szPackage, &hPackage); > if (res != ERROR_SUCCESS) > @@ -837,22 +840,39 @@ static UINT package_from_db(MSIHANDLE hdb, MSIHANDLE *handle) > return res; > } > > + CoUninitialize(); > + Why do you need this? > -static void create_test_file(const CHAR *name) > +static void create_file_data(LPCSTR name, LPCSTR data, DWORD size) > { > HANDLE file; > DWORD written; > > file = CreateFileA(name, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL); > ok(file != INVALID_HANDLE_VALUE, "Failure to open file %s\n", name); > - WriteFile(file, name, strlen(name), &written, NULL); > + if (file == INVALID_HANDLE_VALUE) > + return; > + > + WriteFile(file, data, strlen(data), &written, NULL); > WriteFile(file, "\n", strlen("\n"), &written, NULL); > + > + if (size) > + { > + SetFilePointer(file, size, NULL, FILE_BEGIN); > + SetEndOfFile(file); > + } > + > CloseHandle(file); > } You're not using this in this patch set.

3 3

Re: [PATCH 4/5] msi: Implement INSTALLMESSAGE_INITIALIZE and INSTALLMESSAGE_TERMINATE.
by Marvin June 26, 2017

June 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=31839 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH 3/5] msi: Send the correct UI messages upon calling MsiDoAction().
by Marvin June 26, 2017

June 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=31838 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH 1/5] msi/tests: Add tests for external UI callback.
by Marvin June 26, 2017

June 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=31836 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v3] configure: Avoid clobbering x18 on arm64 within wine
by André Hentschel June 26, 2017

June 26, 2017

1 0

Re: [v2 PATCH 1/2] d3drm: Added IDirect3DRMWrap stub
by Henri Verbeet June 26, 2017

June 26, 2017

On 26 June 2017 at 01:16, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_wrap_QueryInterface(IDirect3DRMWrap *iface, REFIID riid, void **out) > +{ > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMWrap) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + IDirect3DRMWrap_AddRef(iface); > + *out = iface; > + return S_OK; > + } > + > + WARN("%s not implemented, returning E_NOINTERFACE.\n", debugstr_guid(riid)); That's a little misleading. > + > + *out = NULL; > + return CLASS_E_CLASSNOTAVAILABLE; > +}

1 0

Re: [PATCH 5/5] msi: Implement UI messages in MsiOpenPackage().
by Hans Leidekker June 26, 2017

June 26, 2017

> @@ -1610,6 +1617,35 @@ UINT MSI_OpenPackageW(LPCWSTR szPackage, MSIPACKAGE **pPackage) > if (gszLogFile) > package->log_file = CreateFileW( gszLogFile, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); > + > + /* FIXME: when should these messages be sent? */ > + data_row = MSI_CreateRecord(3); > + /* FIXME: field 0 should be NULL */ > + MSI_RecordSetInteger(data_row, 1, 0); > + MSI_RecordSetInteger(data_row, 2, package->num_langids ? package->langids[0] : 0); > + MSI_RecordSetInteger(data_row, 3, msi_get_string_table_codepage(package->db->strings)); > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); > + > + info_row = MSI_CreateRecord(0); > + GetTimeFormatW(LOCALE_USER_DEFAULT, 0, NULL, time_format, timet, 100); > + GetDateFormatW(LOCALE_USER_DEFAULT, 0, NULL, date_format, datet, 100); > + LoadStringW(msi_hInstance, IDS_INFO_LOGGINGSTART, info_template, 1024); > + sprintfW(info_message, info_template, datet, timet); > + MSI_RecordSetStringW(info_row, 0, info_message); > + MSI_ProcessMessage(package, INSTALLMESSAGE_INFO|MB_ICONHAND, info_row); > + > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); > + > + productname = msi_dup_property(package->db, INSTALLPROPERTY_PRODUCTNAMEW); > + MSI_RecordSetInteger(data_row, 1, 1); > + MSI_RecordSetStringW(data_row, 2, productname); > + MSI_RecordSetStringW(data_row, 3, NULL); > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); Error handling.

1 0

Re: [PATCH 3/5] msi: Send the correct UI messages upon calling MsiDoAction().
by Hans Leidekker June 26, 2017

June 26, 2017

On Sun, 2017-06-25 at 21:13 -0500, Zebediah Figura wrote: > @@ -156,18 +158,12 @@ static const WCHAR szValidateProductID[] = > static const WCHAR szWriteEnvironmentStrings[] = > {'W','r','i','t','e','E','n','v','i','r','o','n','m','e','n','t','S','t','r','i','n','g','s',0}; > > -static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action) > +static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action, LPCWSTR description, LPCWSTR template) > { > - static const WCHAR Query_t[] = > - {'S','E','L','E','C','T',' ','*',' ','F','R','O','M',' ', > - '`','A','c','t','i','o', 'n','T','e','x','t','`',' ', > - 'W','H','E','R','E', ' ','`','A','c','t','i','o','n','`',' ','=', > - ' ','\'','%','s','\'',0}; > - MSIRECORD * row; > - > - row = MSI_QueryGetRecord( package->db, Query_t, action ); > - if (!row) > - return; > + MSIRECORD *row = MSI_CreateRecord(3); > + MSI_RecordSetStringW(row, 1, action); > + MSI_RecordSetStringW(row, 2, description); > + MSI_RecordSetStringW(row, 3, template); Please check the result of the MSI_CreateRecord call. > @@ -175,28 +171,21 @@ static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action) > static void ui_actioninfo(MSIPACKAGE *package, LPCWSTR action, BOOL start, > UINT rc) > { > - MSIRECORD * row; > - static const WCHAR template_s[]= > - {'A','c','t','i','o','n',' ','s','t','a','r','t',' ','%','s',':',' ', > - '%','s', '.',0}; > - static const WCHAR template_e[]= > - {'A','c','t','i','o','n',' ','e','n','d','e','d',' ','%','s',':',' ', > - '%','s', '.',' ','R','e','t','u','r','n',' ','v','a','l','u','e',' ', > - '%','i','.',0}; > + MSIRECORD *row; > + WCHAR template[1024]; > static const WCHAR format[] = > {'H','H','\'',':','\'','m','m','\'',':','\'','s','s',0}; > WCHAR message[1024]; > WCHAR timet[0x100]; > > GetTimeFormatW(LOCALE_USER_DEFAULT, 0, NULL, format, timet, 0x100); > - if (start) > - sprintfW(message,template_s,timet,action); > - else > - sprintfW(message,template_e,timet,action,rc); > - > - row = MSI_CreateRecord(1); > - MSI_RecordSetStringW(row,1,message); > - > + LoadStringW(msi_hInstance, start ? IDS_INFO_ACTIONSTART : IDS_INFO_ACTIONENDED, template, 1024); > + sprintfW(message, template, timet); > + > + row = MSI_CreateRecord(2); > + MSI_RecordSetStringW(row, 0, message); > + MSI_RecordSetStringW(row, 1, action); > + MSI_RecordSetInteger(row, 2, !rc); Same here.

1 0

Re: [PATCH 1/2] tools/winedbg: Add support for printing floating point registers.
by Alexandre Julliard June 26, 2017

June 26, 2017

Zebediah Figura <z.figura12(a)gmail.com> writes: > @@ -237,6 +237,14 @@ static struct dbg_internal_var be_x86_64_ctx[] = > {CV_AMD64_R13, "R13", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R13), dbg_itype_unsigned_long_int}, > {CV_AMD64_R14, "R14", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R14), dbg_itype_unsigned_long_int}, > {CV_AMD64_R15, "R15", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R15), dbg_itype_unsigned_long_int}, > + {CV_AMD64_ST0, "ST0", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[ 0]), dbg_itype_long_real}, > + {CV_AMD64_ST0+1, "ST1", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[10]), dbg_itype_long_real}, > + {CV_AMD64_ST0+2, "ST2", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[20]), dbg_itype_long_real}, > + {CV_AMD64_ST0+3, "ST3", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[30]), dbg_itype_long_real}, > + {CV_AMD64_ST0+4, "ST4", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[40]), dbg_itype_long_real}, > + {CV_AMD64_ST0+5, "ST5", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[50]), dbg_itype_long_real}, > + {CV_AMD64_ST0+6, "ST6", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[60]), dbg_itype_long_real}, > + {CV_AMD64_ST0+7, "ST7", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[70]), dbg_itype_long_real}, This doesn't build: ../../../wine/include/winnt.h:757:42: error: ‘CONTEXT {aka struct _CONTEXT}’ has no member named ‘FloatSave’ ../../../wine/programs/winedbg/be_x86_64.c:240:53: note: in expansion of macro ‘FIELD_OFFSET’ -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] tools/winedbg: Add support for printing SSE (XMM) registers.
by Alexandre Julliard June 26, 2017

June 26, 2017

Zebediah Figura <z.figura12(a)gmail.com> writes: > + for (cnt = 0; cnt < 8; cnt++) > + { > + dbg_printf( " xmm%u: uint=%016llx%016llx", cnt, > + xmm_area->XmmRegisters[cnt].High, xmm_area->XmmRegisters[cnt].Low ); Please avoid %ll formats. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advpack: Improve DelNode and tests
by Alexandre Julliard June 26, 2017

June 26, 2017

"katahiromz ." <katayama.hirofumi.mz(a)gmail.com> writes: > @@ -327,6 +328,149 @@ done: > return HRESULT_FROM_WIN32(dwLastError); > } > > +static HRESULT DELNODE_delete_file(LPWSTR fname) > +{ > + if (GetFileAttributesW(fname) != INVALID_FILE_ATTRIBUTES) > + { > + SetFileAttributesW(fname, FILE_ATTRIBUTE_NORMAL); > + if (DeleteFileW(fname)) > + { > + return S_OK; > + } > + } There shouldn't be any reason to retrieve attributes first. > + /* generate a path with wildcard suitable for iterating */ > + fname_len = lstrlenW(fname); > + if (fname_len && fname[fname_len - 1] != L'\\') > + { > + fname[fname_len++] = L'\\'; Please don't use wide character constants. > C_SRCS = \ > advpack.c \ > + delnode.c \ > files.c \ > install.c Please don't create a new file, the tests should go into files.c. > +static const NODEW s_nodesW[] = > +{ > + { L"dir1", TRUE }, /* 0 */ > + { L"dir1\\dir2", TRUE }, /* 1 */ > + { L"dir1\\dir2\\file1", FALSE }, /* 2 */ You can't use wide character strings in Wine. > +START_TEST(delnode) > +{ > + s_hAdvPack = LoadLibraryA("advpack.dll"); > + if (s_hAdvPack == NULL) > + { > + skip("unable to load advpack.dll\n"); > + return; > + } This shouldn't be necessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] configure: Avoid clobbering x18 on arm64 when building with clang
by Martin Storsjö June 26, 2017

June 26, 2017

On Sat, 24 Jun 2017, André Hentschel wrote: > Am 21.06.2017 um 12:39 schrieb Martin Storsjo: >> On aarch64/arm64, clang/LLVM feels free to use x18 for normal code >> generation on linux (while the register is reserved on iOS/darwin). >> For windows/arm64, this register must not be clobbered. >> >> If targeting arm64, check for the clang cflags that allows this >> register to be left untouched. >> >> This makes sure that wine for aarch64 built with clang doesn't >> crash immediately on startup. >> >> Signed-off-by: Martin Storsjo <martin(a)martin.st> >> --- >> Now with the sign-off included, which was forgotten in v1. >> --- >> configure.ac | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/configure.ac b/configure.ac >> index 7ae29f7..5b5a1d8 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -179,6 +179,11 @@ case $host in >> CFLAGS="$CFLAGS -marm" >> AC_SUBST(TARGETFLAGS,"-marm") >> ;; >> + aarch64*) >> + # Clang needs these flags in order not to clobber the x18 register >> + WINE_TRY_CFLAGS([-Xclang -target-feature -Xclang +reserve-x18], >> + [CFLAGS="$CFLAGS -Xclang -target-feature -Xclang +reserve-x18"]) >> + ;; >> i[[3456789]]86*) >> enable_win16=${enable_win16:-yes} >> ;; >> > > I think it's worthwhile adding it > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> FWIW, in case Alexandre also reconsiders merging it since you think it's worthwhile adding it - I reposted a v3, using the gcc compatible flag syntax and with an improved commit message. // Martin

1 0

Re: [4/6] windowscodecs: Add initial implementation of IWICMetadataQueryReader::GetMetadataByName. (v2)
by Dmitry Timoshkov June 25, 2017

June 25, 2017

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > +static const WCHAR *map_shortname_to_schema(const GUID *format, const WCHAR *name) > +{ > + UINT i; > + > + /* It appears that the only metadata formats > + * that support schemas are xmp and xmpstruct. > ++ */ Oops. I hope that a typo in the comment won't require another resend. Alexandre, could you please remove extra '+' in the comment above if the patch gets accepted? Thanks. -- Dmitry.

1 0

Re: [6/7] windowscodecs: Add some tests for IWICMetadataQueryReader.
by Vincent Povirk June 25, 2017

June 25, 2017

> + if (CompareStringW(LOCALE_NEUTRAL, NORM_IGNORECASE, queryW, len-1, name, len-1) == CSTR_EQUAL && decoder_data[j].query[len - 1] != 0) > + { > + if (winetest_debug > 1) > + trace("query: %s\n", wine_dbgstr_w(queryW + len - 1)); > + PropVariantInit(&value); Shouldn't this be PropVariantClear?

2 1

Re: [5/7] windowscodecs: Add initial implementation of IWICMetadataQueryReader::GetMetadataByName.
by Vincent Povirk June 25, 2017

June 25, 2017

> + if (vt == VT_CLSID) > + { > + id->u.puuid = CoTaskMemAlloc(sizeof(GUID)); > + if (!id->u.puuid) return E_OUTOFMEMORY; > + > + hr = UuidFromStringW(next_token.u.bstrVal, id->u.puuid); > + } > + else > + hr = PropVariantChangeType(id, &next_token, 0, vt); > + PropVariantClear(&next_token); > + if (hr != S_OK) > + { > + PropVariantClear(id); > + PropVariantClear(schema); > + return hr; > + } > + > + id->vt = vt; Assigning the vt at the end of this is a bit strange. I don't know any situation here where PropVariantChangeType will succeed without giving you the requested vt, and if it did, changing it would be unsafe. I can see you need it in the VT_CLSID case, but then it would make more sense to set it there. In fact, this version will leak memory if UuidFromStringW fails. + if (!elem.len) break; When can this happen? + new_value.vt = VT_UNKNOWN; + hr = MetadataQueryReader_CreateInstance(This->block, root, (IWICMetadataQueryReader **)&new_value.u.punkVal); I think you need to clear new_value first here?

2 1

Re: [PATCH v2] configure: Avoid clobbering x18 on arm64 when building with clang
by Alexandre Julliard June 24, 2017

June 24, 2017

Martin Storsjo <martin(a)martin.st> writes: > On aarch64/arm64, clang/LLVM feels free to use x18 for normal code > generation on linux (while the register is reserved on iOS/darwin). > For windows/arm64, this register must not be clobbered. This would have to be made the default system-wide, fixing it on the Wine side isn't good enough since we call system libraries. -- Alexandre Julliard julliard(a)winehq.org

3 7

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Vincent Povirk June 24, 2017

June 24, 2017

+ * GenericError If conversion from arc to bezier curve fails When would this happen? Best I can tell, it isn't supposed to be possible, and the check is just coding defensively. + * Ok If ecerything works out as expected Typo.

2 1

Re: [3/3] user32/tests: Add test for GetWindowDisplayAffinity.
by Marvin June 23, 2017

June 23, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=31812 Your paranoid android. === w7u (32 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (32 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (64 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8

2 1

Re: [PATCH 2/2] d3drm: Added IDirect3DRMWrap stub
by Henri Verbeet June 23, 2017

June 23, 2017

On 23 June 2017 at 15:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_wrap_QueryInterface(IDirect3DRMWrap *iface, REFIID riid, void **out) > +{ > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMWrap) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + IDirect3DRMWrap_AddRef(iface); > + *out = iface; > + return S_OK; > + } > + > + WARN("%s not implemented, returning E_NOINTERFACE.\n", debugstr_guid(riid)); > + > + *out = NULL; > + return E_NOINTERFACE; > +} Likewise, while E_NOINTERFACE would normally be the expected value, that's not a given with d3drm. > +static ULONG WINAPI d3drm_wrap_Release(IDirect3DRMWrap *iface) > +{ > + struct d3drm_wrap *wrap = impl_from_IDirect3DRMWrap(iface); > + ULONG refcount = InterlockedDecrement(&wrap->ref); > + > + TRACE("%p decreasing refcount to %u.\n", iface, refcount); > + > + if (!refcount) > + { > + d3drm_object_cleanup((IDirect3DRMObject *)iface, &wrap->obj); > + //IDirect3DRM_Release(mesh->d3drm); C99 comment. > @@ -109,10 +109,10 @@ static void test_class_name_(unsigned int line, IDirect3DRMObject *object, const > ok_(__FILE__, line)(hr == D3DRM_OK, "Failed to get classname size, hr %#x.\n", hr); > ok_(__FILE__, line)(size == strlen(name) + 1, "wrong size: %u\n", size); > > - size = 1; > + size = size2 = *name ? 1 : 0; I think "!!*name" would be more obvious, but don't care strongly.

1 0

Re: [PATCH 1/2] d3drm: Added IDirect3DRMAnimation stub
by Henri Verbeet June 23, 2017

June 23, 2017

On 23 June 2017 at 15:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_animation2_QueryInterface(IDirect3DRMAnimation2 *iface, REFIID riid, void **out) > +{ > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation2(iface); > + > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMAnimation) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + *out = &animation->IDirect3DRMAnimation_iface; > + } > + else if (IsEqualGUID(riid, &IID_IDirect3DRMAnimation2)) > + { > + *out = &animation->IDirect3DRMAnimation2_iface; > + } > + else > + { > + *out = NULL; > + WARN("%s not implemented, returning CLASS_E_CLASSNOTAVAILABLE.\n", debugstr_guid(riid)); > + return CLASS_E_CLASSNOTAVAILABLE; I suspect CLASS_E_CLASSNOTAVAILABLE is correct, since other d3drm interfaces are unusual like that as well, but it would be good to have that backed up by the tests.

1 0

Re: [PATCH 1/4] d3drm: Make it possible to create material objects with CreateObject().
by Henri Verbeet June 22, 2017

June 22, 2017

On 21 June 2017 at 14:39, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index fc19b97b8b..6c2903226a 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1404,6 +1404,8 @@ static void test_object(void) > { &CLSID_CDirect3DRMFrame, &IID_IDirect3DRMFrame2 }, > { &CLSID_CDirect3DRMFrame, &IID_IDirect3DRMFrame3 }, > { &CLSID_CDirect3DRMLight, &IID_IDirect3DRMLight }, > + { &CLSID_CDirect3DRMMaterial, &IID_IDirect3DRMMaterial }, > + { &CLSID_CDirect3DRMMaterial, &IID_IDirect3DRMMaterial2 }, > }; > IDirect3DRM *d3drm1; > IDirect3DRM2 *d3drm2; > @@ -1429,7 +1431,8 @@ static void test_object(void) > { > BOOL takes_ref = IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMMeshBuilder) || > IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMFrame) || > - IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMLight); > + IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMLight) || > + IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMMaterial); If there are going to be more of these, it probably makes sense to just include the information as a field in tests[].

2 1

Re: winhttp: Reset content length when a redirect creates a new connection.
by Alistair Leslie-Hughes June 22, 2017

June 22, 2017

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>

1 0

Re: [PATCH 4/4] d3drm: Make it possible to create meshes with CreateObject().
by Henri Verbeet June 22, 2017

June 22, 2017

On 21 June 2017 at 14:39, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > diff --git a/dlls/d3drm/d3drm_private.h b/dlls/d3drm/d3drm_private.h > index 1b00e1a36d..af79b43292 100644 > --- a/dlls/d3drm/d3drm_private.h > +++ b/dlls/d3drm/d3drm_private.h > @@ -147,6 +147,30 @@ struct d3drm_mesh_builder > DWORD *material_indices; > }; > > +struct mesh_group > +{ > + unsigned nb_vertices; > + D3DRMVERTEX* vertices; > + unsigned nb_faces; > + unsigned vertex_per_face; > + DWORD face_data_size; > + unsigned* face_data; > + D3DCOLOR color; > + IDirect3DRMMaterial2* material; > + IDirect3DRMTexture3* texture; > +}; Not new, but misleading "*" placement.

1 0

Re: [PATCH 1/2] Update make_specfiles to handle ucrtbase's _o_* functions
by Alexandre Julliard June 22, 2017

June 22, 2017

Max Qian <public(a)maxqia.com> writes: > Helps fix https://bugs.winehq.org/show_bug.cgi?id=38960 > I'm 99% sure that all of them redirect to the non _o_ functions, > and this is required to get Steam working with Windows <=7 mode. I expect that there's a reason behind the _o_ functions, and it's probably worth figuring out. In any case, you don't want to have a dll forward to itself, you should link to the same target function instead (assuming that's really what the _o_ functions are supposed to do). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] api-ms-win-core-crt-l1-1-0: Add dll.
by Alexandre Julliard June 22, 2017

June 22, 2017

Andrey Gusev <andrey.goosev(a)gmail.com> writes: > +@ cdecl -arch=i386 -ret64 _ftol2() MSVCRT__ftol > +@ cdecl -arch=i386 -ret64 _ftol2_sse() MSVCRT__ftol This can't work, the function isn't in this dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] oleaut32: check return code of Currency2Integer (Coverity)
by Dmitry Timoshkov June 22, 2017

June 22, 2017

Marcus Meissner <marcus(a)jet.franken.de> wrote: > HRESULT WINAPI VarI1FromCy(CY cyIn, signed char* pcOut) > { > LONG i = I1_MAX + 1; > + HRESUTL hr; > > - VarI4FromCy(cyIn, &i); > - return _VarI1FromI4(i, pcOut); > + hr = VarI4FromCy(cyIn, &i); > + > + if (SUCCEEDED(hr)) > + hr = _VarI1FromI4(i, pcOut); > + return hr; > } I guess that this change makes initialization of 'i' redundant. Here and in remaining cases. Probably needs a test case though to make sure which behaviour is more correct. -- Dmitry.

1 0

Re: rsaenh: Avoid double 'va_end(args)' in case of a premature loop termination.
by Sebastian Lackner June 22, 2017

June 22, 2017

On 21.06.2017 10:24, Dmitry Timoshkov wrote: > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > --- > dlls/rsaenh/mpi.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/rsaenh/mpi.c b/dlls/rsaenh/mpi.c > index 03e31023e6..dcf6ddf112 100644 > --- a/dlls/rsaenh/mpi.c > +++ b/dlls/rsaenh/mpi.c > @@ -2365,10 +2365,7 @@ int mp_init_multi(mp_int *mp, ...) > succeeded in init-ing, then return error. > */ > va_list clean_args; > - > - /* end the current list */ > - va_end(args); > - > + > /* now start cleaning up */ > cur_arg = mp; > va_start(clean_args, mp); > @@ -2381,6 +2378,7 @@ int mp_init_multi(mp_int *mp, ...) > break; > } > n++; > + va_end(args); Doesn't this change make it even worse? Whats the purpose of calling va_end() when the enumeration isn't finished yet? > cur_arg = va_arg(args, mp_int*); > } > va_end(args); >

2 3

Re: [11/17] windowscodecs: Simplify a bit comparison of two PROPVARIANTs.
by Vincent Povirk June 22, 2017

June 22, 2017

I'm not sure the point of changing this when we're just going to replace it with PropVariantCompareEx.

2 1

Re: [13/17] windowscodecs: Use PropVariantCompareEx to compare metadata items.
by Vincent Povirk June 22, 2017

June 22, 2017

This breaks the windowscodecs/metadata test here. fixme:propsys:PropVariantCompareEx vartype 30 not handled metadata.c:382: Test failed: GetValue failed, hr=88982f40 fixme:propsys:PropVariantCompareEx vartype 30 not handled metadata.c:388: Test failed: GetValue failed, hr=88982f40 metadata.c:389: Test failed: unexpected vt: 30 wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed13c05 (thread 0009), starting debugger...

2 1

Re: [v4 1/4] d3dx9: Remove redundant parameter size check in set_constants().
by Matteo Bruni June 21, 2017

June 21, 2017

2017-06-19 11:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v4: > - added assert() for parameter size. > --- > dlls/d3dx9_36/preshader.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 2785ca3..76d6de9 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -1178,11 +1178,6 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > param_offset = i + j * info.major; > else > param_offset = i * info.minor + j; > - if (param_offset * sizeof(unsigned int) >= param->bytes) > - { > - WARN("Parameter data is too short, name %s, component %u.\n", debugstr_a(param->name), i); > - break; > - } > out[offset] = data[param_offset]; > } > } > @@ -1303,6 +1298,11 @@ static HRESULT merge_const_set_entries(struct d3dx_const_tab *const_tab, > memmove(&const_tab->const_set[index + 1], &const_tab->const_set[i], > sizeof(*const_tab->const_set) * (const_tab->const_set_count - i)); > const_tab->const_set_count -= i - index - 1; > + assert(param->bytes >= table_info[first_const->table].component_size > + * first_const->element_count > + * (first_const->direct_copy ? get_reg_components(first_const->table) > + * first_const->register_count > + : first_const->param->rows * first_const->param->columns)); I don't think an assert() is correct here. You are comparing parameter size, which eventually depends on the effect data, with the constant size, which comes from the constant table and thus again the effect data. In general we shouldn't assert on invalid input data. Also by putting the assert() in merge_const_set_entries() you're not checking the non-array, non-struct constants. Am I missing something? Is there something else that would trigger if e.g. a 4x4 matrix constants gets matched with a 3x4 parameter?

2 4

Re: [PATCH 1/2] quartz: Restore a comment explaining mediatime.
by Matteo Bruni June 21, 2017

June 21, 2017

2017-06-19 21:15 GMT+02:00 Zebediah Figura <z.figura12(a)gmail.com>: > This comment was removed by 0a6f11c8, possibly by accident. > The usage of the term "media time" here is confusing, both > because it does not describe time (or any meaningful unit) > and also because it conflicts with the normal definition of > "media time", viz. length in number of samples. > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/quartz/quartz_private.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h > index 7cad3a75640..a9855e95acd 100644 > --- a/dlls/quartz/quartz_private.h > +++ b/dlls/quartz/quartz_private.h > @@ -33,6 +33,7 @@ > #include "wine/strmbase.h" > #include "wine/list.h" > > +/* see IAsyncReader::Request on MSDN for the explanation of this */ > #define MEDIATIME_FROM_BYTES(x) ((LONGLONG)(x) * 10000000) > #define SEC_FROM_MEDIATIME(time) ((time) / 10000000) > #define BYTES_FROM_MEDIATIME(time) SEC_FROM_MEDIATIME(time) Is it reasonable to put some short explanation right here (i.e. removing the middle man) instead?

2 1

Re: [v4 4/4] d3dx9: Move transpose 'if' outside of the inner loop in set_constants().
by Matteo Bruni June 21, 2017

June 21, 2017

2017-06-19 11:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v4: > - updated to handle incomplete row of transposed matrix accordingly. > --- > dlls/d3dx9_36/preshader.c | 26 ++++++++++---------------- > 1 file changed, 10 insertions(+), 16 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 9a2ecfa..39bd483 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -1138,7 +1138,6 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > unsigned int table = const_set->table; > struct d3dx_parameter *param = const_set->param; > unsigned int element, i, j, start_offset; > - unsigned int param_offset; > struct const_upload_info info; > unsigned int *data = param->data; > enum pres_value_type param_type; > @@ -1178,24 +1177,19 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > > /* Store reshaped but (possibly) not converted yet data temporarily in the same constants buffer. > * All the supported types of parameters and table values have the same size. */ > - for (i = 0; i < info.major_count; ++i) > - { > - for (j = 0; j < info.minor; ++j) > - { > - if (info.transpose) > - param_offset = i + j * info.major; > - else > - param_offset = i * info.minor + j; > - out[i * info.major_stride + j] = data[param_offset]; > - } > - } > if (info.transpose) > { > + for (i = 0; i < info.major_count; ++i) > + for (j = 0; j < info.minor; ++j) > + out[i * info.major_stride + j] = data[i + j * info.major]; > + > for (j = 0; j < info.minor_remainder; ++j) > - { > - param_offset = i + j * info.major; > - out[i * info.major_stride + j] = data[param_offset]; > - } > + out[i * info.major_stride + j] = data[i + j * info.major]; } Accidental backspace? ;)

1 0

Re: [PATCH v2 2/4] winemp3.acm: Disallow operations encoding to MPEG.
by Andrew Eikum June 21, 2017

June 21, 2017

I'd like this more with tests, showing what the application was doing and how Wine failed its expectations but now meets them. Andrew On Fri, Jun 09, 2017 at 06:08:28PM -0500, Zebediah Figura wrote: > Since the winemp3 driver is currently decode-only, and most Windows > versions do not ship by default with a driver capable of encoding > to mpeg3, we should report the driver's capabilities accordingly. > > v2: remove failing tests > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/winemp3.acm/mpegl3.c | 80 ++++++++++------------------------------------- > 1 file changed, 17 insertions(+), 63 deletions(-) > > diff --git a/dlls/winemp3.acm/mpegl3.c b/dlls/winemp3.acm/mpegl3.c > index cc6008da59e..c5d71bba524 100644 > --- a/dlls/winemp3.acm/mpegl3.c > +++ b/dlls/winemp3.acm/mpegl3.c > @@ -258,10 +258,13 @@ static LRESULT MPEG3_StreamOpen(PACMDRVSTREAMINSTANCE adsi) > mpg123_param(aad->mh, MPG123_ADD_FLAGS, MPG123_IGNORE_INFOFRAME, 0); > #endif > } > - /* no encoding yet > else if (adsi->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM && > - adsi->pwfxDst->wFormatTag == WAVE_FORMAT_MPEGLAYER3) > - */ > + (adsi->pwfxDst->wFormatTag == WAVE_FORMAT_MPEGLAYER3 || > + adsi->pwfxDst->wFormatTag == WAVE_FORMAT_MPEG)) > + { > + WARN("Encoding to MPEG is not supported\n"); > + goto theEnd; > + } > else goto theEnd; > MPEG3_Reset(adsi, aad); > > @@ -736,54 +739,19 @@ static LRESULT MPEG3_FormatTagDetails(PACMFORMATTAGDETAILSW aftd, DWORD dwQuery) > case 1: > aftd->dwFormatTag = WAVE_FORMAT_MPEGLAYER3; > aftd->cbFormatSize = sizeof(MPEGLAYER3WAVEFORMAT); > - aftd->cStandardFormats = NUM_MPEG3_FORMATS; > + aftd->cStandardFormats = 0; > lstrcpyW(aftd->szFormatTag, szMpeg3); > break; > case 2: > aftd->dwFormatTag = WAVE_FORMAT_MPEG; > aftd->cbFormatSize = sizeof(MPEG1WAVEFORMAT); > - aftd->cStandardFormats = NUM_MPEG3_FORMATS; > + aftd->cStandardFormats = 0; > lstrcpyW(aftd->szFormatTag, szMpeg); > break; > } > return MMSYSERR_NOERROR; > } > > -static void fill_in_mp3(unsigned cbwfx, WAVEFORMATEX* wfx, unsigned bit_rate) > -{ > - MPEGLAYER3WAVEFORMAT* mp3wfx = (MPEGLAYER3WAVEFORMAT*)wfx; > - > - wfx->nAvgBytesPerSec = bit_rate / 8; > - if (cbwfx >= sizeof(WAVEFORMATEX)) > - wfx->cbSize = sizeof(MPEGLAYER3WAVEFORMAT) - sizeof(WAVEFORMATEX); > - if (cbwfx >= sizeof(MPEGLAYER3WAVEFORMAT)) > - { > - mp3wfx->wID = MPEGLAYER3_ID_MPEG; > - mp3wfx->fdwFlags = MPEGLAYER3_FLAG_PADDING_OFF; > - mp3wfx->nBlockSize = (bit_rate * 144) / wfx->nSamplesPerSec; > - mp3wfx->nFramesPerBlock = 1; > - mp3wfx->nCodecDelay = 0x0571; > - } > -} > - > -static void fill_in_mpeg(unsigned cbwfx, WAVEFORMATEX* wfx, unsigned bit_rate) > -{ > - MPEG1WAVEFORMAT* mp3wfx = (MPEG1WAVEFORMAT*)wfx; > - > - wfx->nAvgBytesPerSec = bit_rate / 8; > - if (cbwfx >= sizeof(WAVEFORMATEX)) > - wfx->cbSize = sizeof(MPEG1WAVEFORMAT) - sizeof(WAVEFORMATEX); > - if (cbwfx >= sizeof(MPEG1WAVEFORMAT)) > - { > - mp3wfx->fwHeadLayer = ACM_MPEG_LAYER3; > - mp3wfx->dwHeadBitrate = wfx->nAvgBytesPerSec * 8; > - mp3wfx->fwHeadMode = ACM_MPEG_JOINTSTEREO; > - mp3wfx->fwHeadModeExt = 0xf; > - mp3wfx->wHeadEmphasis = 1; > - mp3wfx->fwHeadFlags = ACM_MPEG_ID_MPEG1; > - } > -} > - > /*********************************************************************** > * MPEG3_FormatDetails > * > @@ -814,16 +782,8 @@ static LRESULT MPEG3_FormatDetails(PACMFORMATDETAILSW afd, DWORD dwQuery) > break; > case WAVE_FORMAT_MPEGLAYER3: > case WAVE_FORMAT_MPEG: > - if (afd->dwFormatIndex >= NUM_MPEG3_FORMATS) return ACMERR_NOTPOSSIBLE; > - afd->pwfx->nChannels = MPEG3_Formats[afd->dwFormatIndex].nChannels; > - afd->pwfx->nSamplesPerSec = MPEG3_Formats[afd->dwFormatIndex].rate; > - afd->pwfx->wBitsPerSample = MPEG3_Formats[afd->dwFormatIndex].nBits; > - afd->pwfx->nBlockAlign = 1; > - if (afd->dwFormatTag == WAVE_FORMAT_MPEGLAYER3) > - fill_in_mp3(afd->cbwfx, afd->pwfx, 192000); > - else > - fill_in_mpeg(afd->cbwfx, afd->pwfx, 192000); > - break; > + WARN("Encoding to MPEG is not supported\n"); > + return ACMERR_NOTPOSSIBLE; > default: > WARN("Unsupported tag %08x\n", afd->dwFormatTag); > return MMSYSERR_INVALPARAM; > @@ -856,18 +816,15 @@ static LRESULT MPEG3_FormatSuggest(PACMDRVFORMATSUGGEST adfs) > adfs->pwfxDst->nChannels = adfs->pwfxSrc->nChannels; > if (!(adfs->fdwSuggest & ACM_FORMATSUGGESTF_NSAMPLESPERSEC)) > adfs->pwfxDst->nSamplesPerSec = adfs->pwfxSrc->nSamplesPerSec; > - > if (!(adfs->fdwSuggest & ACM_FORMATSUGGESTF_WBITSPERSAMPLE)) > - { > - if (adfs->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM) > - adfs->pwfxDst->wBitsPerSample = 4; > - else > - adfs->pwfxDst->wBitsPerSample = 16; > - } > + adfs->pwfxDst->wBitsPerSample = 16; > if (!(adfs->fdwSuggest & ACM_FORMATSUGGESTF_WFORMATTAG)) > { > if (adfs->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM) > - adfs->pwfxDst->wFormatTag = WAVE_FORMAT_MPEGLAYER3; > + { > + WARN("Encoding to MPEG is not supported\n"); > + return ACMERR_NOTPOSSIBLE; > + } > else > adfs->pwfxDst->wFormatTag = WAVE_FORMAT_PCM; > } > @@ -883,12 +840,9 @@ static LRESULT MPEG3_FormatSuggest(PACMDRVFORMATSUGGEST adfs) > adfs->pwfxDst->nAvgBytesPerSec = adfs->pwfxDst->nSamplesPerSec * adfs->pwfxDst->nBlockAlign; > break; > case WAVE_FORMAT_MPEG: > - adfs->pwfxDst->nBlockAlign = 1; > - fill_in_mpeg(adfs->cbwfxDst, adfs->pwfxDst, 192000); > - break; > case WAVE_FORMAT_MPEGLAYER3: > - adfs->pwfxDst->nBlockAlign = 1; > - fill_in_mp3(adfs->cbwfxDst, adfs->pwfxDst, 192000); > + WARN("Encoding to MPEG is not supported\n"); > + return ACMERR_NOTPOSSIBLE; > break; > default: > FIXME("\n"); > -- > 2.13.0 > > >

2 4

Re: user.exe16: Fix memory leaks in cases when HeapReAlloc fails.
by Alexandre Julliard June 21, 2017

June 21, 2017

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -3286,7 +3289,8 @@ DWORD WINAPI FormatMessage16( > } > talloced = strlen(target)+1; > if (nSize && talloced<nSize) { > - target = HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,target,nSize); > + LPSTR new_target = HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,target,nSize); > + if (new_target) target = new_target; You could probably remove it entirely. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] gdi32: Don't write EMR_EXTSELECTCLIPRGN to emf file on SelectClipPath call
by Dmitry Timoshkov June 21, 2017

June 21, 2017

Piotr Caban <piotr(a)codeweavers.com> wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdi32/enhmfdrv/dc.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) It shouldn't be too hard to add an appropriate test case. -- Dmitry.

1 0

Re: [PATCH 1/5] cryptnet: label ordinals
by Alexandre Julliard June 21, 2017

June 21, 2017

Austin English <austinenglish(a)gmail.com> writes: > @@ -1,7 +1,7 @@ > -@ stub CertDllVerifyCTLUsage > -@ stdcall CertDllVerifyRevocation(long long long ptr long ptr ptr) > -@ stub CryptnetWlxLogoffEvent > -@ stub LdapProvOpenStore > +1 stub CertDllVerifyCTLUsage > +2 stdcall CertDllVerifyRevocation(long long long ptr long ptr ptr) > +3 stub CryptnetWlxLogoffEvent > +4 stub LdapProvOpenStore I see no evidence that these should have ordinals, they differ across versions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] api-ms-win-core-crt-l1-1-0: Add dll.
by Alexandre Julliard June 21, 2017

June 21, 2017

Andrey Gusev <andrey.goosev(a)gmail.com> writes: > @@ -53,6 +53,13 @@ my @dll_groups = > ], > [ > "ucrtbase", > + "msvcr120", > + "msvcrt", > + "ntdll", > + "api-ms-win-core-crt-l1-1-0", You can't have all these dlls forward to ucrtbase. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ole32: Add stub for OleGetIconOfFile.
by Dmitry Timoshkov June 21, 2017

June 21, 2017

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > +HGLOBAL WINAPI OleGetIconOfFile(LPOLESTR path, BOOL use_file_as_label) > +{ > + FIXME("(%p, %d), stub!\n", path, use_file_as_label); > + return NULL; > +} Probably 'path' should be printed with debugstr_w(), > +@ stdcall OleGetIconOfFile(ptr long) ... and argument type should be 'wstr' instead of 'ptr'. -- Dmitry.

2 1

Re: [06/17] propsys: Add support for VT_LPSTR and VT_LPWSTR to PropVariantCompareEx. (v2)
by Alexandre Julliard June 20, 2017

June 20, 2017

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -112,6 +116,15 @@ static HRESULT PROPVAR_ConvertNumber(REFPROPVARIANT pv, int dest_bits, > src_signed = FALSE; > *res = 0; > break; > + case VT_LPSTR: > + *res = strtoll(pv->u.pszVal, NULL, 0); > + src_signed = *res < 0; > + break; > + case VT_LPWSTR: > + case VT_BSTR: > + *res = strtolW(pv->u.pwszVal, NULL, 0); > + src_signed = *res < 0; > + break; This could probably use a little error checking. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 07/12] server: Introduce default async queue that's used if async is not explicitly queued in fd op.
by Alexandre Julliard June 20, 2017

June 20, 2017

Jacek Caban <jacek(a)codeweavers.com> writes: > Although (at least now) all read and write implementations always queue > async on success, it's not the case for ioctl. I think we should allow > simple ioctls without pending results to not care about explicitly > handling async objects, but those still need a queued async for proper > result reporting. We currently don't set events, queue APCs nor send > completion for them. > > My initial thought was to make async object work better without > associated queue, but that leads to problems with references from an > async to fd. I think that would be better than creating a dummy queue. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [17/17] windowscodecs: Add some tests for IWICMetadataQueryReader.
by Marvin June 20, 2017

June 20, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=31731 Your paranoid android. === w8 (32 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} === w864 (32 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} === w1064 (32 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} === w864 (64 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} === w1064 (64 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36}

2 1

Re: [PATCH] gdiplus: Implement triangular line caps in widened paths.
by Clemens Tamme June 19, 2017

June 19, 2017

Great, thanks for letting me know! Am 19.06.2017 22:20 schrieb "Marvin" <testbot(a)winehq.org>: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Committed". > > This means that your patch has been approved, and committed to the > main git tree. Congratulations! >

1 0

Re: [PATCH] shell32: Initialize members in SHGetFileInfo.
by Alexandre Julliard June 19, 2017

June 19, 2017

"katahiromz ." <katayama.hirofumi.mz(a)gmail.com> writes: > From ca0631aa8766b91cc0183adc9f9f1fe99e058af0 Mon Sep 17 00:00:00 2001 > From: Katayama Hirofumi MZ <katayama.hirofumi.mz(a)gmail.com> > Date: Mon, 19 Jun 2017 13:02:33 +0900 > Subject: [PATCH] shell32: Initialize members in SHGetFileInfo. > > This patch kills some failures in shell32_winetest:shlfileop by > initializing some members of SHFILEINFO in SHGetFileInfoA/W. > > Tested on ReactOS r75083. > > before: shlfileop: 790 tests executed (0 marked as todo, 31 failures), 0 > skipped. > after: shlfileop: 790 tests executed (0 marked as todo, 22 failures), 0 > skipped. > > Signed-off-by: Katayama Hirofumi MZ <katayama.hirofumi.mz(a)gmail.com> > --- > dlls/shell32/shell32_main.c | 5 +++++ > 1 file changed, 5 insertions(+) You'd need to update the corresponding todos, but the patch is also causing failures: ../../../tools/runtest -q -P wine -T ../../.. -M shell32.dll -p shell32_test.exe.so shlfileop && touch shlfileop.ok shlfileop.c:200: Test succeeded inside todo block: SHGetFileInfoA('' | 0) did not clear hIcon shlfileop.c:201: Test succeeded inside todo block: SHGetFileInfoA('' | 0) did not clear szDisplayName[0] shlfileop.c:202: Test succeeded inside todo block: SHGetFileInfoA('' | 0) did not clear szTypeName[0] shlfileop.c:203: Test failed: SHGetFileInfoA('' | 0) should not clear iIcon shlfileop.c:238: Test succeeded inside todo block: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) did not clear hIcon shlfileop.c:239: Test succeeded inside todo block: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) did not clear szDisplayName[0] shlfileop.c:240: Test succeeded inside todo block: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) did not clear szTypeName[0] shlfileop.c:241: Test failed: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) should not clear iIcon shlfileop.c:386: Test succeeded inside todo block: SHGetFileInfoA(CSIDL_DESKTOP, SHGFI_SYSICONINDEX|SHGFI_SMALLICON|SHGFI_PIDL) did not clear hIcon shlfileop.c:387: Test succeeded inside todo block: SHGetFileInfoA(CSIDL_DESKTOP, SHGFI_SYSICONINDEX|SHGFI_SMALLICON|SHGFI_PIDL) did not clear szTypeName[0] shlfileop.c:412: Test succeeded inside todo block: SHGetFileInfoW(CSIDL_DESKTOP, SHGFI_SYSICONINDEX|SHGFI_SMALLICON|SHGFI_PIDL) did not clear hIcon shlfileop.c:713: Tests skipped: Test would show a dialog box Makefile:739: recipe for target 'shlfileop.ok' failed make: *** [shlfileop.ok] Error 11 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2 4/5] msi: Don't reimplement record formatting.
by Hans Leidekker June 19, 2017

June 19, 2017

On Sun, 2017-06-18 at 21:53 -0500, Zebediah Figura wrote: > diff --git a/dlls/msi/package.c b/dlls/msi/package.c > index eae01e0..f16b1dc 100644 > --- a/dlls/msi/package.c > +++ b/dlls/msi/package.c > @@ -1709,8 +1709,8 @@ INT MSI_ProcessMessage( MSIPACKAGE *package, INSTALLMESSAGE eMessageType, MSIREC > static const WCHAR szSetProgress[] = {'S','e','t','P','r','o','g','r','e','s','s',0}; > static const WCHAR szActionText[] = {'A','c','t','i','o','n','T','e','x','t',0}; > MSIRECORD *uirow; > - LPWSTR deformated, message; > - DWORD i, len, total_len, log_type = 0; > + LPWSTR deformated, message = {0}; > + DWORD len, log_type = 0; > INT rc = 0; > char *msg; > > @@ -1776,39 +1776,10 @@ INT MSI_ProcessMessage( MSIPACKAGE *package, INSTALLMESSAGE eMessageType, MSIREC > } > else > { > - static const WCHAR format[] = {'%','u',':',' ',0}; > - UINT count = MSI_RecordGetFieldCount( record ); > - WCHAR *p; > - > - total_len = 1; > - for (i = 1; i <= count; i++) > - { > - len = 0; > - MSI_RecordGetStringW( record, i, NULL, &len ); > - total_len += len + 13; > - } > - p = message = msi_alloc( total_len * sizeof(WCHAR) ); > - if (!p) return ERROR_OUTOFMEMORY; > - > - for (i = 1; i <= count; i++) > - { > - if (count > 1) > - { > - len = sprintfW( p, format, i ); > - total_len -= len; > - p += len; > - } > - len = total_len; > - MSI_RecordGetStringW( record, i, p, &len ); > - total_len -= len; > - p += len; > - if (count > 1 && total_len) > - { > - *p++ = ' '; > - total_len--; > - } > - } > - p[0] = 0; > + MSI_FormatRecordW(package, record, message, &len); > + len++; > + message = msi_alloc(len * sizeof(WCHAR)); > + MSI_FormatRecordW(package, record, message, &len); You can pass a NULL buffer in the size query. Please keep the check for allocation failure. I would check the first call to MSI_FormatRecordW too since the record is passed by the caller.

2 1

Re: [v3 3/3] d3dx9: Remove redundant parameter size check in set_constants().
by Matteo Bruni June 19, 2017

June 19, 2017

2017-06-15 0:00 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v3: > no changes. > --- > dlls/d3dx9_36/preshader.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 2785ca3..0bc31cb 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -1178,11 +1178,6 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > param_offset = i + j * info.major; > else > param_offset = i * info.minor + j; > - if (param_offset * sizeof(unsigned int) >= param->bytes) > - { > - WARN("Parameter data is too short, name %s, component %u.\n", debugstr_a(param->name), i); > - break; > - } > out[offset] = data[param_offset]; Is there anything else covering this case though? If I'm not mistaken such a parameter / constant would be accepted currently so just dropping the check would potentially allow broken preshaders to read outside of the parameter data. Now I certainly agree that the check shouldn't be there, it should probably be in init_set_constants_param() instead. If this is already checked somewhere in the code then I'm okay with the patch as is.

2 1

Re: [PATCH 2/5] msi: Use an external UI record handler before a string handler.
by Marvin June 18, 2017

June 18, 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=31710 Your paranoid android. === wvistau64 (32 bit package) === package.c:9086: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 20 package.c:9107: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 22 package.c:9107: Test failed: message didn't match package.c:9086: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 24 package.c:9107: Test failed: message didn't match === wvistau64 (64 bit package) === package.c:9086: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 20 package.c:9107: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 22 package.c:9107: Test failed: message didn't match package.c:9086: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 24 package.c:9107: Test failed: message didn't match

1 0

Re: [4/4] wined3d: Trigger frontbuffer update in surface_cpu_blt.
by Henri Verbeet June 18, 2017

June 18, 2017

On 16 June 2017 at 16:03, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > In this case I'm not sure about the best way to fix it. Feel free to use > a different approach if preferred (for example calling > swapchain_frontbuffer_updated from context_unmap_bo_address). > Explicitly calling from surface_cpu_blt() is probably the right way to go. > @@ -3343,6 +3343,9 @@ release: > context_unmap_bo_address(context, &dst_data, GL_PIXEL_UNPACK_BUFFER); > if (!same_sub_resource) > context_unmap_bo_address(context, &src_data, GL_PIXEL_UNPACK_BUFFER); > + > + swapchain_frontbuffer_updated(dst_texture, dst_sub_resource_idx, dst_box); Strictly speaking this is only necessary on success, but doing it unconditionally shouldn't hurt. > @@ -1979,6 +1979,22 @@ static HRESULT texture_resource_sub_resource_map(struct wined3d_resource *resour > return WINED3D_OK; > } > > +void swapchain_frontbuffer_updated(struct wined3d_texture *texture, unsigned int sub_resource_idx, > + const struct wined3d_box *box) > +{ > + struct wined3d_texture_sub_resource *sub_resource; > + > + if (!texture->swapchain || texture->swapchain->front_buffer != texture) > + return; > + if (!(sub_resource = wined3d_texture_get_sub_resource(texture, sub_resource_idx))) > + return; The sub-resource index should always be valid here. We validate it on entry into wined3d, and internally we should always pass valid indices. > + if (sub_resource->locations & (WINED3D_LOCATION_DRAWABLE | WINED3D_LOCATION_TEXTURE_RGB)) > + return; Perhaps more importantly, this check should be unnecessary for surface_cpu_blt(), since we always invalidate ~map_binding. > + if (box) SetRect(&texture->swapchain->front_buffer_update, box->left, box->top, box->right, box->bottom); And with this line effectively being only used for surface_cpu_blt(), I'm not sure the swapchain_frontbuffer_updated() helper is really worth it.

1 0

Detect whether wineserver is fully started? Signal? File?
by Sebastian M. Ernst June 18, 2017

June 18, 2017

Dear Wine developers, I am working on a little Python module which is supposed to make use of Wine. The module has a dedicated class for managing its own wineserver-session with its own prefix. It allows me to control wineserver independently of the lifetime of any Windows executable I run on top of it and to quit it when my work is done. Starting and stopping wineserver is no problem. However, what I can not figure out is how to determine when my wineserver is actually completely loaded, up and running. After all, the loading process requires quite a bit of time. Mainly due to my intention of preventing any (hard to debug) crashes and delays when running Windows executables, I want wineserver to be fully up & loaded before I run anything on top of it. The following code snipped illustrates the problem: os.environ['WINEPREFIX'] = '/some/path' proc_wineserver = subprocess.Popen( ['wineserver', '-f', '-p'], # run persistent in foreground stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE, shell = False ) time.sleep(1) # Placeholder *HACK*. BETTER SOLUTION? proc_somewinexe = subprocess.Popen(['wine some.exe'], shell = False) As a temporary hack, for which I am seeking a replacement, I simply sleep for one second. This is odd on faster PCs and really not enough on somewhat older hardware (or with slow harddrives instead of SSDs) ... Is there a signal I can catch or a file I can check (and wait for in a loop to appear) or anything else which would allow me a clean(er) solution? Or, alternatively, where in the Wine source code do I have to look for how the "wine" command does it (?) - looking for wineserver and firing one up if there is not one before any exe file is executed? I recently posted a question in the Wine forum with similar content: https://forum.winehq.org/viewtopic.php?f=2&t=28967 Thanks for any advise, Sebastian

3 6

[PATCH] gdiplus: Implement triangular line caps in widened paths.
by Clemens Tamme June 17, 2017

June 17, 2017

Pens in GDI+ have a startcap an an endcap property. Previously, values LineCapFlat, LineCapSquare and LineCapRound were supported, now LineCapTriangle is added. This solves two FIXMEs in GdipWidenPath: unimplemented end cap 3 and unimplemented start cap 3 (3 being the value of LineCapTriangle). Test dlls/gdiplus/test/graphicspath.c runs on Ubuntu 16.04. Signed-off-by: Clemens Tamme <clemens.tamme(a)gmail.com> --- dlls/gdiplus/graphicspath.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/dlls/gdiplus/graphicspath.c b/dlls/gdiplus/graphicspath.c index 3d33c29..e34f4ed 100644 --- a/dlls/gdiplus/graphicspath.c +++ b/dlls/gdiplus/graphicspath.c @@ -1883,6 +1883,27 @@ static void widen_cap(const GpPointF *endpoint, const GpPointF *nextpoint, } break; } + case LineCapTriangle: + { + REAL segment_dy = nextpoint->Y-endpoint->Y; + REAL segment_dx = nextpoint->X-endpoint->X; + REAL segment_length = sqrtf(segment_dy*segment_dy + segment_dx*segment_dx); + REAL distance = pen->width/2.0; + REAL dx, dy; + + dx = distance * segment_dx / segment_length; + dy = distance * segment_dy / segment_length; + + if (add_first_points) { + add_bevel_point(endpoint, nextpoint, pen, 1, last_point); + + *last_point = add_path_list_node(*last_point, endpoint->X - dx, + endpoint->Y - dy, PathPointTypeLine); + } + if (add_last_point) + add_bevel_point(endpoint, nextpoint, pen, 0, last_point); + break; + } } } @@ -2118,10 +2139,10 @@ GpStatus WINGDIPAPI GdipWidenPath(GpPath *path, GpPen *pen, GpMatrix *matrix, { last_point = points; - if (pen->endcap > LineCapRound) + if (pen->endcap > LineCapTriangle) FIXME("unimplemented end cap %x\n", pen->endcap); - if (pen->startcap > LineCapRound) + if (pen->startcap > LineCapTriangle) FIXME("unimplemented start cap %x\n", pen->startcap); if (pen->dashcap != DashCapFlat) -- 2.7.4

1 0

Installation of up-to-date wine-staging
by Alan W. Irwin June 17, 2017

June 17, 2017

I followed the directions at <https://wine-staging.com/installation.html> to install wine-staging on my Debian Jessie platform. However, the result is considerably out of date (version 2.4 rather than 2.9 (or 2.10)), and there appears to be no method of determining what version of wine-staging is available for each of the other Linux platforms mentioned on that web page such as Debian testing = stretch. Is this lack of an up-to-date version some idiosyncrasy for the Debian Jessie platform or is this a problem for all the Linux distributions covered in the above web page? Are there plans to start keeping wine-staging installs more up to date for Debian Jessie or is there some other set of directions I should be following to gain access to the latest version of wine-staging? It's been a number of years since I have built wine, and in that era I only bothered with the 32-bit version. So if it turns out the answer is there are no plans to keep the various distro versions of wine-staging up to date so the only way to get an up-to-date version is to build a WoW64 version of the latest wine that has been patched with the wine-staging patches, it would be good to state that in the above page. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

2 3

Approach to debugging wine issues
by Fabian Maurer June 16, 2017

June 16, 2017

Hello Wine Devs, I'm currently trying to investigate an crash with an old game called KnightOfKnights (See Bug 43180). I already know which dll is responsible for the crash, and the native dll fixes it. The crash appears in native code of the game though. Now my approach would be to open the program with a debugger (x64dbg works nice under wine) and then step through the program, finding where the null- pointer comes from until I reach the wine function that returned something wrong. After all, I can compare the control flow using the native d3dxof dll and the builtin d3dxof dll to see where the game gets the value(s) that lead to crash, the goal here would be to find one or more functions from d3dxof that return a different value, like a nullpointer. Then I could begin hacking wine code to find out why it returns something wrong and try to fix that, without looking at the native code of course. Now my question, is this an accepted solution to fixing bugs? I read in the wiki that disassembling a program to diagnose bugs is discouraged due to legal issues and difficulty, though I don't really see another way to track it down. Any insights from you guys and girls who are used to fixing bugs? Just figured I should ask, before I try to create a solution by ways you won't accept. Regards, Fabian Maurer

3 3

Re: widl: Try to append .tlb extension to importib file name if it can't be found without it.
by Alexandre Julliard June 16, 2017

June 16, 2017

Jacek Caban <jacek(a)codeweavers.com> writes: > That's for cases like importlib("oleacc.dll"). MIDL can import them from > system DLLs, but for widl, we currently need oleacc.dll file in include > directory. Since it is at least confusing to have a file named > oleacc.dll between includes, this patch allows providing oleacc.dll.tlb > file instead. I'm not sure what you want to do here. Do you want to put a plain typelib file in includes, but name it .dll.tlb? Or do you need an actual dll? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [v2 PATCH] include/wincodec.idl: Stop redefinition of ID2D1Image
by Vincent Povirk June 16, 2017

June 16, 2017

Why can't we handle this the way that d2d1.idl does? It doesn't include wincodec.idl, but it declares the interfaces it uses from there. I know the Windows SDK doesn't do that, but that's probably because the SDK headers are weird and don't declare the d2d1 interfaces in an idl.

3 2

Re: [PATCH] oledb32: Support DBTYPE_I4->DBTYPE_WSTR in GetConversionSize
by Huw Davies June 16, 2017

June 16, 2017

On Tue, Jun 13, 2017 at 04:09:54AM +0000, Alistair Leslie-Hughes wrote: > dst_len cannot be set to 110 beacuse we don't have any idea of how this > value is set. In this case we really do want to set something, and if it's 110 on Windows then we may as well use that. The previous case was to do with a NULL-variant, where DataConvert() didn't actually return any data. This time it will, so we should give the app a chance to allocate a big enough buffer. It would also be worth handling and testing more cases than the conversion to DBTYPE_I4. Perhaps we should set *dst_len to 110 if get_length() returns 0 and then let the special cases overrride it. Huw. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/convert.c | 5 +++++ > dlls/oledb32/tests/convert.c | 12 ++++++++++++ > 2 files changed, 17 insertions(+) > > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index 0d45ef0..bf01101 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -1401,6 +1401,11 @@ static HRESULT WINAPI convert_GetConversionSize(IDataConvert* iface, > case DBTYPE_WSTR: > switch (src_type) > { > + case DBTYPE_I4: > + { > + /* Return S_OK to signal we can convert from this type. On windows, dst_len is set to 110. */ > + break; > + } > case DBTYPE_VARIANT: > { > VARIANT v; > diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c > index 116ca16..d07ebf1 100644 > --- a/dlls/oledb32/tests/convert.c > +++ b/dlls/oledb32/tests/convert.c > @@ -2715,6 +2715,7 @@ static void test_getconversionsize(void) > VARIANT var; > SAFEARRAY *psa = NULL; > SAFEARRAYBOUND rgsabound[1]; > + int i4; > > /* same way as CanConvert fails here */ > dst_len = 0; > @@ -2834,6 +2835,17 @@ static void test_getconversionsize(void) > ok(dst_len == 1802, "%ld\n", dst_len); > VariantClear(&var); > > + /* A value of 110 is returned in dst_len */ > + dst_len = 0; > + src_len = sizeof(i4); > + i4 = 200; > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_I4, DBTYPE_WSTR, &src_len, &dst_len, &i4); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > + dst_len = 0; > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_I4, DBTYPE_WSTR, NULL, &dst_len, NULL); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > /* On Windows, NULL variants being convert to a non-fixed sized type will return a dst_len of > * 110 but we aren't testing for this value. > */ > -- > 1.9.1 > > >

1 0