May 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

WineConf 2017
by Jacek Caban June 8, 2017

June 8, 2017

Hi all, We'd like to share with everyone current plans for WineConf. It will most likely be on 28th and 29th October 2017 in Wrocław, Sofitel hotel. It's still not final yet, but we feel that it's close enough to be worth sharing. We will send an announcement with more details once we have everything sorted out. Looking forward to see you all in Wrocław, Piotr and Jacek PS: I don't seem to have enough permissions to create a page on Wiki. Could someone please do that?

1 1

Re: [v2 PATCH 2/3] mfplat: Implement MFCreateMediaType
by Nikolay Sivov June 6, 2017

June 6, 2017

On 31.05.2017 4:09, Alistair Leslie-Hughes wrote: > +typedef struct _mfmedaitype > +{ > + IMFMediaType IMFMediaType_iface; > + LONG ref; > +} mfmedaitype; You got a typo in structure name.

4 4

Re: [PATCH] user32: Keep tracking if we just created the menu.
by Huw Davies June 2, 2017

June 2, 2017

On Wed, May 31, 2017 at 02:34:06PM -0500, Zebediah Figura wrote: > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/user32/menu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/user32/menu.c b/dlls/user32/menu.c > index a65f01eaa5..c52b723f76 100644 > --- a/dlls/user32/menu.c > +++ b/dlls/user32/menu.c > @@ -2597,7 +2597,10 @@ static BOOL MENU_ButtonDown( MTRACKER* pmt, HMENU hPtMenu, UINT wFlags ) > > /* If the popup menu is not already "popped" */ > if (!(ptmenu->items[pos].fState & MF_MOUSESELECT)) > + { > pmt->hCurrentMenu = MENU_ShowSubPopup( pmt->hOwnerWnd, hPtMenu, FALSE, wFlags ); > + return TRUE; > + } > } > > /* A click on an item or anywhere on a popup keeps tracking going */ So under what conditions does the if statement directly below this hunk not get triggered? Huw.

2 4

Re: [PATCH 3/4] quartz: fix crash in FilterGraph2_Render
by Andrew Eikum June 2, 2017

June 2, 2017

Can you add a test for this? Andrew On Thu, May 25, 2017 at 04:54:49PM +0200, Miklós Máté wrote: > Note: there are a lot of other places as well where the null pointer handling > is present in the msdn docs but missing in wine. > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/quartz/filtergraph.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/quartz/filtergraph.c b/dlls/quartz/filtergraph.c > index a143b05d83..e26eb199c8 100644 > --- a/dlls/quartz/filtergraph.c > +++ b/dlls/quartz/filtergraph.c > @@ -1279,6 +1279,9 @@ static HRESULT WINAPI FilterGraph2_Render(IFilterGraph2 *iface, IPin *ppinOut) > > TRACE("(%p/%p)->(%p)\n", This, iface, ppinOut); > > + if (!ppinOut) > + return E_POINTER; > + > if (TRACE_ON(quartz)) > { > PIN_INFO PinInfo; > -- > 2.11.0 > > >

3 2

Re: [PATCH 1/4] quartz: AsyncReader is always expected to have output pin
by Andrew Eikum June 1, 2017

June 1, 2017

Thanks for working on this. I tested your patch sequence against a number of games as well as embedding videos in MSOffice 2007 and 2010 and found no regressions. I do have some comments, though, in-line below. Is this something you could write a test for? E.g. create the filter and then query for its output pin immediately after creation. On Thu, May 25, 2017 at 04:54:47PM +0200, Miklós Máté wrote: > Even between create() and Load(). This fixes a crash in DSPlayer. > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/quartz/filesource.c | 31 ++++++++++++++++++++----------- > 1 file changed, 20 insertions(+), 11 deletions(-) > > diff --git a/dlls/quartz/filesource.c b/dlls/quartz/filesource.c > index ed7e5ee201..200463ff5b 100644 > --- a/dlls/quartz/filesource.c > +++ b/dlls/quartz/filesource.c > @@ -73,7 +73,8 @@ static const IFileSourceFilterVtbl FileSource_Vtbl; > static const IAsyncReaderVtbl FileAsyncReader_Vtbl; > static const IAMFilterMiscFlagsVtbl IAMFilterMiscFlags_Vtbl; > > -static HRESULT FileAsyncReader_Construct(HANDLE hFile, IBaseFilter * pBaseFilter, LPCRITICAL_SECTION pCritSec, IPin ** ppPin); > +static HRESULT FileAsyncReader_Construct(IBaseFilter * pBaseFilter, LPCRITICAL_SECTION pCritSec, IPin ** ppPin); > +static HRESULT FileAsyncReader_SetFile(IAsyncReader * iface, HANDLE hFile); > > static const WCHAR mediatype_name[] = { > 'M', 'e', 'd', 'i', 'a', ' ', 'T', 'y', 'p', 'e', 0 }; > @@ -416,6 +417,7 @@ static const BaseFilterFuncTable BaseFuncTable = { > HRESULT AsyncReader_create(IUnknown * pUnkOuter, LPVOID * ppv) > { > AsyncReader *pAsyncRead; > + HRESULT hr; > > if( pUnkOuter ) > return CLASS_E_NOAGGREGATION; > @@ -429,7 +431,8 @@ HRESULT AsyncReader_create(IUnknown * pUnkOuter, LPVOID * ppv) > > pAsyncRead->IFileSourceFilter_iface.lpVtbl = &FileSource_Vtbl; > pAsyncRead->IAMFilterMiscFlags_iface.lpVtbl = &IAMFilterMiscFlags_Vtbl; > - pAsyncRead->pOutputPin = NULL; > + hr = FileAsyncReader_Construct(&pAsyncRead->filter.IBaseFilter_iface, &pAsyncRead->filter.csFilter, &pAsyncRead->pOutputPin); > + BaseFilterImpl_IncrementPinVersion(&pAsyncRead->filter); If this fails, I think we should free resources and return the error immediately. > > pAsyncRead->pszFileName = NULL; > pAsyncRead->pmt = NULL; > @@ -438,7 +441,7 @@ HRESULT AsyncReader_create(IUnknown * pUnkOuter, LPVOID * ppv) > > TRACE("-- created at %p\n", pAsyncRead); > > - return S_OK; > + return hr; > } > > /** IUnknown methods **/ > @@ -606,7 +609,7 @@ static ULONG WINAPI FileSource_Release(IFileSourceFilter * iface) > > static HRESULT WINAPI FileSource_Load(IFileSourceFilter * iface, LPCOLESTR pszFileName, const AM_MEDIA_TYPE * pmt) > { > - HRESULT hr; > + HRESULT hr = E_FAIL; > HANDLE hFile; > IAsyncReader * pReader = NULL; > AsyncReader *This = impl_from_IFileSourceFilter(iface); > @@ -625,16 +628,15 @@ static HRESULT WINAPI FileSource_Load(IFileSourceFilter * iface, LPCOLESTR pszFi > return HRESULT_FROM_WIN32(GetLastError()); > } > > - /* create pin */ > - hr = FileAsyncReader_Construct(hFile, &This->filter.IBaseFilter_iface, &This->filter.csFilter, &This->pOutputPin); > - BaseFilterImpl_IncrementPinVersion(&This->filter); > > - if (SUCCEEDED(hr)) > + if (This->pOutputPin) Since we now create the output pin during filter creation, this should never be non-NULL, right? > hr = IPin_QueryInterface(This->pOutputPin, &IID_IAsyncReader, (LPVOID *)&pReader); > > /* store file name & media type */ > if (SUCCEEDED(hr)) > { > + FileAsyncReader_SetFile(pReader, hFile); > + > CoTaskMemFree(This->pszFileName); > if (This->pmt) > FreeMediaType(This->pmt); > @@ -939,7 +941,7 @@ static const BaseOutputPinFuncTable output_BaseOutputFuncTable = { > BaseOutputPinImpl_BreakConnect > }; > > -static HRESULT FileAsyncReader_Construct(HANDLE hFile, IBaseFilter * pBaseFilter, LPCRITICAL_SECTION pCritSec, IPin ** ppPin) > +static HRESULT FileAsyncReader_Construct(IBaseFilter * pBaseFilter, LPCRITICAL_SECTION pCritSec, IPin ** ppPin) > { > PIN_INFO piOutput; > HRESULT hr; > @@ -952,9 +954,8 @@ static HRESULT FileAsyncReader_Construct(HANDLE hFile, IBaseFilter * pBaseFilter > > if (SUCCEEDED(hr)) > { > - FileAsyncReader *pPinImpl = (FileAsyncReader *)*ppPin; > + FileAsyncReader *pPinImpl = impl_from_IPin(*ppPin); > pPinImpl->IAsyncReader_iface.lpVtbl = &FileAsyncReader_Vtbl; > - pPinImpl->hFile = hFile; > pPinImpl->bFlushing = FALSE; > pPinImpl->sample_list = NULL; > pPinImpl->handle_list = NULL; > @@ -965,6 +966,14 @@ static HRESULT FileAsyncReader_Construct(HANDLE hFile, IBaseFilter * pBaseFilter > return hr; > } > > +static HRESULT FileAsyncReader_SetFile(IAsyncReader * iface, HANDLE hFile) > +{ > + FileAsyncReader *This = impl_from_IAsyncReader(iface); > + > + This->hFile = hFile; > + return S_OK; > +} > + Why is this a separate function instead of just setting hFile in FileSource_Load? > /* IAsyncReader */ > > static HRESULT WINAPI FileAsyncReader_QueryInterface(IAsyncReader * iface, REFIID riid, LPVOID * ppv) > -- > 2.11.0 > > >

2 1

Re: PATCH 1/7] msvcrt: Translate SEH exception on each call to __CxxFrameHandler.
by Piotr Caban June 1, 2017

June 1, 2017

On 05/24/17 02:54, Daniel Lehman wrote: > +extern void __wine_rtl_unwind( EXCEPTION_REGISTRATION_RECORD* frame, EXCEPTION_RECORD *record, > + void (*target)(void) ); It's already defined in wine/exception.h. > +extern void CDECL __DestructExceptionObject(EXCEPTION_RECORD *rec); This is also already defined (in msvcrt.h) > + > +static void DECLSPEC_NORETURN seh_unwind_target(void) > +{ > + seh_frame_info *seh_frame = (seh_frame_info *)__wine_get_frame(); > + __wine_pop_frame( &seh_frame->frame ); There's no need to call __wine_pop_frame here, it will be done after the jump anyway. I think that the whole series will be cleaner/easier to read if we add the __EXCEPT_CTX/__FINALLY_CTX macros and use them here. I'm attaching a patch with proposition of changes for this functions. With such changes your patch will look like this (this is not tested): typedef struct { ULONG64 dest_frame; ULONG64 orig_frame; DISPATCHER_CONTEXT *dispatch; const cxx_function_descr *descr; } se_translator_ctx; static DWORD se_translation_filter(EXCEPTION_POINTERS *ep, void *c) { se_translator_ctx *ctx = (se_translator_ctx*)c; /* this is copied from original patch but I think that */ /* terminate should be called on non C++ exceptions here */ if (ep->rec->ExceptionCode != CXX_EXCEPTION) return ExceptionContinueSearch; find_catch_block(...); __DestructExceptionObject(ep->rec); return ExceptionExecuteHandler; } in cxx_frame_handler: if (data->se_translator) { se_translator_ctx ctx; //initialize ctx __TRY { except_ptrs.ExceptionRecord = rec; except_ptrs.ContextRecord = context; data->se_translator(rec->ExceptionCode, &except_ptrs); } __EXCEPT_CTX(se_translation_filter, &ctx) { } __END_TRY } With such changes second patch can be also changed to use __TRY/__FINALLY_CTX around "ret_addr = handler(0, frame);" file. What do you think about it? Thanks, Piotr

2 1

Re: [PATCH 6/6] d3dx9: Merge constant setting for child parameters when possible.
by Matteo Bruni May 31, 2017

May 31, 2017

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > + if (!(const_set->table == current_table && current_start_offset == start_offset > + && const_set->direct_copy == first_const->direct_copy > + && current_data == const_set->param->data > + && (const_set->direct_copy || (first_const->param->type == const_set->param->type > + && first_const->param->class == const_set->param->class > + && first_const->param->columns == const_set->param->columns > + && first_const->param->rows == const_set->param->rows > + && first_const->register_count == const_set->register_count > + && (i == const_tab->const_set_count - 1 > + || first_const->param->element_count == const_set->param->element_count))))) > + { > + TRACE("direct_copy %u, i %u, index %u, param %s.%s, current_data %p, const_set->param->data %p, "\ > + "current_start_offset %u, start_offset %u, const_set->table %u, current_table %u.\n", > + const_set->direct_copy, i, index, debugstr_a(param->name), > + debugstr_a(const_set->param->name), current_data, const_set->param->data, > + current_start_offset, start_offset, const_set->table, current_table); > + break; > + } This looks like a debug trace. > + TRACE("Merging %u child parameters for %s, not merging %u, direct_copy %u.\n", i - index, > + debugstr_a(param->name), const_tab->const_set_count - i, first_const->direct_copy); I guess it's intentional that you're printing this even when not merging anything, in that case the TRACE sounds a bit awkward though. Maybe have a separate TRACE for that case? BTW, please format the BOOL with %#x. > + if (i > index + 1) > + { > + first_const->element_count = element_count; > + if (first_const->direct_copy) > + { > + first_const->element_count = 1; > + if (index == start_index > + && !(param->type == D3DXPT_VOID && param->class == D3DXPC_STRUCT)) > + { > + if (param_type_to_table_type(param->type) == PRES_VT_MAX) > + return D3DERR_INVALIDCALL; > + first_const->param = param; > + } > + first_const->register_count = get_reg_offset(current_table, current_start_offset) > + - first_const->register_index; > + } > + 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; > + } Just for my own curiosity, do you think it's significant to merge non-direct_copy entries? Not that it hurts anything to have it.

2 4

Re: [v2 2/6] d3dx9: Factor out get_const_upload_info() function.
by Matteo Bruni May 31, 2017

May 31, 2017

2017-05-30 11:38 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v2: > - renamed 'n' to 'major_count'; major_count is still a bit meh, since "major" is really already a count and there is an unspecified "count" too. I don't have any good suggestion and this is an improvement over the current naming though, so...

1 0

Re: [PATCH 1/6] d3dx9: Get rid of table lookup for converting between register indexes and offsets.
by Matteo Bruni May 31, 2017

May 31, 2017

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > static unsigned int get_reg_offset(unsigned int table, unsigned int offset) > { > - return offset / table_info[table].reg_component_count; > + return table == PRES_REGTAB_OBCONST ? offset : offset >> 2; > +} > + > +static unsigned int get_offset_reg(unsigned int table, unsigned int reg_idx) > +{ > + return table == PRES_REGTAB_OBCONST ? reg_idx : reg_idx << 2; > } I suppose using an explicit division and multiplication here wouldn't change the generated code, in which case I'd slightly prefer that. It doesn't matter right now, just mentioning it for potentially similar cases in the future. Also this patch probably should have been split in two, with the first patch introducing get_offset_reg() with no functional changes and the second hardcoding the table check / dropping the table lookup. Not worth a rework at this point I guess. > @@ -1033,9 +1035,9 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > unsigned int offset; > > offset = start_offset + i * major_stride + j; > - if (offset / table_info[table].reg_component_count >= rs->table_sizes[table]) > + if (get_reg_offset(table, offset) >= rs->table_sizes[table]) > { > - if (table_info[table].reg_component_count != 1) > + if (table != PRES_REGTAB_OBCONST) > FIXME("Output offset exceeds table size, name %s, component %u.\n", > debugstr_a(param->name), i); > break; Not new and probably I just forgot the details, but, why would the register component count matter for the FIXME? > - offset = reg_index * table_info[table].reg_component_count > - + offset % table_info[table].reg_component_count; > + offset = get_offset_reg(table, reg_index) + offset % get_offset_reg(table, 1); That "get_offset_reg(table, 1)" comes up a number of times. Maybe worth making an extra get_reg_components(table) (or similar) helper? Simply for even greater clarity.

2 5

Re: [PATCH 3/6] d3d9: Validate adapter format in CheckDeviceFormat().
by Marvin May 31, 2017

May 31, 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=31280 Your paranoid android. === wvistau64 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w2008s64 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w7u (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w7pro64 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w8 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w864 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w1064 (32 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === wvistau64 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w2008s64 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w7pro64 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w864 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4. === w1064 (64 bit device) === device.c:11206: Test failed: Got unexpected hr 0, device type 0x4. device.c:11209: Test failed: Got unexpected hr 0, device type 0x4. device.c:11212: Test failed: Got unexpected hr 0, device type 0x4. device.c:11215: Test failed: Got unexpected hr 0, device type 0x4.

2 1

Re: [PATCH 2/6] d3d8: Validate adapter format in CheckDeviceFormat().
by Marvin May 31, 2017

May 31, 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=31279 Your paranoid android. === w8 (32 bit device) === device.c:2945: Test failed: Received WM_WINDOWPOSCHANGED but did not expect it.

1 0

RE: [PATCH 2/7] msvcrt: Clean up registered C++ object in handler.
by Daniel Lehman May 31, 2017

May 31, 2017

On 05/24/17 02:55, Daniel Lehman wrote: > +static DWORD cxx_catch_cleanup(EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame, > + CONTEXT *context, > +EXCEPTION_REGISTRATION_RECORD **pdispatcher) { > + if (rec->ExceptionFlags & (EH_UNWINDING | EH_EXIT_UNWIND)) > + { > + thread_data_t *data = msvcrt_get_thread_data(); > + frame_info *cur; > + > + if (cxx_is_consolidate(rec)) > Is this condition really needed? Shouldn't we clean the object no matter what's the reason of unwind? Yeah. That's covered by patch 7/7. The original code only cleaned up if consolidating. Since this 2/7 patch was somewhat of a refactoring for the later patches, I kept the consolidate-only cleanup logic. I can merge them if you want >> + if ((ULONG64)cur <= (ULONG64)frame) > This condition is not working. It's making assumption about order of catch_frame and frame_info variables on stack while they are declared this way: I see what you mean. If I forcefully reverse them, my tests crash; my version of gcc was always putting them in the same place on the stack, regardless of where they were declared >> + EXCEPTION_REGISTRATION_RECORD catch_frame; >> cxx_frame_info frame_info; > Shouldn't the cxx_catch_cleanup just unregister the object that was registered in call_catch_block? I didn't find a way to be call __CxxUnregisterObject on that one specifically (I'll try suggestions if you got em) but the loop in cxx_catch_cleanup effective does this. when unwinding a nested exception, cxx_catch_cleanup will be called when unwinding call_catch_block, so all objects registered in call_catch_block and below will be cleaned up at that point. Unless the catch block itself explicitly calls __CxxRegisterObject, the only object on the list up to that frame will be the one from call_catch_block > Here's a test case that demonstrate the problem with cur <= frame > comparison: > > try { > try { int *p = NULL; *p = 0x42; } > catch (klass x) { throw 1; } > } catch (int i) { } > > try { throw 1; } > catch(...) {} This crashes for me even on Windows because the SEGV is uncaught. It 'works' if I set an seh translator that throws int, but I get identical results on Wine with my series applied. Do I need to add something? Thanks daniel

2 1

Re: [PATCH 7/7] regedit: Do not get text for items with an index less than one
by Alexandre Julliard May 31, 2017

May 31, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -59,7 +59,7 @@ LPWSTR GetItemText(HWND hwndLV, UINT item) > { > LPWSTR newStr, curStr; > unsigned int maxLen = 128; > - if (item == 0) return NULL; /* first item is ALWAYS a default */ > + if (item < 1) return NULL; /* first item is ALWAYS a default */ How is this different? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH 2/3] mfplat: Implement MFCreateMediaType
by Dmitry Timoshkov May 30, 2017

May 30, 2017

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +struct IMFMediaTypeVtbl mediatype_vtbl = > +{ It should be 'static const', and without 'struct'. -- Dmitry.

1 0

Re: [7/7] wsdapi/tests: Add tests for Get/SetSockaddr.
by Marvin May 30, 2017

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

1 0

Re: [6/7] wsdapi/tests: Add tests for Get/SetMessageType.
by Marvin May 30, 2017

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

1 0

Re: [5/7] wsdapi/tests: Add tests for Get/SetPort.
by Marvin May 30, 2017

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

1 0

Re: [4/7] wsdapi/tests: Add tests for Get/SetTransportAddress.
by Marvin May 30, 2017

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

1 0

Re: [3/7] wsdapi/tests: Add WSDCreateUdpAddress tests.
by Marvin May 30, 2017

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

1 0

Re: [PATCH 2/7] msvcrt: Clean up registered C++ object in handler.
by Piotr Caban May 30, 2017

May 30, 2017

On 05/24/17 02:55, Daniel Lehman wrote: > +static DWORD cxx_catch_cleanup(EXCEPTION_RECORD *rec, EXCEPTION_REGISTRATION_RECORD *frame, > + CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **pdispatcher) > +{ > + if (rec->ExceptionFlags & (EH_UNWINDING | EH_EXIT_UNWIND)) > + { > + thread_data_t *data = msvcrt_get_thread_data(); > + frame_info *cur; > + > + if (cxx_is_consolidate(rec)) Is this condition really needed? Shouldn't we clean the object no matter what's the reason of unwind? > + { > + rec = (void*)rec->ExceptionInformation[4]; > + > + for (cur = data->frame_info_head; cur; cur = cur->next) > + { > + if ((ULONG64)cur <= (ULONG64)frame) This condition is not working. It's making assumption about order of catch_frame and frame_info variables on stack while they are declared this way: > + EXCEPTION_REGISTRATION_RECORD catch_frame; > cxx_frame_info frame_info; Shouldn't the cxx_catch_cleanup just unregister the object that was registered in call_catch_block? Thanks, Piotr

1 1

Re: [PATCH] macdrv: Don't update clipboard if its content didn't change
by Ken Thomases May 30, 2017

May 30, 2017

On May 25, 2017, at 1:22 PM, Piotr Caban <piotr(a)codeweavers.com> wrote: > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/winemac.drv/clipboard.c | 34 ++++++++++------------------------ > dlls/winemac.drv/cocoa_clipboard.m | 18 ++++++++++++++++++ > dlls/winemac.drv/macdrv_cocoa.h | 1 + > 3 files changed, 29 insertions(+), 24 deletions(-) > > +int macdrv_has_pasteboard_changed(void) > +{ > + __block int new_change_count; > + int ret; > + > + OnMainThread(^{ > + NSPasteboard* pb = [NSPasteboard generalPasteboard]; > + new_change_count = [pb changeCount]; > + }); > + > + ret = (change_count != new_change_count); > + change_count = new_change_count; > + return ret; > +} Unfortunately, -[NSPasteboard changeCount] isn't incremented for all changes to the pasteboard. For example, if the owner replaces the data for an existing type, it doesn't change. I'd have to check again, but I think it doesn't even change if the owner adds a new data type. I think it only changes when the pasteboard is cleared and rebuilt by -clearContents or -declareTypes:owner:. -Ken

2 5

Re: [PATCH 4/6] d3dx9: Evaluate condition if parameter can be directly copied during initialization.
by Matteo Bruni May 29, 2017

May 29, 2017

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: The patch subject is a bit cumbersome IMO, what about "d3dx9: Add a direct copy path to set_constants()."?

2 2

Re: [PATCH 3/6] d3dx9: Factor out param_type_to_table_type() function.
by Matteo Bruni May 29, 2017

May 29, 2017

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 26 ++++++++++++++++++++++---- > 1 file changed, 22 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 262b7c1..bddd74f 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -193,7 +193,8 @@ enum pres_value_type > PRES_VT_FLOAT, > PRES_VT_DOUBLE, > PRES_VT_INT, > - PRES_VT_BOOL > + PRES_VT_BOOL, > + PRES_VT_MAX > }; I guess you mean PRES_VT_COUNT. > > static const struct > @@ -260,6 +261,22 @@ struct d3dx_pres_ins > struct d3dx_pres_operand output; > }; > > +static enum pres_value_type param_type_to_table_type(D3DXPARAMETER_TYPE type) In d3d we usually name those the other way around e.g. table_type_from_param_type().

1 0

Re: [PATCH 2/6] d3dx9: Factor out get_constant_dimensions() function.
by Matteo Bruni May 29, 2017

May 29, 2017

2017-05-24 11:46 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 43 +++++++++++++++++++++++++++---------------- > 1 file changed, 27 insertions(+), 16 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 29a2346..262b7c1 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -979,6 +979,31 @@ void d3dx_free_param_eval(struct d3dx_param_eval *peval) > HeapFree(GetProcessHeap(), 0, peval); > } > > +static void get_constant_dimensions(struct d3dx_const_param_eval_output *const_set, BOOL *transpose, > + unsigned int *major, unsigned int *minor, unsigned int *major_stride, unsigned int *n, > + unsigned int *count) It seems better to pass around a struct pointer in place of all those separate out arguments, e.g. struct const_upload_info. Then you can name the helper get_"structname"() too. > + *n = min(*major * *major_stride, > + get_offset_reg(table, const_set->register_count) + *major_stride - 1) / *major_stride; > + *count = *n * *minor; Preexisting, but "n" is a bit confusing, especially considering that there is a "count" too. Something like "available_major" / "reg_count"? count might be "component_count" or similar. Maybe you can find some better names...

1 0

Re: [PATCH] api-ms-win-security-activedirectoryclient-l1-1-0: Add dll.
by Nikolay Sivov May 29, 2017

May 29, 2017

On 29.05.2017 14:04, Andrey Gusev wrote: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > configure | 2 ++ > configure.ac | 1 + > dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in | 1 + > .../api-ms-win-security-activedirectoryclient-l1-1-0.spec | 8 ++++++++ > tools/make_specfiles | 4 ++++ > 5 files changed, 16 insertions(+) > create mode 100644 dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > create mode 100644 dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > > diff --git a/configure b/configure > index d2d391c..fb22627 100755 > --- a/configure > +++ b/configure > @@ -1026,6 +1026,7 @@ enable_api_ms_win_ntuser_dc_access_l1_1_0 > enable_api_ms_win_power_base_l1_1_0 > enable_api_ms_win_power_setting_l1_1_0 > enable_api_ms_win_rtcore_ntuser_private_l1_1_0 > +enable_api_ms_win_security_activedirectoryclient_l1_1_0 > enable_api_ms_win_security_audit_l1_1_1 > enable_api_ms_win_security_base_l1_1_0 > enable_api_ms_win_security_base_l1_2_0 > @@ -17897,6 +17898,7 @@ wine_fn_config_dll api-ms-win-ntuser-dc-access-l1-1-0 enable_api_ms_win_ntuser_d > wine_fn_config_dll api-ms-win-power-base-l1-1-0 enable_api_ms_win_power_base_l1_1_0 > wine_fn_config_dll api-ms-win-power-setting-l1-1-0 enable_api_ms_win_power_setting_l1_1_0 > wine_fn_config_dll api-ms-win-rtcore-ntuser-private-l1-1-0 enable_api_ms_win_rtcore_ntuser_private_l1_1_0 > +wine_fn_config_dll api-ms-win-security-activedirectoryclient-l1-1-0 enable_api_ms_win_security_activedirectoryclient_l1_1_0 > wine_fn_config_dll api-ms-win-security-audit-l1-1-1 enable_api_ms_win_security_audit_l1_1_1 > wine_fn_config_dll api-ms-win-security-base-l1-1-0 enable_api_ms_win_security_base_l1_1_0 > wine_fn_config_dll api-ms-win-security-base-l1-2-0 enable_api_ms_win_security_base_l1_2_0 > diff --git a/configure.ac b/configure.ac > index db4d168..dde867b 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2843,6 +2843,7 @@ WINE_CONFIG_DLL(api-ms-win-ntuser-dc-access-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-power-base-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-power-setting-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-rtcore-ntuser-private-l1-1-0) > +WINE_CONFIG_DLL(api-ms-win-security-activedirectoryclient-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-security-audit-l1-1-1) > WINE_CONFIG_DLL(api-ms-win-security-base-l1-1-0) > WINE_CONFIG_DLL(api-ms-win-security-base-l1-2-0) > diff --git a/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > new file mode 100644 > index 0000000..e1e99bd > --- /dev/null > +++ b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/Makefile.in > @@ -0,0 +1 @@ > +MODULE = api-ms-win-security-activedirectoryclient-l1-1-0.dll > diff --git a/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > new file mode 100644 > index 0000000..eef1c40 > --- /dev/null > +++ b/dlls/api-ms-win-security-activedirectoryclient-l1-1-0/api-ms-win-security-activedirectoryclient-l1-1-0.spec > @@ -0,0 +1,8 @@ > +@ stub DsBindWithSpnExW > +@ stub DsCrackNamesW > +@ stub DsFreeDomainControllerInfoW > +@ stub DsFreeNameResultW > +@ stub DsFreePasswordCredentials > +@ stub DsGetDomainControllerInfoW > +@ stub DsMakePasswordCredentialsW > +@ stub DsUnBindW > diff --git a/tools/make_specfiles b/tools/make_specfiles > index e544293..910bd0f 100755 > --- a/tools/make_specfiles > +++ b/tools/make_specfiles > @@ -157,6 +157,10 @@ my @dll_groups = > "api-ms-win-power-setting-l1-1-0", > ], > [ > + "ntdsapi", > + "api-ms-win-security-activedirectoryclient-l1-1-0", > + ], > + [ > "kernel32", > "api-ms-win-appmodel-identity-l1-1-0", > "api-ms-win-appmodel-runtime-l1-1-1", > Those exports are present in kernelbase spec file, maybe it's better to forward to it?

1 0

Re: [PATCH 4/6] wined3d: Prefer GLSL 1.50 shaders in draw_test_quad().
by Henri Verbeet May 29, 2017

May 29, 2017

On 29 May 2017 at 10:53, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + BOOL use_glsl_150 = gl_info->glsl_version >= 150; That doesn't work in Wine :D I wouldn't necessarily mind if it did though.

1 0

Re: [PATCH] comctl32/listview: Do not select the first list item when drawing a marquee rectangle
by Nikolay Sivov May 29, 2017

May 29, 2017

On 22.05.2017 16:02, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/comctl32/listview.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index c681451..a117f83 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -3892,6 +3892,9 @@ static void LISTVIEW_MarqueeHighlight(LISTVIEW_INFO *infoPtr, const POINT *coord > if ((scroll & SCROLL_DOWN) && (coords_orig->y >= infoPtr->rcList.bottom)) > LISTVIEW_Scroll(infoPtr, 0, (coords_orig->y - infoPtr->rcList.bottom)); > > + if (IsRectEmpty(&infoPtr->marqueeRect)) > + infoPtr->marqueeRect = rect; > + > iterator_frameditems_absolute(&old_elems, infoPtr, &infoPtr->marqueeRect); > > infoPtr->marqueeRect = rect; > I see what you mean, when you start selecting with marquee first item in report mode is always selected. This patch fixes that, but breaks ICON mode it seems - sometimes items are not selected when they are clearly intersect with marquee rectangle. Admittedly this selection mode is already funny in ICON mode, it does not use dead zones properly, so slight movement selects things, while it should check with icon rectangle when resized horizontally, and allow about half icon rectangle intersect marquee vertically before setting item state.

2 3

Re: [v5 PATCH 1/3] wined3d: Send texture updates through the command stream.
by Stefan Dösinger May 29, 2017

May 29, 2017

Am 2017-05-24 um 15:49 schrieb Masanori Kakura: > + for (j = 0; j < layer_count; ++j) > + { > + wined3d_cs_emit_blt_sub_resource(cs, > + &dst_texture->resource, j * dst_level_count + i, &box, > + &src_texture->resource, j * src_level_count + i + src_skip_levels, &box, > + 0, NULL, WINED3D_TEXF_POINT); > + } I don't like emitting new operations in the CS handler instead of doing the actual operation. Maybe this can be avoided with some refactoring of wined3d_cs_exec_blt_sub_resource?

3 3

Re: [v6 PATCH 2/3] wined3d: Add dirty region tracking.
by Marvin May 28, 2017

May 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=31231 Your paranoid android. === w1064 (64 bit visual) === visual.c:8016: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

1 0

about donat enikeev csmt on graphics tab in winecfg
by CARLOS RODRIGUEZ May 27, 2017

May 27, 2017

Hi henri I read your discussion about normal user dont need touch that However various titles needs csmt, mainly for solve graphics issues case duke nuke forever (dont show anything without csmt), resident evil 6 (only see light without csmt) Or flickering graphics case im alive, senran kagura shinovi versus, bayonetta, vanquish Resolve audio sincronization in prerenderer sequences case front mission evolved And possible many other titles Put option in winecfg could be usefull for new users I agree about you said related csmt dont be stay active for default for now, but solve before problems described Maybe can add some note in csmt like that: mainly for resolve graphics issues for now or something similar Thanks

1 0

Re: [PATCH] msvcp140: Implement _To_wide (v2).
by Stefan Dösinger May 26, 2017

May 26, 2017

Am 2017-05-26 um 13:17 schrieb Stefan Dösinger: > + return MultiByteToWideChar(CP_ACP, 0, src, -1, dst, strlen(src) + 1); Do not commit this yet, there is another version coming. The maximum length is limited to MAX_PATH, and Nikolai says the test randomly crashes on his Windows. It seems Microsoft lets interns write APIs nowadays.

1 0

Re: [PATCH] msvcp140: Implement _To_wide.
by Marvin May 26, 2017

May 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=31204 Your paranoid android. === wvistau64 (32 bit msvcp140) === msvcp140.c:492: Test failed: Got unexpected output L"\05e6\05d4\f895\f893\20ac\009f" === wvistau64 (64 bit msvcp140) === msvcp140.c:492: Test failed: Got unexpected output L"\05e6\05d4\f895\f893\20ac\009f"

1 0

Re: [PATCH] oleaut32: Add VarBstrFromDisp tests
by Marvin May 25, 2017

May 25, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=31191 Your paranoid android. === wxppro (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w2003std (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === wvistau64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w2008s64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w7u (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w7pro64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w8 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w864 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w1064 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === wvistau64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w2008s64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w7pro64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w1064 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\5540\5653\4157\4154\4155\4156\4857\6c8d\e124\8148\d8ec" oleaut32:vartype crashed (c0000374)

1 0

Re: [7/8] d3d11/tests: Add R9G9B9E5_SHAREDEXP to test_create_texture3d.
by Józef Kucia May 25, 2017

May 25, 2017

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > {DXGI_FORMAT_R8G8B8A8_UNORM, D3D11_BIND_DEPTH_STENCIL, FALSE, FALSE}, > {DXGI_FORMAT_D24_UNORM_S8_UINT, D3D11_BIND_RENDER_TARGET, FALSE, FALSE}, > {DXGI_FORMAT_D32_FLOAT, D3D11_BIND_RENDER_TARGET, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_SHADER_RESOURCE, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_RENDER_TARGET, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_DEPTH_STENCIL, FALSE, FALSE}, Please use D3D11 enum values.

1 0

Re: [6/8] d3d11/tests: Add R9G9B9E5_SHAREDEXP to test_create_texture2d.
by Józef Kucia May 25, 2017

May 25, 2017

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > {DXGI_FORMAT_D32_FLOAT, 1, D3D11_BIND_RENDER_TARGET, 0, FALSE, FALSE}, > {DXGI_FORMAT_D32_FLOAT, 1, D3D11_BIND_DEPTH_STENCIL, 0, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_SHADER_RESOURCE, 0, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_RENDER_TARGET, 0, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_DEPTH_STENCIL, 0, FALSE, FALSE}, > }; Please use D3D11 enum values.

1 0

Re: [5/8] d3d10core/tests: Add R9G9B9E5_SHAREDEXP to test_texture.
by Józef Kucia May 25, 2017

May 25, 2017

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > + static const DWORD r9g9b9e5_colors[16] = { Please try to put opening brackets on a new line (applies also to the d3d11 version).

1 0

Re: [PATCH 1/5] d3dx9/tests: Use ARRAY_SIZE in test_D3DXSHEvalDirectionalLight().
by Matteo Bruni May 24, 2017

May 24, 2017

2017-05-23 11:04 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > @@ -2908,7 +2908,7 @@ static void test_D3DXSHEvalDirectionalLight(void) > green_out = test[l].green_in; > blue_out = test[l].blue_in; > > - for (j = 0; j < 49; j++) > + for (j = 0; j < ARRAY_SIZE(red_out); ++j) red_out here is defined as a pointer, not an array.

1 0

Re: [v5 PATCH 3/3] wined3d: Update only dirty regions in wined3d_cs_exec_update_texture().
by Marvin May 24, 2017

May 24, 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=31147 Your paranoid android. === w1064 (32 bit visual) === visual.c:8016: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

1 0

Re: [PATCH] iphlpapi: Implement if_nametoindex.
by Bruno Jesus May 24, 2017

May 24, 2017

On Wed, May 24, 2017 at 7:39 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > ... > diff --git a/dlls/iphlpapi/iphlpapi_main.c b/dlls/iphlpapi/iphlpapi_main.c > index 796950e0f9..4cceb65621 100644 > --- a/dlls/iphlpapi/iphlpapi_main.c > +++ b/dlls/iphlpapi/iphlpapi_main.c > @@ -36,6 +36,9 @@ > #ifdef HAVE_RESOLV_H > # include <resolv.h> > #endif > +#ifdef HAVE_NET_IF_H > +# include <net/if.h> > +#endif > > #define NONAMELESSUNION > #define NONAMELESSSTRUCT > @@ -3208,3 +3211,12 @@ DWORD WINAPI ConvertInterfaceNameToLuidW(const WCHAR *name, NET_LUID *luid) > luid->Info.IfType = row.dwType; > return NO_ERROR; > } > + > +/****************************************************************** > + * if_nametoindex (IPHLPAPI.@) > + */ > +IF_INDEX WINAPI IPHLP_if_nametoindex(const char *name) > +{ > + TRACE("(%s)\n", name); > + return if_nametoindex(name); > +} Hi, this seems to be the ASCII version of GetAdapterIndex, can't you call getInterfaceIndexByName and avoid the new #include? Best wishes, Bruno

3 8

Re: [PATCH 2/2] winex11.drv: Implement clipboard changes tracking using xfixes extension
by Alexandre Julliard May 24, 2017

May 24, 2017

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -499,6 +499,7 @@ extern Atom systray_atom DECLSPEC_HIDDEN; > typedef BOOL (*x11drv_event_handler)( HWND hwnd, XEvent *event ); > > extern void X11DRV_register_event_handler( int type, x11drv_event_handler handler, const char *name ) DECLSPEC_HIDDEN; > +extern void X11DRV_register_XFixesSelectionNotify( int type ) DECLSPEC_HIDDEN; Is there a reason you can't use X11DRV_register_event_handler? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 2/2] regedit: Add 'Expand' and 'Collapse' options to the treeview pop-up menu
by Nikolay Sivov May 24, 2017

May 24, 2017

On 24.05.2017 11:21, Hugh McMaster wrote: > + item.mask = TVIF_CHILDREN | TVIF_HANDLE | TVIF_STATE; > + item.stateMask = TVIS_EXPANDED | TVIS_EXPANDEDONCE | TVIS_EXPANDPARTIAL; > + SendMessageW(hwndTV, TVM_GETITEMW, 0, (LPARAM)&item) Later you only test for TVIS_EXPANDED, is it necessary to request other bits?

2 1

Re: [PATCH 2/2] regedit: Add 'Expand' and 'Collapse' options to the treeview pop-up menu
by Nikolay Sivov May 24, 2017

May 24, 2017

On 24.05.2017 11:21, Hugh McMaster wrote: > + case ID_TREE_EXPAND: > + { > + HTREEITEM selected = (HTREEITEM)SendMessageW(g_pChildWnd->hTreeWnd, TVM_GETNEXTITEM, TVGN_CARET, 0); > + SendMessageW(g_pChildWnd->hTreeWnd, TVM_EXPAND, TVE_TOGGLE, (LPARAM)selected); > + break; > + } Maybe it's better to name it ID_TREE_EXPAND_COLLAPSE, since it does not only expand.

2 1

Re: [PATCH] authz: document missorted function in specfile
by Alexandre Julliard May 24, 2017

May 24, 2017

Austin English <austinenglish(a)gmail.com> writes: > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/authz/authz.spec | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/authz/authz.spec b/dlls/authz/authz.spec > index eb9e044d2a..1e9edefc59 100644 > --- a/dlls/authz/authz.spec > +++ b/dlls/authz/authz.spec > @@ -35,6 +35,8 @@ > @ stub AuthziInitializeAuditQueue > @ stub AuthziInitializeContextFromSid > @ stub AuthziLogAuditEvent > +# AuthziModifyAuditEvent2 comes before AuthziModifyAuditEvent on native, > +# even though AuthzInitializeObjectAccessAuditEvent is before AuthzInitializeObjectAccessAuditEvent2 > @ stub AuthziModifyAuditEvent2 > @ stub AuthziModifyAuditEvent > @ stub AuthziModifyAuditEventType There are many functions that aren't sorted, I don't think this warrants a comment. If you have a script for this, you may want to maintain a list of exceptions inside the script instead. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH] comctl32/listview: Do not select the first list item when drawing a marquee rectangle
by Nikolay Sivov May 23, 2017

May 23, 2017

On 22.05.2017 16:02, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/comctl32/listview.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index c681451..a117f83 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -3892,6 +3892,9 @@ static void LISTVIEW_MarqueeHighlight(LISTVIEW_INFO *infoPtr, const POINT *coord > if ((scroll & SCROLL_DOWN) && (coords_orig->y >= infoPtr->rcList.bottom)) > LISTVIEW_Scroll(infoPtr, 0, (coords_orig->y - infoPtr->rcList.bottom)); > > + if (IsRectEmpty(&infoPtr->marqueeRect)) > + infoPtr->marqueeRect = rect; > + > iterator_frameditems_absolute(&old_elems, infoPtr, &infoPtr->marqueeRect); > > infoPtr->marqueeRect = rect; > How can I reproduce this issue?

1 0

Re: [PATCH 2/2] d3d11/tests: Add additional test for occlusion query.
by Henri Verbeet May 22, 2017

May 22, 2017

On 20 May 2017 at 14:12, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + for (i = 0; i < 500; ++i) > + { > + if ((hr = ID3D11DeviceContext_GetData(context, query, NULL, 0, 0)) != S_FALSE) > + break; > + Sleep(10); > + } > + ok(hr == S_OK, "Got unexpected hr %#x.\n", hr); > + hr = ID3D11DeviceContext_GetData(context, query, &data, sizeof(data), 0); > + ok(hr == S_OK, "Got unexpected hr %#x.\n", hr); > + todo_wine ok(data.dword[0] == 0x1000 && !data.dword[1], > + "Got unexpected query result 0x%08x%08x.\n", data.dword[1], data.dword[0]); This fails about half of the time with csmt enabled: d3d11.c:4872: Test succeeded inside todo block: Got unexpected query result 0x0000000000001000.

2 2

Re: [PATCH 5/5] d2d1: Implement initial support for quadratic bezier outlines.
by Dmitry Timoshkov May 22, 2017

May 22, 2017

Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > +static void d2d_point_lerp(D2D1_POINT_2F *out, > + const D2D1_POINT_2F *a, const D2D1_POINT_2F *b, float t) > +{ > + out->x = a->x * (1.0f - t) + b->x * t; > + out->y = a->y * (1.0f - t) + b->y * t; > +} According to my investigation of a better bilinear blending (lerp) implementation the above formula is better to explicitely simplify to out->x = a->x + (b->x - a->x) * t; out->y = a->y + (b->y - a->y) * t; or even better to avoid floating point operations at all by replacing them either by fixed point math or a mmx/sse helper, which is able to considerably (x10) improve performance. -- Dmitry.

3 9

What is the best way to debug a freeze in wine?
by Derek Lesho May 22, 2017

May 22, 2017

This is my first time posting in a mailing list, so if this is the wrong place to ask or I am doing something wrong, please tell me. Anyway, In wine 2.8, GTA-V is able to be run, however there is a major bug in which any key press will freeze the game for a few seconds. However, if you bind any actions to the mouse, say mouse4 or mouse5, the issue is not present. GTA-V has also worked for people using xbox 360 controllers. I have moderate programming knowledge, and I would like to find the source of this bug, however I have no found a good way to do it yet. I have tried winedbg, however when I get a backtrace of the process, there are atleast 50 threads running and I am unsure which one is locking up the game. I would use perf, however so far I haven't figured out how to make it tell me which functions are taking up most of the time. My question is, do any of you know of good tools/techniques that would help me debug this sort of problem? It would be greatly appreciated. P.S. for any of you who are also interested in this specific problem, many error messages are sent out at a very fast speed, but when the game is frozen due to this bug, all error messages temporarily halt with the exception of these two: fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 40000000: semi-stub! fixme:keyboard:X11DRV_ActivateKeyboardLayout flags 40000000 not supported Which are output a slow interval instead until the game unfreezes at which point the console output returns back to its normal sporadic behavior. Also, here is a normal backtrace from winedbg while the issue is occuring: http://paste.ubuntu.com/24539530/

2 1

Re: [PATCH 7/7] d3dx9/tests: Use static test blob in test_effect_preshader_ops().
by Matteo Bruni May 22, 2017

May 22, 2017

2017-05-19 13:56 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: Thanks, I do think this is an improvement compared to the old tests. A few comments below. > static const struct > { > - unsigned int pos; > + const char *mnem; > + unsigned int expected_result[4]; > unsigned int result_index; > - unsigned int ins_count; > + float *result; > + D3DXVECTOR4 opvect1, opvect2, opvect3; > + unsigned int ulps; > + BOOL todo[4]; > } I assume ulps and todo are there for future tests? > + for (j = 0; j < 4; ++j) > + { > + const float *v = op_tests[i].result; Can you put the initialization of 'v' outside of the inner loop? I'm sure the compiler sees the optimization and the generated code is ultimately the same (not that it would really matter for a test anyway...) but it seems a bit nicer to do that in the "correct" block. You could also call it "result" or similar. > + todo_wine_if(op_tests[i].todo[j]) > + ok(compare_float(v[j], ((float *)op_tests[i].expected_result)[j], op_tests[i].ulps), > + "Operation %s, component %u, expected %#x (%g), got %#x (%g).\n", op_tests[i].mnem, > + j, op_tests[i].expected_result[j], ((float *)op_tests[i].expected_result)[j], > + ((unsigned int *)v)[j], v[j]); Just an idea, maybe use %.8e to print the float values? Mostly for consistency with the usual d3d stuff, although in this case it doesn't matter much since you're also printing the bit encoding in hex. Also you can clean the ok() a bit by defining a "const float *expected_float;" variable (similarly to test_effect_preshader_relative_addressing()). BTW, notice that you're currently casting away const from v.

2 2

Re: [v2 2/2] d3d11/tests: Add tests for SM5 instructions gather4_c/gather4_po_c
by Henri Verbeet May 22, 2017

May 22, 2017

On 19 May 2017 at 14:31, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > Signed-off-by: Sven Hesse <drmccoy(a)drmccoy.de> > --- > dlls/d3d11/tests/d3d11.c | 230 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 230 insertions(+) > This fails here: d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 1.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}. d3d11.c:19637: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}. d3d11.c:19658: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00}.

2 2

Re: [PATCH 1/2] kernel32/tests: Added more PeedNamedPipe tests.
by Marvin May 22, 2017

May 22, 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=31084 Your paranoid android. === w7u (32 bit pipe) === pipe.c:2631: Test failed: FlushFileBuffers failed: 0

1 0

D3D command stream patches for testing
by A.S. May 21, 2017

May 21, 2017

Hello, I have low frame rate (~16-18) problem in Unreal Tournament 3, wine 2.8. "stat fps", "stat ld" commands were enabled in game console and showed relation that fps drop after 'static mesh tris' goes higher than >200 000 So I applied patchset from https://www.winehq.org/pipermail/wine-devel/2013-September/101116.html to wine 1.7 with CXXFLAGS -o3 -m native, and tested it. Yes, finnaly my fps imroves to ~30 on same maps where it was lower before. Thank you Stefan. same issue was reported by many unreal engine 3 players on windows, so AFAIK this could be ue3 problem itself. the patchset could be step in right direction, or workaround, but not a total fix, cuz even minimal ~30 frame rate is lower than expected on Core2Duo, gf GTS450, when other games works better. Thanks, Lex.

1 0

Re: [PATCH 2/2] kernel32/tests: Test bytes left in PeekNamedPipe().
by Marvin May 21, 2017

May 21, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=31073 Your paranoid android. === wvistau64 (64 bit pipe) === pipe.c:356: Test failed: peek3 got -21 bytes left pipe.c:395: Test failed: peek4 got -21 bytes left === w2008s64 (64 bit pipe) === pipe.c:356: Test failed: peek3 got -21 bytes left pipe.c:395: Test failed: peek4 got -21 bytes left === w7pro64 (64 bit pipe) === pipe.c:356: Test failed: peek3 got -21 bytes left pipe.c:395: Test failed: peek4 got -21 bytes left === w864 (64 bit pipe) === pipe.c:356: Test failed: peek3 got -21 bytes left pipe.c:395: Test failed: peek4 got -21 bytes left === w1064 (64 bit pipe) === pipe.c:356: Test failed: peek3 got -21 bytes left pipe.c:395: Test failed: peek4 got -21 bytes left

3 2

Re: [PATCH] wined3d: Add Brian Paul recognize code
by Henri Verbeet May 19, 2017

May 19, 2017

On 16 May 2017 at 16:09, Jarkko Korpi <jarkko_korpi(a)hotmail.com> wrote: > This is for bug #42538 > As explained in that bug, I don't object to adding this in principle, but would still like to see how this can be triggered in practice.

1 0

Re: [PATCH V3] wined3d: Add more gl_vendor_string codes for amd cards
by Henri Verbeet May 19, 2017

May 19, 2017

On 16 May 2017 at 15:58, Jarkko Korpi <jarkko_korpi(a)hotmail.com> wrote: > @@ -1815,7 +1815,9 @@ static enum wined3d_pci_vendor wined3d_guess_card_vendor(const char *gl_vendor_s > || strstr(gl_renderer, "R200") > || strstr(gl_renderer, "R300") > || strstr(gl_renderer, "R600") > - || strstr(gl_renderer, "R700")) > + || strstr(gl_renderer, "R700") > + || strstr(gl_renderer, "R800") > + || strstr(gl_renderer, "R900")) Which driver reports these? Please use git send-email for submitting patches.

1 0

Re: [PATCH 6/8] wined3d: Generate code for hull shaders.
by Henri Verbeet May 19, 2017

May 19, 2017

On 18 May 2017 at 15:19, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -228,6 +228,7 @@ struct glsl_shader_prog_link > { > struct wine_rb_entry program_lookup_entry; > struct glsl_vs_program vs; > + struct glsl_vs_program hs; Is that intentional?

2 1

Re: [2/2] d3d11/tests: Add tests for SM5 instructions gather4_c/gather4_po_c
by Józef Kucia May 19, 2017

May 19, 2017

On Fri, May 19, 2017 at 2:50 AM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > + if (!init_test_context(&test_context, NULL)) > + return; > + > + device = test_context.device; > + context = test_context.immediate_context; > + > + if (ID3D11Device_GetFeatureLevel(device) < D3D_FEATURE_LEVEL_11_0) > + { > + skip("Shader model 5 required for gather4_c/gather4_po_c.\n"); > + release_test_context(&test_context); > + return; > + } You should just pass the feature level to init_test_context(), and it will skip the test for you. > + > + texture_desc.Format = DXGI_FORMAT_D32_FLOAT; > + texture_desc.BindFlags = D3D11_BIND_SHADER_RESOURCE; > + hr = ID3D11Device_CreateTexture2D(device, &texture_desc, &resource_data, &texture); > + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > + hr = ID3D11Device_CreateShaderResourceView(device, (ID3D11Resource *)texture, NULL, &srv); The D32_FLOAT format cannot be used as SRV. You have to create the texture with format DXGI_FORMAT_R32_TYPELESS, and then use DXGI_FORMAT_R32_FLOAT for SRV. I think it may be interesting to test with D3D11_BIND_DEPTH_STENCIL and without D3D11_BIND_DEPTH_STENCIL because wined3d behaves a bit differently when depth stencil is enabled. > + ok(SUCCEEDED(hr), "Fialed to create shader resource view, hr %#x.\n", hr); Typo. > + ID3D11DeviceContext_PSSetSamplers(context, 0, 1, &sampler); You don't need to set samplers multiple times. It can be done once, after the sampler state is created.

1 0

Re: [1/2] wined3d: Implement SM5 gather4_po_c opcode.
by Józef Kucia May 19, 2017

May 19, 2017

On Fri, May 19, 2017 at 2:50 AM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > - resource_param_idx = ins->handler_idx == WINED3DSIH_GATHER4_PO ? 2 : 1; > + resource_param_idx = (ins->handler_idx == WINED3DSIH_GATHER4_PO || ins->handler_idx == WINED3DSIH_GATHER4_PO_C) ? 2 : 1; Please avoid lines longer than 120 characters in D3D code. > resource_idx = ins->src[resource_param_idx].reg.idx[0].offset; > sampler_idx = ins->src[resource_param_idx + 1].reg.idx[0].offset; > component_idx = shader_glsl_swizzle_get_component(ins->src[resource_param_idx + 1].swizzle, 0); > @@ -5878,8 +5879,12 @@ static void shader_glsl_gather4(const struct wined3d_shader_instruction *ins) > { > shader_glsl_add_src_param(ins, &ins->src[3], WINED3DSP_WRITEMASK_0, &compare_param); > shader_addline(buffer, ", %s", compare_param.param_str); > + } else if (ins->handler_idx == WINED3DSIH_GATHER4_PO_C) > + { > + shader_glsl_add_src_param(ins, &ins->src[4], WINED3DSP_WRITEMASK_0, &compare_param); > + shader_addline(buffer, ", %s", compare_param.param_str); Please put the closing bracket on its own line in order to match existing D3D coding style. Also, you may merge "if" statements: if (ins->handler_idx == WINED3DSIH_GATHER4_C || ins->handler_idx == WINED3DSIH_GATHER4_PO_C) { shader_glsl_add_src_param(ins, &ins->src[resource_param_idx + 2], WINED3DSP_WRITEMASK_0, &compare_param); shader_addline(buffer, ", %s", compare_param.param_str); } > - else if (ins.handler_idx == WINED3DSIH_GATHER4_PO) > + else if (ins.handler_idx == WINED3DSIH_GATHER4_PO > + || ins.handler_idx == WINED3DSIH_GATHER4_PO_C) > + > { Please remove the empty line.

1 0

Re: Alexandre Julliard : gdi32: Return more meaningful data in the null driver GetDeviceCaps implementation.
by Dmitry Timoshkov May 19, 2017

May 19, 2017

Alexandre Julliard <julliard(a)winehq.org> wrote: > + case BITSPIXEL: return 32; Shouldn't BITSPIXEL be also fetched from dev->hdc like the values below? > + case NUMCOLORS: > + bpp = GetDeviceCaps( dev->hdc, BITSPIXEL ); > + return (bpp > 8) ? -1 : (1 << bpp); > + case COLORRES: > + /* The observed correspondence between BITSPIXEL and COLORRES is: > + * BITSPIXEL: 8 -> COLORRES: 18 > + * BITSPIXEL: 16 -> COLORRES: 16 > + * BITSPIXEL: 24 -> COLORRES: 24 > + * BITSPIXEL: 32 -> COLORRES: 24 */ > + bpp = GetDeviceCaps( dev->hdc, BITSPIXEL ); > + return (bpp <= 8) ? 18 : min( 24, bpp ); -- Dmitry.

2 3

Re: [PATCH 1/3] msvcp: Implement the wchar version of _Open_dir.
by Piotr Caban May 19, 2017

May 19, 2017

Hi Stefan, On 05/18/17 13:33, Stefan Dösinger wrote: > +/* ??_Open_dir(a)sys@tr2(a)std@@YAPAXPA_WPB_WAAHAAW4file_type(a)123@@Z */ > +/* ??_Open_dir(a)sys@tr2(a)std@@YAPEAXPEA_WPEB_WAEAHAEAW4file_type(a)123@@Z */ > +void* __cdecl tr2_sys__Open_dir_wchar(wchar_t* target, wchar_t const* dest, int* err_code, enum file_type* type) > { > HANDLE handle; > - WIN32_FIND_DATAA data; > - char temppath[MAX_PATH]; > - > - TRACE("(%p %s %p %p)\n", target, debugstr_a(dest), err_code, type); > - if(strlen(dest) > MAX_PATH - 3) { > + WIN32_FIND_DATAW data; > + wchar_t temppath[MAX_PATH]; > + static const wchar_t dot[] = {'.', 0}; > + static const wchar_t dotdot[] = {'.', '.', 0}; > + static const wchar_t asterisk[] = {'\\', '*', 0}; > + > + TRACE("(%p %s %p %p)\n", target, debugstr_w(dest), err_code, type); > + if(wcslen(dest) > MAX_PATH - 3) { > *err_code = ERROR_BAD_PATHNAME; > return NULL; > } Could you please check if there really is such a length limit in wchar version of the function? > > +/* ?_Open_dir(a)sys@tr2(a)std@@YAPAXAAY0BAE(a)DPBDAAHAAW4file_type@123@@Z */ > +/* ?_Open_dir(a)sys@tr2(a)std@@YAPEAXAEAY0BAE(a)DPEBDAEAHAEAW4file_type@123@@Z */ > +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* err_code, enum file_type* type) > +{ > + void *handle; > + size_t len; > + wchar_t target_w[MAX_PATH]; > + wchar_t *dest_w = NULL; > + > + TRACE("(%p %s %p %p)\n", target, debugstr_a(dest), err_code, type); > + > + if (dest) > + { > + len = strlen(dest) + 1; > + dest_w = malloc(sizeof(*dest_w) * len); You don't need to allocate dest_w dynamically. Its length is limited to ~MAX_PATH anyway. Thanks, Piotr

2 6

Re: [2/2] d3d11/tests: Add tests for SM5 instructions gather4_c/gather4_po_c
by Marvin May 19, 2017

May 19, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=31043 Your paranoid android. === w7u (32 bit d3d11) === d3d11.c:19621: Test failed: Failed to create texture, hr 0x80070057. d3d11.c:19623: Test failed: Fialed to create shader resource view, hr 0x80070057. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. 094c:d3d11: unhandled exception c0000005 at 00413F16 === w7pro64 (32 bit d3d11) === d3d11.c:19621: Test failed: Failed to create texture, hr 0x80070057. d3d11.c:19623: Test failed: Fialed to create shader resource view, hr 0x80070057. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. 07e0:d3d11: unhandled exception c0000005 at 00413F16 === w8 (32 bit d3d11) === d3d11.c:19621: Test failed: Failed to create texture, hr 0x80070057. d3d11.c:19623: Test failed: Fialed to create shader resource view, hr 0x80070057. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. 0fd0:d3d11: unhandled exception c0000005 at 00413F16 === w864 (32 bit d3d11) === d3d11.c:19621: Test failed: Failed to create texture, hr 0x80070057. d3d11.c:19623: Test failed: Fialed to create shader resource view, hr 0x80070057. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. 08b0:d3d11: unhandled exception c0000005 at 00413F16 === w1064 (32 bit d3d11) === d3d11.c:19621: Test failed: Failed to create texture, hr 0x80070057. d3d11.c:19623: Test failed: Fialed to create shader resource view, hr 0x80070057. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. 0db0:d3d11: unhandled exception c0000005 at 00413F16 === w7pro64 (64 bit d3d11) === d3d11.c:19621: Test failed: Failed to create texture, hr 0x80070057. d3d11.c:19623: Test failed: Fialed to create shader resource view, hr 0x80070057. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. 0854:d3d11: unhandled exception c0000005 at 0000000000412BB7 === w864 (64 bit d3d11) === d3d11.c:19621: Test failed: Failed to create texture, hr 0x80070057. d3d11.c:19623: Test failed: Fialed to create shader resource view, hr 0x80070057. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. 0f8c:d3d11: unhandled exception c0000005 at 0000000000412BB7 === w1064 (64 bit d3d11) === d3d11.c:19621: Test failed: Failed to create texture, hr 0x80070057. d3d11.c:19623: Test failed: Fialed to create shader resource view, hr 0x80070057. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19648: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 0.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {0.00000000e+000, 1.00000000e+000, 1.00000000e+000, 0.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. d3d11.c:19670: Test failed: Got {0.00000000e+000, 0.00000000e+000, 0.00000000e+000, 0.00000000e+000}, expected {1.00000000e+000, 1.00000000e+000, 1.00000000e+000, 1.00000000e+000}. 02b8:d3d11: unhandled exception c0000005 at 0000000000412BB7

1 0

Re: [2/3] wsdapi: Implement AddNamespace, AddNameToNamespace.
by Alexandre Julliard May 18, 2017

May 18, 2017

Owen Rudge <orudge(a)codeweavers.com> writes: > +static LPWSTR generate_namespace_prefix(struct list *namespaces, void *parentMemoryBlock, LPCWSTR uri) > +{ > + WCHAR formatString[] = { 'u','n','%','d', 0 }; > + WCHAR suggestedPrefix[7]; > + int i; > + > + ZeroMemory(suggestedPrefix, sizeof(suggestedPrefix)); > + > + /* Find a unique prefix */ > + for (i = 0; i < 1000; i++) > + { > + wsprintfW(suggestedPrefix, formatString, i); > + > + if (is_prefix_unique(namespaces, suggestedPrefix)) > + { > + return duplicate_string(parentMemoryBlock, suggestedPrefix); > + } > + } This looks extremely inefficient. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] comctl32/listview: When adding a scrollbar, update the other one.
by Alex Henrie May 18, 2017

May 18, 2017

2017-05-18 4:11 GMT-06:00 Nikolay Sivov <nsivov(a)codeweavers.com>: > From: Alex Henrie <alexhenrie24(a)gmail.com> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > Minor modifications from original patch - fixed length loop instead of repeated calls, > and changed subject to have component in front. > > dlls/comctl32/listview.c | 78 +++++++++++++++++++++++++++++++----------------- > 1 file changed, 50 insertions(+), 28 deletions(-) Looks good to me, thanks. -Alex

1 0

Re: [PATCH v3] d3dx9: Match native out of bounds array selector index handling.
by Marvin May 18, 2017

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

1 0

Re: [PATCH 6/9] combase: sort specfile
by Alexandre Julliard May 18, 2017

May 18, 2017

Austin English <austinenglish(a)gmail.com> writes: > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/combase/combase.spec | 128 +++++++++++++++++++++++----------------------- > 1 file changed, 64 insertions(+), 64 deletions(-) Please always confirm that they are sorted on Windows, many of these look like they might be ordinal exports. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] msvcp: Implement the wchar version of _Open_dir.
by Piotr Caban May 18, 2017

May 18, 2017

On 05/18/17 13:33, Stefan Dösinger wrote: > + WideCharToMultiByte(CP_ACP, 0, target_w, -1, target, wcslen(target_w) + 1, NULL, NULL); You can use MAX_PATH here instead of wcslen(target_w)+1. Thanks, Piotr

1 0

Re: Avoid using isspace()/isdigit() for WCHARs.
by Hugh McMaster May 18, 2017

May 18, 2017

On Thursday, 18 May 2017 6:16 PM, Hans Leidekker wrote: > +/* > +** WCHAR safe version of isdigit() > +*/ > +static inline int isDigit(WCHAR c) > +{ > + return c >= '0' && c <= '9'; > +} > + > +/* > +** WCHAR safe version of isspace(), except '\r' > +*/ > +static inline int isSpace(WCHAR c) > +{ > + return c == ' ' || c == '\t' || c == '\n' || c == '\f'; > +} Why not just use Wine's inbuilt inline functions? isdigitW() and isspaceW() are in wine/unicode.h, which is already included in msi/tokenize.c.

2 1

Re: [PATCH] kernel32: add AddDllDirectory stub
by Hugh McMaster May 18, 2017

May 18, 2017

On Thursday, 18 May 2017 9:00 AM, Austin English wrote: > > +/************************************************************************* > + * AddDllDirectory (KERNEL32.@) > + */ > +BOOL WINAPI AddDllDirectory(WCHAR *directory) > +{ > + FIXME("(%s): stub\n", wine_dbgstr_w(directory)); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return FALSE; > +} This function actually returns DLL_DIRECTORY_COOKIE, which is a typedef'd void *. The actual definition is in libloaderapi.h, which Wine doesn't have. And, according to MSDN, directory should be const WCHAR *. -- Hugh McMaster

1 0

Re: [PATCH v2] comctl32/tests: Add tests for mouse right-click in a treeview control
by Nikolay Sivov May 17, 2017

May 17, 2017

On 16.05.2017 12:05, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/comctl32/tests/treeview.c | 79 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/dlls/comctl32/tests/treeview.c b/dlls/comctl32/tests/treeview.c > index 43de61c..ca3366d 100644 > --- a/dlls/comctl32/tests/treeview.c > +++ b/dlls/comctl32/tests/treeview.c > @@ -54,6 +54,21 @@ static BOOL g_v6; > static struct msg_sequence *sequences[NUM_MSG_SEQUENCES]; > static struct msg_sequence *item_sequence[1]; > > +static void flush_events(void) > +{ > + MSG msg; > + int diff = 200; > + int min_timeout = 100; > + DWORD time = GetTickCount() + diff; > + > + while (diff > 0) > + { > + if (MsgWaitForMultipleObjects(0, NULL, FALSE, min_timeout, QS_ALLINPUT) == WAIT_TIMEOUT) break; > + while (PeekMessageA(&msg, 0, 0, 0, PM_REMOVE)) DispatchMessageA(&msg); > + diff = time - GetTickCount(); > + } > +} > + > static const struct message FillRootSeq[] = { > { TVM_INSERTITEMA, sent }, > { TVM_INSERTITEMA, sent }, > @@ -201,6 +216,13 @@ static const struct message test_get_set_unicodeformat_seq[] = { > { 0 } > }; > > +static const struct message test_right_click_seq[] = { > + { WM_RBUTTONDOWN, sent|wparam, MK_RBUTTON }, > + { WM_CAPTURECHANGED, sent|defwinproc }, > + { TVM_GETNEXTITEM, sent|wparam|lparam|defwinproc, TVGN_CARET, 0 }, > + { 0 } > +}; > + > static const struct message parent_expand_seq[] = { > { WM_NOTIFY, sent|id, 0, 0, TVN_ITEMEXPANDINGA }, > { WM_NOTIFY, sent|id, 0, 0, TVN_ITEMEXPANDEDA }, > @@ -342,6 +364,12 @@ static const struct message parent_vk_return_seq[] = { > { 0 } > }; > > +static const struct message parent_right_click_seq[] = { > + { WM_NOTIFY, sent|id, 0, 0, NM_RCLICK }, > + { WM_CONTEXTMENU, sent }, > + { 0 } > +}; > + > static HWND hMainWnd; > > static HTREEITEM hRoot, hChild; > @@ -1296,6 +1324,13 @@ static LRESULT CALLBACK parent_wnd_proc(HWND hWnd, UINT message, WPARAM wParam, > } > break; > } > + case NM_RCLICK: > + { > + HTREEITEM selected = (HTREEITEM)SendMessageA(((NMHDR *)lParam)->hwndFrom, > + TVM_GETNEXTITEM, TVGN_CARET, 0); > + ok(selected == hChild, "child item should still be selected\n"); > + break; > + } > } > } > break; > @@ -2583,6 +2618,49 @@ todo_wine > DestroyWindow(hwnd); > } > > +static void test_right_click(void) > +{ > + HWND hTree; > + HTREEITEM selected; > + RECT rc; > + LRESULT result; > + POINT pt; > + > + hTree = create_treeview_control(0); > + fill_tree(hTree); > + > + SendMessageA(hTree, TVM_ENSUREVISIBLE, 0, (LPARAM)hChild); > + SendMessageA(hTree, TVM_SELECTITEM, TVGN_CARET, (LPARAM)hChild); > + selected = (HTREEITEM)SendMessageA(hTree, TVM_GETNEXTITEM, TVGN_CARET, 0); > + ok(selected == hChild, "child item not selected\n"); > + > + *(HTREEITEM *)&rc = hRoot; > + result = SendMessageA(hTree, TVM_GETITEMRECT, TRUE, (LPARAM)&rc); > + ok(result, "TVM_GETITEMRECT failed\n"); > + > + flush_events(); > + > + pt.x = rc.left + (rc.right - rc.left) / 2; > + pt.y = rc.top + (rc.bottom - rc.top) / 2; Could you please simplify this to "(a + b) / 2"? Other than that, it looks good.

1 0

Re: [PATCH] appwiz.cpl: Use sha256 checksums to validate Mono/Gecko downloads.
by Alexandre Julliard May 17, 2017

May 17, 2017

Alex Henrie <alexhenrie24(a)gmail.com> writes: > + if(BCryptOpenAlgorithmProvider(&alg, BCRYPT_SHA256_ALGORITHM, MS_PRIMITIVE_PROVIDER, 0)) > + goto end; > + if(BCryptCreateHash(alg, &hash, NULL, 0, NULL, 0, 0)) > + goto end; > + if(BCryptHashData(hash, (UCHAR *)file_map, size, 0)) > + goto end; > + if(BCryptFinishHash(hash, sha, sizeof(sha), 0)) > + goto end; > > UnmapViewOfFile(file_map); You are leaking file_map on error. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] user32: add GetPhysicalCursorPos/SetPhysicalCursorPos stubs (try 3)
by Ken Thomases May 17, 2017

May 17, 2017

On May 16, 2017, at 12:38 PM, Austin English <austinenglish(a)gmail.com> wrote: > --- > dlls/user32/input.c | 19 +++++++++++++++++++ > dlls/user32/user32.spec | 2 ++ > 2 files changed, 21 insertions(+) Looks good to me. -Ken

1 0

Re: [PATCH 4/6 v2] reg/tests: Add tests for importing REG_NONE data
by Marvin May 17, 2017

May 17, 2017

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=31013 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [v8 PATCH] oleaut32: Improve support for IDispatch in VarCat
by Jacek Caban May 17, 2017

May 17, 2017

Hi Alistair, On 12.05.2017 05:56, Alistair Leslie-Hughes wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=27106 > > v6 - Simplify the code when the Variant cannot be coerced. > v7 - Fix copy/paste bug in return value. > v8 - Fixed failed test. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oleaut32/tests/vartest.c | 217 ++++++++++++++++++++++++++++++++++++++++++ > dlls/oleaut32/variant.c | 52 +++------- > 2 files changed, 229 insertions(+), 40 deletions(-) > > diff --git a/dlls/oleaut32/tests/vartest.c b/dlls/oleaut32/tests/vartest.c > index 0e86ffb..f4224dc 100644 > --- a/dlls/oleaut32/tests/vartest.c > +++ b/dlls/oleaut32/tests/vartest.c > @@ -97,6 +97,150 @@ static BOOL has_i8; > #define R8_MAX DBL_MAX > #define R8_MIN DBL_MIN > > +#define DEFINE_EXPECT(func) \ > + static BOOL expect_ ## func = FALSE, called_ ## func = FALSE > + > +#define SET_EXPECT(func) \ > + do { called_ ## func = FALSE; expect_ ## func = TRUE; } while(0) > + > +#define CHECK_EXPECT2(func) \ > + do { \ > + ok(expect_ ##func, "unexpected call " #func "\n"); \ > + called_ ## func = TRUE; \ > + }while(0) > + > +#define CHECK_EXPECT(func) \ > + do { \ > + CHECK_EXPECT2(func); \ > + expect_ ## func = FALSE; \ > + }while(0) > + > +#define CHECK_CALLED(func) \ > + do { \ > + ok(called_ ## func, "expected " #func "\n"); \ > + expect_ ## func = called_ ## func = FALSE; \ > + }while(0) > + > +DEFINE_EXPECT(dispatch_invoke); > + > +typedef struct > +{ > + IDispatch IDispatch_iface; > + VARTYPE vt; > + HRESULT result; > +} DummyDispatch; > + > +static inline DummyDispatch *impl_from_IDispatch(IDispatch *iface) > +{ > + return CONTAINING_RECORD(iface, DummyDispatch, IDispatch_iface); > +} > + > +static ULONG WINAPI DummyDispatch_AddRef(IDispatch *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI DummyDispatch_Release(IDispatch *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI DummyDispatch_QueryInterface(IDispatch *iface, > + REFIID riid, > + void** ppvObject) > +{ > + *ppvObject = NULL; > + > + if (IsEqualIID(riid, &IID_IDispatch) || > + IsEqualIID(riid, &IID_IUnknown)) > + { > + *ppvObject = iface; > + IDispatch_AddRef(iface); > + } > + > + return *ppvObject ? S_OK : E_NOINTERFACE; > +} > + > +static HRESULT WINAPI DummyDispatch_GetTypeInfoCount(IDispatch *iface, UINT *pctinfo) > +{ > + ok(0, "Unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI DummyDispatch_GetTypeInfo(IDispatch *iface, UINT tinfo, LCID lcid, ITypeInfo **ti) > +{ > + ok(0, "Unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI DummyDispatch_GetIDsOfNames(IDispatch *iface, REFIID riid, LPOLESTR *names, > + UINT cnames, LCID lcid, DISPID *dispid) > +{ > + ok(0, "Unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI DummyDispatch_Invoke(IDispatch *iface, > + DISPID dispid, REFIID riid, > + LCID lcid, WORD wFlags, > + DISPPARAMS *params, > + VARIANT *res, > + EXCEPINFO *ei, > + UINT *arg_err) > +{ > + DummyDispatch *This = impl_from_IDispatch(iface); > + > + CHECK_EXPECT(dispatch_invoke); > + > + ok(dispid == DISPID_VALUE, "got dispid %d\n", dispid); > + ok(IsEqualIID(riid, &IID_NULL), "go riid %s\n", wine_dbgstr_guid(riid)); > + ok(wFlags == DISPATCH_PROPERTYGET, "Flags wrong\n"); > + > + ok(params->rgvarg == NULL, "got %p\n", params->rgvarg); > + ok(params->rgdispidNamedArgs == NULL, "got %p\n", params->rgdispidNamedArgs); > + ok(params->cArgs == 0, "got %d\n", params->cArgs); > + ok(params->cNamedArgs == 0, "got %d\n", params->cNamedArgs); > + > + ok(res != NULL, "got %p\n", res); > + ok(V_VT(res) == VT_EMPTY, "got %d\n", V_VT(res)); > + ok(ei == NULL, "got %p\n", ei); > + ok(arg_err == NULL, "got %p\n", arg_err); > + > + if (FAILED(This->result)) > + return This->result; > + > + V_VT(res) = This->vt; > + if (This->vt == VT_UI1) > + V_UI1(res) = 34; > + else if (This->vt == VT_NULL) > + { > + V_VT(res) = VT_NULL; > + V_BSTR(res) = NULL; > + } > + else > + memset(res, 0, sizeof(*res)); > + > + return S_OK; > +} > + > +static const IDispatchVtbl DummyDispatch_VTable = > +{ > + DummyDispatch_QueryInterface, > + DummyDispatch_AddRef, > + DummyDispatch_Release, > + DummyDispatch_GetTypeInfoCount, > + DummyDispatch_GetTypeInfo, > + DummyDispatch_GetIDsOfNames, > + DummyDispatch_Invoke > +}; > + > +static void init_test_dispatch(VARTYPE vt, DummyDispatch *dispatch) > +{ > + dispatch->IDispatch_iface.lpVtbl = &DummyDispatch_VTable; > + dispatch->vt = vt; > + dispatch->result = S_OK; > +} > + > typedef struct IRecordInfoImpl > { > IRecordInfo IRecordInfo_iface; > @@ -5607,6 +5751,7 @@ static void test_VarCat(void) > HRESULT hres; > HRESULT expected_error_num; > int cmp; > + DummyDispatch dispatch; > > CHECKPTR(VarCat); > > @@ -5941,6 +6086,78 @@ static void test_VarCat(void) > VariantClear(&result); > VariantClear(&expected); > > + /* Dispatch conversion */ > + init_test_dispatch(VT_NULL, &dispatch); > + V_VT(&left) = VT_DISPATCH; > + V_DISPATCH(&left) = &dispatch.IDispatch_iface; > + > + V_VT(&expected) = VT_BSTR; > + V_BSTR(&expected)= SysAllocString(sz_empty); > + > + SET_EXPECT(dispatch_invoke); > + hres = VarCat(&left, &right, &result); > + ok(hres == S_OK, "got 0x%08x\n", hres); > + ok(V_VT(&result) == VT_BSTR, "got %d\n", V_VT(&result)); > + ok(SysStringLen(V_BSTR(&result)) == 0, "got %d\n", SysStringLen(V_BSTR(&result))); > + CHECK_CALLED(dispatch_invoke); > + ok(VarCmp(&result,&expected,lcid,0) == VARCMP_EQ, "VarCat: DISPATCH concat with EMPTY did not return empty VT_BSTR\n"); This VarCmp doesn't test any more than you tested a few lines earlier. I'd remove it. > + > + VariantClear(&left); > + VariantClear(&right); > + VariantClear(&result); > + VariantClear(&expected); > + > + init_test_dispatch(VT_NULL, &dispatch); > + V_VT(&right) = VT_DISPATCH; > + V_DISPATCH(&right) = &dispatch.IDispatch_iface; > + > + SET_EXPECT(dispatch_invoke); > + hres = VarCat(&left, &right, &result); > + ok(hres == S_OK, "got 0x%08x\n", hres); > + ok(V_VT(&result) == VT_BSTR, "got %d\n", V_VT(&result)); > + ok(SysStringLen(V_BSTR(&result)) == 0, "got %d\n", SysStringLen(V_BSTR(&result))); > + CHECK_CALLED(dispatch_invoke); > + ok(VarCmp(&result,&expected,lcid,0) == VARCMP_EQ, "VarCat: DISPATCH concat with EMPTY did not return empty VT_BSTR\n"); Same here. > + > + VariantClear(&left); > + VariantClear(&right); > + VariantClear(&result); > + VariantClear(&expected); > + > + init_test_dispatch(VT_UI1, &dispatch); > + V_VT(&right) = VT_DISPATCH; > + V_DISPATCH(&right) = &dispatch.IDispatch_iface; > + > + V_VT(&expected) = VT_BSTR; > + V_VT(&left) = VT_BSTR; > + V_BSTR(&left) = SysAllocString(sz12); > + V_BSTR(&expected) = SysAllocString(sz1234); > + SET_EXPECT(dispatch_invoke); > + hres = pVarCat(&left,&right,&result); > + ok(hres == S_OK, "VarCat failed with error 0x%08x\n", hres); > + CHECK_CALLED(dispatch_invoke); > + ok(VarCmp(&result,&expected,lcid,0) == VARCMP_EQ, "VarCat: VT_DISPATCH concat with VT_BSTR failed to return correct result\n"); I'd replace that with explicit result tests, using strcmp_wa(). > + > + VariantClear(&left); > + VariantClear(&right); > + VariantClear(&result); > + VariantClear(&expected); > + > + init_test_dispatch(VT_NULL, &dispatch); > + dispatch.result = E_OUTOFMEMORY; > + V_VT(&right) = VT_DISPATCH; > + V_DISPATCH(&right) = &dispatch.IDispatch_iface; > + > + SET_EXPECT(dispatch_invoke); > + hres = VarCat(&left, &right, &result); > + todo_wine ok(hres == E_OUTOFMEMORY, "got 0x%08x\n", hres); > + CHECK_CALLED(dispatch_invoke); This test shows that there is still something wrong with error handling with your patch. > + > + VariantClear(&left); > + VariantClear(&right); > + VariantClear(&result); > + VariantClear(&expected); > + > /* Test boolean conversion */ > V_VT(&left) = VT_BOOL; > V_BOOL(&left) = VARIANT_TRUE; > diff --git a/dlls/oleaut32/variant.c b/dlls/oleaut32/variant.c > index 17f753a..aa86be0 100644 > --- a/dlls/oleaut32/variant.c > +++ b/dlls/oleaut32/variant.c > @@ -2605,30 +2605,16 @@ HRESULT WINAPI VarCat(LPVARIANT left, LPVARIANT right, LPVARIANT out) > else > V_BSTR(&bstrvar_left) = SysAllocString(str_false); > } Note that V_BOOL case could also be handled by VariantChangeTypeEx if you used VARIANT_ALPHABOOL flag. > - /* Fill with empty string for later concat with right side */ > - else if (leftvt == VT_NULL) > - { > - V_VT(&bstrvar_left) = VT_BSTR; > - V_BSTR(&bstrvar_left) = SysAllocString(sz_empty); > - } > else > { > + /* The value may not be able to be coerced, ie. VT_NULL */ > hres = VariantChangeTypeEx(&bstrvar_left,left,0,0,VT_BSTR); > - if (hres != S_OK) { > - VariantClear(&bstrvar_left); > - VariantClear(&bstrvar_right); > - if (leftvt == VT_NULL && (rightvt == VT_EMPTY || > - rightvt == VT_NULL || rightvt == VT_I2 || > - rightvt == VT_I4 || rightvt == VT_R4 || > - rightvt == VT_R8 || rightvt == VT_CY || > - rightvt == VT_DATE || rightvt == VT_BSTR || > - rightvt == VT_BOOL || rightvt == VT_DECIMAL || > - rightvt == VT_I1 || rightvt == VT_UI1 || > - rightvt == VT_UI2 || rightvt == VT_UI4 || > - rightvt == VT_I8 || rightvt == VT_UI8 || > - rightvt == VT_INT || rightvt == VT_UINT)) > - return DISP_E_BADVARTYPE; Removing dead code should be a separated patch. > + if (hres != S_OK && hres != DISP_E_TYPEMISMATCH) > return hres; > + else if(FAILED(hres)) > + { > + V_VT(&bstrvar_left) = VT_BSTR; > + V_BSTR(&bstrvar_left) = SysAllocString(sz_empty); > } Something like: if (hres == DISP_E_TYPEMISMATCH) { // set empty string }else if(hres != S_OK) return hres; would be cleaner. However, more importantly, this needs more tests. There are more cases than IDispatch when your patch changes behaviour, so we need to make sure what behaviour is desired first. > } > } > @@ -2645,30 +2631,16 @@ HRESULT WINAPI VarCat(LPVARIANT left, LPVARIANT right, LPVARIANT out) > else > V_BSTR(&bstrvar_right) = SysAllocString(str_false); > } > - /* Fill with empty string for later concat with right side */ > - else if (rightvt == VT_NULL) > - { > - V_VT(&bstrvar_right) = VT_BSTR; > - V_BSTR(&bstrvar_right) = SysAllocString(sz_empty); > - } > else > { > + /* The value may not be able to be coerced, ie. VT_NULL */ > hres = VariantChangeTypeEx(&bstrvar_right,right,0,0,VT_BSTR); > - if (hres != S_OK) { > - VariantClear(&bstrvar_left); > - VariantClear(&bstrvar_right); > - if (rightvt == VT_NULL && (leftvt == VT_EMPTY || > - leftvt == VT_NULL || leftvt == VT_I2 || > - leftvt == VT_I4 || leftvt == VT_R4 || > - leftvt == VT_R8 || leftvt == VT_CY || > - leftvt == VT_DATE || leftvt == VT_BSTR || > - leftvt == VT_BOOL || leftvt == VT_DECIMAL || > - leftvt == VT_I1 || leftvt == VT_UI1 || > - leftvt == VT_UI2 || leftvt == VT_UI4 || > - leftvt == VT_I8 || leftvt == VT_UI8 || > - leftvt == VT_INT || leftvt == VT_UINT)) > - return DISP_E_BADVARTYPE; > + if (hres != S_OK && hres != DISP_E_TYPEMISMATCH) > return hres; > + else if(FAILED(hres)) > + { > + V_VT(&bstrvar_right) = VT_BSTR; > + V_BSTR(&bstrvar_right) = SysAllocString(sz_empty); > } > } > } > -- 1.9.1 Same for those changes: remove dead code in separated patch, add tests and consider using VARIANT_ALPHABOOL. Thanks, Jacek

1 0

Re: Transferring D3D textures to OpenGL or Vulkan contexts in Winelib
by Józef Kucia May 16, 2017

May 16, 2017

On Tue, May 16, 2017 at 12:55 AM, Ben "Root" Anderson <roothorick(a)gmail.com> wrote: > On Sun, May 14, 2017 at 2:53 AM, Józef Kucia <joseph.kucia(a)gmail.com> wrote: >> In theory Wine could implement WGL_NV_DX_interop [1] and WGL_NV_DX_interop2 [2]. >> >> [1] - https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop.txt >> [2] - https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop2.txt > > In theory? I'm just a bit skeptical about usefulness of this extension in Wine besides your use-case. > > The main question I can't find the answer to is, are there any > potential copyright/IP problems (or just Wine policy issues) with > implementing these extensions "paint by numbers" off the published > specs? I'm not aware of such problems. Other WGL extensions are already implemented in Wine, see dlls/winex11.drv/opengl.c. In this case it may be a little harder though, the extension has to understand D3D9, D3D10 and D3D11 interfaces, and it has to talk to wined3d, and it has to presumably map GL objects to internal wined3d GL objects.

3 2

Re: d3d11/tests: Add test for the SM4 instruction continuec.
by Henri Verbeet May 16, 2017

May 16, 2017

On 16 May 2017 at 17:47, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > To get fxc to output continuec_z/continuec_nz instead of an if-block > with a normal continue inside, the shaders have been compiled with > the /Gfa flag. > Could you add that as a comment in the code itself?

1 0

Re: [PATCH 4/4] server: Don't change clipboard sequnce number on delayed data rendering
by Marvin May 16, 2017

May 16, 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=30988 Your paranoid android. === w8 (32 bit clipboard) === clipboard.c:399: Test failed: GlobalGetAtomNameA should fail clipboard.c:400: Test failed: err -559038737

1 0

Re: [PATCH 1/3] ws2_32: Don't try to match host name in getaddrinfo if AI_NUMERICHOST hint is specified.
by Marvin May 16, 2017

May 16, 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=30982 Your paranoid android. === w7u (32 bit sock) === sock.c:6146: Test failed: Expected event sequence [FD_READ(0)], got []

1 0

Re: wined3d: Implement SM4 continuec opcode.
by Henri Verbeet May 16, 2017

May 16, 2017

On 14 May 2017 at 18:54, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > Works just like breakc and retc. > > Signed-off-by: Sven Hesse <drmccoy(a)drmccoy.de> > --- > dlls/wined3d/arb_program_shader.c | 1 + > dlls/wined3d/glsl_shader.c | 2 ++ > dlls/wined3d/shader.c | 1 + > dlls/wined3d/shader_sm4.c | 3 +++ > dlls/wined3d/wined3d_private.h | 1 + > 5 files changed, 8 insertions(+) > Thanks. I'll take this as it is, although a small test using the instruction would be nice.

2 1

Re: rpcrt4: Use standard Wine list to store connections in RpcServerProtseq.
by Alexandre Julliard May 16, 2017

May 16, 2017

Jacek Caban <jacek(a)codeweavers.com> writes: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/rpcrt4/rpc_binding.h | 2 +- > dlls/rpcrt4/rpc_server.c | 18 ++++---- > dlls/rpcrt4/rpc_server.h | 2 +- > dlls/rpcrt4/rpc_transport.c | 110 > +++++++++++++++----------------------------- > 4 files changed, 50 insertions(+), 82 deletions(-) This breaks the Windows build: i686-w64-mingw32-gcc -c -o rpc_transport.o ../../../wine/dlls/rpcrt4/rpc_transport.c -I. -I../../../wine/dlls/rpcrt4 \ -I../../include -I../../../wine/include -D__WINESRC__ -D_RPCRT4_ -DMSWMSG -D_REENTRANT -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla \ -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer \ -g -O2 -fno-diagnostics-show-caret -D_WIN32 In file included from ../../../wine/include/windef.h:266:0, from ../../../wine/include/windows.h:37, from ../../../wine/include/winsock.h:110, from ../../../wine/include/winsock2.h:47, from ../../../wine/include/ws2tcpip.h:22, from ../../../wine/dlls/rpcrt4/rpc_transport.c:40: ../../../wine/dlls/rpcrt4/rpc_transport.c: In function ‘rpcrt4_protseq_sock_get_wait_array’: ../../../wine/dlls/rpcrt4/rpc_transport.c:1767:37: error: ‘RpcServerProtseq {aka struct _RpcServerProtseq}’ has no member named ‘conn’ ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c:1772:46: error: ‘RpcConnection {aka struct _RpcConnection}’ has no member named ‘Next’; did you mean ‘exp’? ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c:1789:37: error: ‘RpcServerProtseq {aka struct _RpcServerProtseq}’ has no member named ‘conn’ ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c:1803:46: error: ‘RpcConnection {aka struct _RpcConnection}’ has no member named ‘Next’; did you mean ‘exp’? ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c: In function ‘rpcrt4_protseq_sock_wait_for_new_connection’: ../../../wine/dlls/rpcrt4/rpc_transport.c:1846:41: error: ‘RpcServerProtseq {aka struct _RpcServerProtseq}’ has no member named ‘conn’ ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ ../../../wine/dlls/rpcrt4/rpc_transport.c:1850:50: error: ‘RpcConnection {aka struct _RpcConnection}’ has no member named ‘Next’; did you mean ‘exp’? ../../../wine/include/winnt.h:760:21: note: in definition of macro ‘CONTAINING_RECORD’ Makefile:737: recipe for target 'rpc_transport.o' failed -- Alexandre Julliard julliard(a)winehq.org

4 6

Re: [PATCH 3/6] d3dx9: Match native out of bounds array selector index handling.
by Matteo Bruni May 16, 2017

May 16, 2017

2017-05-12 14:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index 9c07f9c..21aa5d7 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -1051,7 +1051,9 @@ static HRESULT d3dx9_get_param_value_ptr(struct d3dx_pass *pass, struct d3dx_sta > FIXME("Preshader structure is null.\n"); > return D3DERR_INVALIDCALL; > } > - if (update_all || is_param_eval_input_dirty(param->param_eval)) > + /* According to the tests, native d3dx handles the case of array index evaluated to -1 > + * in a specific way. */ > + if (state->index == 0xffffffffu || is_param_eval_input_dirty(param->param_eval, pass->update_version)) Hmm, so that's the index value set at initialization, thus getting a -1 in the first evaluation ends up breaking the "selector changed" check in native? You might want to spell that out in some form in the comment. AFAIU there is no other way a -1 is stored in state->index, correct?

2 3

Re: [PATCH 2/6] d3dx9: Use versioned parameter updates instead of 'dirty' flags.
by Matteo Bruni May 16, 2017

May 16, 2017

2017-05-12 14:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Looping through shared parameters in set_dirty() which is removed by this patch > has a major performance impact on parameter update for applications creating a > lot of effects and sharing parameters between them, which is a common case. > Using versioned scheme also allows for some further optimization. > > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> I don't have serious issues with this patch but I also have a number of questions so I don't feel like signing it off either. Sorry :/ > @@ -163,6 +163,7 @@ struct d3dx_const_tab > unsigned int const_set_size; > struct d3dx_const_param_eval_output *const_set; > const enum pres_reg_tables *regset2table; > + ULONG64 update_version; > }; Is it necessary? Could you do without it, using the pass version instead? > struct d3dx_shared_data; > > @@ -213,6 +214,8 @@ struct d3dx_parameter > UINT bytes; > DWORD runtime_flags; > DWORD object_id; > + ULONG64 update_version; > + ULONG64 *update_version_counter; I don't like the "update_version_counter" name that much but I don't have particularly good suggestions. pass_update_version? current_update_version? parent_update_version? new_update_version? > +static inline ULONG64 get_update_version_counter(ULONG64 *update_version_counter) > +{ > + return ++*update_version_counter; > +} Maybe it's just me but it's a bit surprising to see this get_x() function having side effects. Not sure how to call it. next_update_version()? inc_update_version_counter()? > +static inline BOOL is_param_dirty(struct d3dx_parameter *param, ULONG64 update_version) > +{ > + struct d3dx_shared_data *shared_data; > + > + if ((shared_data = param->top_level_param->u.shared_data)) > + return update_version < shared_data->update_version; > + else > + return update_version < param->top_level_param->update_version; > +} Did you try if a unified update_version pointer looks any nicer? Especially considering that you have a more or less matching *update_version_counter at the moment. > HRESULT d3dx_evaluate_parameter(struct d3dx_param_eval *peval, > - const struct d3dx_parameter *param, void *param_value, BOOL update_all) DECLSPEC_HIDDEN; > + const struct d3dx_parameter *param, void *param_value) DECLSPEC_HIDDEN; I guess this has to do with the update_version in struct d3dx_const_tab. I might be missing something, in that case please clue me. > +static ULONG64 get_effect_update_version_counter(struct d3dx9_base_effect *base) > +{ > + return get_update_version_counter(get_update_version_counter_ptr(base)); > } Same naming caveat here. > -static void clear_dirty_params(struct d3dx9_base_effect *base) > +static void set_dirty(struct d3dx_parameter *param) > { > - unsigned int i; > + struct d3dx_shared_data *shared_data; > + struct d3dx_parameter *top_param = param->top_level_param; > + ULONG64 new_update_version = get_update_version_counter(top_param->update_version_counter); > > - for (i = 0; i < base->parameter_count; ++i) > - base->parameters[i].runtime_flags &= ~PARAMETER_FLAG_DIRTY; > + if ((shared_data = top_param->u.shared_data)) > + shared_data->update_version = new_update_version; > + else > + top_param->update_version = new_update_version; > } Another option would be NOT to increment the effect / pool counter on each set_dirty() but instead only increment it in BeginPass() and CommitChanges(), after you're done with the update (or well, it's fine at almost any point given that we don't have to care about races). It seems a bit better to me, unless I'm overlooking something and it won't work. > static HRESULT set_string(char **param_data, const char *string) > @@ -3078,6 +3074,7 @@ static HRESULT d3dx9_apply_pass_states(struct ID3DXEffectImpl *effect, struct d3 > unsigned int i; > HRESULT ret; > HRESULT hr; > + ULONG64 new_update_version = get_effect_update_version_counter(&effect->base_effect); > > TRACE("effect %p, pass %p, state_count %u.\n", effect, pass, pass->state_count); > > @@ -3109,7 +3106,7 @@ static HRESULT d3dx9_apply_pass_states(struct ID3DXEffectImpl *effect, struct d3 > } > effect->material_updated = FALSE; > > - clear_dirty_params(&effect->base_effect); > + pass->update_version = new_update_version; > return ret; > } Right, here is where I'd update the counter.

2 3

Re: wrc: Allow quotes in resource nameID.
by Alexandre Julliard May 16, 2017

May 16, 2017

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

2 2

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

May 16, 2017

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

2 1

Re: [PATCH] user32: add GetPhysicalCursorPos/SetPhysicalCursorPos stubs (try 2)
by Dmitry Timoshkov May 16, 2017

May 16, 2017

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI GetPhysicalCursorPos(POINT *point) > +{ > + FIXME("(%p) semi-stub: forwarding to GetCursorPos\n", point); > + return GetPhysicalCursorPos(point); > +} A copy/paste bug. -- Dmitry.

1 0

Re: [PATCH] user32: add GetPhysicalCursorPos/SetPhysicalCursorPos stubs
by Ken Thomases May 16, 2017

May 16, 2017

On May 15, 2017, at 9:11 PM, Austin English <austinenglish(a)gmail.com> wrote: > > https://bugs.winehq.org/show_bug.cgi?id=42985 > > -- > -Austin > GPG: 14FB D7EA A041 937B > --- > dlls/user32/input.c | 14 ++++++++++++++ > dlls/user32/user32.spec | 2 ++ > 2 files changed, 16 insertions(+) Shouldn't these just pass through to GetCursorPos() and SetCursorPos(), respectively? Their docs refer to the docs for PhysicalToLogicalPoint()[1], which says that a) the distinction is only meaningful for Vista-style DPI scaling, which Wine doesn't support; and b) since Windows 8.1, even that distinction has been eliminated by DPI virtualization. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms633536(v=vs.85).… -Ken

1 0

Transferring D3D textures to OpenGL or Vulkan contexts in Winelib
by Ben "Root" Anderson May 15, 2017

May 15, 2017

I'd like to start a discussion here and see where it goes. First, my usecase. I want to write a wrapper that connects Windows SteamVR applications running under Wine to the native Linux SteamVR runtime. Because it's the same API on both sides, this is very straightforward, except for one crucial element. In their API, the application does not (necessarily) output the rendered frame to a window, instead submitting the frame to their VR compositor as either an ID3D11Texture, a struct describing a D3D12 texture, an OpenGL texture or render buffer name, or a struct describing a Vulkan texture. For obvious reasons, the latter two are the options available on Linux, making them very straightforward for a Winelib DLL. The former two... not so much. The vast majority of SteamVR applications are currently using Direct3D 11, which means for any of this to work with them, I need some way to convert an ID3D11Texture to the appropriate OpenGL or (preferably) Vulkan equivalent that SteamVR is expecting. I've looked high and low and see no way to do this, neither through Windows APIs nor Winelib. Just to get things working for now, I'll likely figure out a way to invoke wined3d_texture_get_gl_buffer() or similar from outside Wine itself, but that's a dirty hack at best and likely to break frequently (eventually, maybe permanently) as Wine evolves. Thoughts?

2 2

Re: [PATCH 5/6] d3dx9: Avoid redundant constant tables updates.
by Matteo Bruni May 15, 2017

May 15, 2017

2017-05-12 14:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +static void set_preshader_modified(struct d3dx_preshader *pres) > +{ > + unsigned int i; > + > + for (i = 0; i < pres->ins_count; ++i) > + { > + const struct d3dx_pres_ins *ins = &pres->ins[i]; > + const struct d3dx_pres_reg *reg = &ins->output.reg; > + > + regstore_set_modified(&pres->regs, reg->table, reg->offset, > + pres_op_info[ins->op].func_all_comps ? 1 : ins->component_count); > + } > +} This looks a bit ugly but I imagine it's actually okay in practice. Not that I can think of anything better either. E.g. I'm not sure that storing an array of register ranges to dirtify (i.e. precomputing this preshader scan) is really an improvement.

1 0

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

May 15, 2017

This is v6 of this series. The five previous submissions can be found here [1], here [2], here[3], here[4], and here[5]. This version addresses the comments received in v4 plus improvements of the handling of emulation in 64-bit builds. Please see details in the change log. === What is UMIP? User-Mode Instruction Prevention (UMIP) is a security feature present in new Intel Processors. If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0. If these instructions were executed while in CPL > 0, user space applications could have access to system-wide settings such as the global and local descriptor tables, the segment selectors to the current task state and the local descriptor table. These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register If any of these instructions is executed with CPL > 0, a general protection exception is issued when UMIP is enabled. === How does it impact applications? There is a caveat, however. Certain applications rely on some of these instructions to function. An example of this are applications that use WineHQ[6]. For instance, these applications rely on sidt returning a non- accessible memory location[8]. During the discussions, it was proposed that the fault could be relied to the user-space and perform the emulation in user-mode. However, this would break existing applications until, for instance, they update to a new WineHQ version. However, this approach would require UMIP to be disabled by default. The consensus in this forum is to always enable it. This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[8] does not support applications that use these instructions. It relies on WineHQ for this [9]. Furthermore, the applications for which the concern was raised run in protected mode [8]. Please note that UMIP is always enabled for both 64-bit and 32-bit Linux builds. However, emulation of the UMIP-protected instructions is not done for 64-bit processes. 64-bit user space applications will receive the SIGSEGV signal when UMIP instructions causes a general protection fault. === How are UMIP-protected instructions emulated? This version keeps UMIP enabled at all times and by default. If a general protection fault caused by the instructions protected by UMIP is detected, such fault will be fixed-up by returning dummy values as follows: * SGDT and SIDT return hard-coded dummy values as the base of the global descriptor and interrupt descriptor tables. These hard-coded values correspond to memory addresses that are near the end of the kernel memory map. This is also the case for virtual-8086 mode tasks. In all my experiments in x86_32, the base of GDT and IDT was always a 4-byte address, even for 16-bit operands. Thus, my emulation code does the same. In all cases, the limit of the table is set to 0. * STR and SLDT return 0 as the segment selector. This looks appropriate since we are providing a dummy value as the base address of the global descriptor table. * SMSW returns the value with which the CR0 register is programmed in head_32/64.S at boot time. This is, the following bits are enabled: CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for Extension Type, which will always be 1 in recent processors with UMIP; CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment Mask. As per the Intel 64 and IA-32 Architectures Software Developer's Manual, SMSW returns a 16-bit results for memory operands. However, when the operand is a register, the results can be up to CR0[63:0]. Since the emulation code only kicks-in in x86_32, we return up to CR[31:0]. * The proposed emulation code is handles faults that happens in both protected and virtual-8086 mode. === How is this series laid out? ++ Fix bugs in MPX address evaluator I found very useful the code for Intel MPX (Memory Protection Extensions) used to parse opcodes and the memory locations contained in the general purpose registers when used as operands. I put some of this code in a separate library file that both MPX and UMIP can access and avoid code duplication. Before creating the new library, I fixed a couple of bugs that I found in how MPX determines the address contained in the instruction and operands. ++ Provide a new x86 instruction evaluating library With bugs fixed, the MPX evaluating code is relocated in a new insn-eval.c library. The basic functionality of this library is extended to obtain the segment descriptor selected by either segment override prefixes or the default segment by the involved registers in the calculation of the effective address. It was also extended to obtain the default address and operand sizes as well as the segment base address. Also, support to process 16-bit address encodings. Armed with this arsenal, it is now possible to determine the linear address onto which the emulated results shall be copied. This code supports Normal 32-bit and 64-bit (i.e., __USER32_CS and/or __USER_CS) protected mode, virtual-8086 mode, 16-bit protected mode with 32-bit base address. ++ Emulate UMIP instructions A new fixup_umip_exception functions inspect the instruction at the instruction pointer. If it is an UMIP-protected instruction, it executes the emulation code. This uses all the address-computing code of the previous section. ++ Add self-tests Lastly, self-tests are added to entry_from_v86.c to exercise the most typical use cases of UMIP-protected instructions in a virtual-8086 mode. ++ Extensive tests Extensive tests were performed to test all the combinations of ModRM, SiB and displacements for 16-bit and 32-bit encodings for the ss, ds, es, fs and gs segments. Tests also include a 64-bit program that uses segmentation via fs and gs. For this purpose, I temporarily, and not as part of this patchset, enabled UMIP support for 64-bit process with the intention to test the computations of linear addresses in 64-bit mode, including the extra R8-R15 registers. Extensive test is also implemented for virtual-8086 tasks. Code of these tests can be found here [10] and here [11]. [1]. https://lwn.net/Articles/705877/ [2]. https://lkml.org/lkml/2016/12/23/265 [3]. https://lkml.org/lkml/2017/1/25/622 [4]. https://lkml.org/lkml/2017/2/23/40 [5]. https://lkml.org/lkml/2017/3/3/678 [7]. https://www.winehq.org/ [8]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html [9]. http://www.dosemu.org/ [9]. http://marc.info/?l=linux-kernel&m=147876798717927&w=2 [10]. https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/um… [11]. https://github.com/01org/luv-yocto/commit/a72a7fe7d68693c0f4100ad86de6ecabd… Thanks and BR, Ricardo Changes since V5: * Relocate the page fault error code enumerations to traps.h Changes since V4: * Audited patches to use braces in all the branches of conditional. statements, except those in which the conditional action only takes one line. * Implemented support in 64-builds for both 32-bit and 64-bit tasks in the instruction evaluating library. * Split segment selector function in the instruction evaluating library into two functions to resolve the segment type by instruction override or default and a separate function to actually read the segment selector. * Fixed a bug when evaluating 32-bit effective addresses with 64-bit kernels. * Split patches further for for easier review. * Use signed variables for computation of effective address. * Fixed issue with a spurious static modifier in function insn_get_addr_ref found by kbuild test bot. * Removed comparison between true and fixup_umip_exception. * Reworked check logic when identifying erroneous vs invalid values of the SiB base and index. Changes since V3: * Limited emulation to 32-bit and 16-bit modes. For 64-bit mode, a general protection fault is still issued when UMIP-protected instructions are executed with CPL > 0. * Expanded instruction-evaluating code to obtain segment descriptor along with their attributes such as base address and default address and operand sizes. Also, support for 16-bit encodings in protected mode was implemented. * When getting a segment descriptor, this include support to obtain those of a local descriptor table. * Now the instruction-evaluating code returns -EDOM when the value of registers should not be used in calculating the effective address. The value -EINVAL is left for errors. * Incorporate the value of the segment base address in the computation of linear addresses. * Renamed new instruction evaluation library from insn-kernel.c to insn-eval.c * Exported functions insn_get_reg_offset_* to obtain the register offset by ModRM r/m, SiB base and SiB index. * Improved documentation of functions. * Split patches further for easier review. Changes since V2: * Added new utility functions to decode the memory addresses contained in registers when the 16-bit addressing encodings are used. This includes code to obtain and compute memory addresses using segment selectors for real-mode address translation. * Added support to emulate UMIP-protected instructions for virtual-8086 tasks. * Added self-tests for virtual-8086 mode that contains representative use cases: address represented as a displacement, address in registers and registers as operands. * Instead of maintaining a static variable for the dummy base addresses of the IDT and GDT, a hard-coded value is used. * The emulated SMSW instructions now return the value with which the CR0 register is programmed in head_32/64.S This is: PE | MP | ET | NE | WP | AM. For x86_64, PG is also enabled. * The new file arch/x86/lib/insn-utils.c is now renamed as arch/x86/lib/ insn-kernel.c. It also has its own header. This helps keep in sync the the kernel and objtool instruction decoders. Also, the new insn-kernel.c contains utility functions that are only relevant in a kernel context. * Removed printed warnings for errors that occur when decoding instructions with invalid operands. * Added more comments on fixes in the instruction-decoding MPX functions. * Now user_64bit_mode(regs) is used instead of test_thread_flag(TIF_IA32) to determine if the task is 32-bit or 64-bit. * Found and fixed a bug in insn-decoder in which X86_MODRM_RM was incorrectly used to obtain the mod part of the ModRM byte. * Added more explanatory code in emulation and instruction decoding code. This includes a comment regarding that copy_from_user could fail if there exists a memory protection key in place. * Tested code with CONFIG_X86_DECODER_SELFTEST=y and everything passes now. * Prefixed get_reg_offset_rm with insn_ as this function is exposed via a header file. For clarity, this function was added in a separate patch. Changes since V1: * Virtual-8086 mode tasks are not treated in a special manner. All code for this purpose was removed. * Instead of attempting to disable UMIP during a context switch or when entering virtual-8086 mode, UMIP remains enabled all the time. General protection faults that occur are fixed-up by returning dummy values as detailed above. * Removed umip= kernel parameter in favor of using clearcpuid=514 to disable UMIP. * Removed selftests designed to detect the absence of SIGSEGV signals when running in virtual-8086 mode. * Reused code from MPX to decode instructions operands. For this purpose code was put in a common location. * Fixed two bugs in MPX code that decodes operands. Ricardo Neri (21): x86/mpx: Use signed variables to compute effective addresses x86/mpx: Do not use SIB index if index points to R/ESP x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0 x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel x86/insn-eval: Add utility functions to get register offsets x86/insn-eval: Add utility functions to get segment selector x86/insn-eval: Add utility function to get segment descriptor x86/insn-eval: Add utility function to get segment descriptor base address x86/insn-eval: Add functions to get default operand and address sizes x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero insn/eval: Incorporate segment base in address computation x86/insn: Support both signed 32-bit and 64-bit effective addresses x86/insn-eval: Add support to resolve 16-bit addressing encodings x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings x86/mm: Relocate page fault error codes to traps.h x86/cpufeature: Add User-Mode Instruction Prevention definitions x86: Add emulation code for UMIP instructions x86/umip: Force a page fault when unable to copy emulated result to user x86/traps: Fixup general protection faults caused by UMIP x86: Enable User-Mode Instruction Prevention selftests/x86: Add tests for User-Mode Instruction Prevention arch/x86/Kconfig | 10 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/insn-eval.h | 23 + arch/x86/include/asm/traps.h | 18 + arch/x86/include/asm/umip.h | 15 + arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cpu/common.c | 16 +- arch/x86/kernel/traps.c | 4 + arch/x86/kernel/umip.c | 298 +++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-eval.c | 832 ++++++++++++++++++++++++++ arch/x86/mm/fault.c | 88 ++- arch/x86/mm/mpx.c | 120 +--- tools/testing/selftests/x86/entry_from_vm86.c | 39 +- 16 files changed, 1301 insertions(+), 176 deletions(-) create mode 100644 arch/x86/include/asm/insn-eval.h create mode 100644 arch/x86/include/asm/umip.h create mode 100644 arch/x86/kernel/umip.c create mode 100644 arch/x86/lib/insn-eval.c -- 2.9.3

7 109

Wine 2.8 source code
by Игорь Чебаненко May 15, 2017

May 15, 2017

Wine 2.8 scanned with Cppcheck 1.72 There is A LOT of "noise" but I hope it will be helpfull for you.

1 0

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 15, 2017

May 15, 2017

>>> When I run winecfg, I got: >>> >>> wine: glibc >= 2.3 without NPTL or TLS is not a supported combination. >>> Please upgrade to a glibc with NPTL support. >>> >>> >>> Should I interpret that message, that: >>> 1. NPTL is required >>> 2. I should use glibc-2.2 or lower >>> >>> If 1) that's probably end of game per https://lwn.net/Articles/10465/ >>> * "- The 2.5.36 kernel or above must be installed and used." >>> * "The current snapshot for glibc 2.3 (or glibc 2.3 when released) is >>> necessary." >>> * "The general compiler requirement for glibc is at least gcc 3.2." >>> >>> So for further steps 1) or 2) ? >> >>A glibc using TLS might still work without NPTL, though that may require >>glibc 2.3 anyway. > >Yes, TLS was added to 2.5.29: >https://www.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.29 > >...and further improved in 2.5.32: >https://lwn.net/Articles/7591/ > >> Note that the above requirements are for building >>glibc, not running it. > >Short version: hint for 2.3 is probably not correct > >Longer version based on Glibc's release notes: > >glibc-2.3: Even though TLS support is mentioned as one new feature for this release >the default is not to build glibc with TLS support enabled. This has >several reasons, most of which are out of control of the glibc >developers. Therefore it is necessry to *not* use the --with-tls option >for configure. > >=no support for TLS & NPTL in glibc-2.3. > >glibc-2.3.2: ELF thread-local storage support (TLS) now works on x86-64. >glibc-2.3.2: The sources were also prepared to be used with the NPTL > thread library which is not yet included. > >=no support for NPTL in glibc-2.3.2 itself > >glibc-2.3.3: The main glibc-2.3.3 release >package contains the Native POSIX Threads Library (NPTL) contributed >by Ulrich Drepper, which supports Linux 2.6 kernels only. > > > > The NPTL support was backported to older kernels IIRC. > >It seems, that RedHat did that... >http://rpm.pbone.net/index.php3/stat/4/idpl/18727833/dir/fedora_1/com/kerne… > >I'm not fan of Fedora, so i could try your initially suggested >"A glibc using TLS might still work without NPTL...", i.e. >kernel-2.5.32 + rebuild of glibc-2.3.2, but i find that >glibc recipe pretty painful. But if you are expecting rather >2.4.xx results, that would be for some Fedora/RedHat fans. > >Anyway, i don't see chances for anything like subject mentioned >linux v2.3.31. > One more note: Debian Sarge includes glibc-2.3.2 and shows: "Thread-local storage support included" and does not mention NPTL. But kernel is 2.4.27 (without kernel side TLS), so winecfg complains. So i could also easily try Sarge's alternative kernel 2.6.8 instead of 2.4.27. Then TLS is supported in this glibc without NPTL and see if, winecfg is happy. That is the easiest step.

1 0

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 15, 2017

May 15, 2017

>> When I run winecfg, I got: >> >> wine: glibc >= 2.3 without NPTL or TLS is not a supported combination. >> Please upgrade to a glibc with NPTL support. >> >> >> Should I interpret that message, that: >> 1. NPTL is required >> 2. I should use glibc-2.2 or lower >> >> If 1) that's probably end of game per https://lwn.net/Articles/10465/ >> * "- The 2.5.36 kernel or above must be installed and used." >> * "The current snapshot for glibc 2.3 (or glibc 2.3 when released) is >> necessary." >> * "The general compiler requirement for glibc is at least gcc 3.2." >> >> So for further steps 1) or 2) ? > >A glibc using TLS might still work without NPTL, though that may require >glibc 2.3 anyway. Yes, TLS was added to 2.5.29: https://www.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.29 ...and further improved in 2.5.32: https://lwn.net/Articles/7591/ > Note that the above requirements are for building >glibc, not running it. Short version: hint for 2.3 is probably not correct Longer version based on Glibc's release notes: glibc-2.3: Even though TLS support is mentioned as one new feature for this release the default is not to build glibc with TLS support enabled. This has several reasons, most of which are out of control of the glibc developers. Therefore it is necessry to *not* use the --with-tls option for configure. =no support for TLS & NPTL in glibc-2.3. glibc-2.3.2: ELF thread-local storage support (TLS) now works on x86-64. glibc-2.3.2: The sources were also prepared to be used with the NPTL thread library which is not yet included. =no support for NPTL in glibc-2.3.2 itself glibc-2.3.3: The main glibc-2.3.3 release package contains the Native POSIX Threads Library (NPTL) contributed by Ulrich Drepper, which supports Linux 2.6 kernels only. > The NPTL support was backported to older kernels IIRC. It seems, that RedHat did that... http://rpm.pbone.net/index.php3/stat/4/idpl/18727833/dir/fedora_1/com/kerne… I'm not fan of Fedora, so i could try your initially suggested "A glibc using TLS might still work without NPTL...", i.e. kernel-2.5.32 + rebuild of glibc-2.3.2, but i find that glibc recipe pretty painful. But if you are expecting rather 2.4.xx results, that would be for some Fedora/RedHat fans. Anyway, i don't see chances for anything like subject mentioned linux v2.3.31.

1 0

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 15, 2017

May 15, 2017

>>>If winecfg runs, that should be good enough. Optional packages can be >>>backported if necessary. >>> >> >>OK, then I will concentrate on min kernel version :) >> Currently I build wine-2.8 on machine with: * Linux-v2.4.27-3-386 * gcc-v3.3.5 * libc6-v2.3.2 There were few failures which I overcome by not building these components: * dwrite * winealsa.drv * wmvcore * ws2_32 * programs/winhlp32 When I run winecfg, I got: wine: glibc >= 2.3 without NPTL or TLS is not a supported combination. Please upgrade to a glibc with NPTL support. Should I interpret that message, that: 1. NPTL is required 2. I should use glibc-2.2 or lower If 1) that's probably end of game per https://lwn.net/Articles/10465/ * "- The 2.5.36 kernel or above must be installed and used." * "The current snapshot for glibc 2.3 (or glibc 2.3 when released) is necessary." * "The general compiler requirement for glibc is at least gcc 3.2." So for further steps 1) or 2) ? wmvcore and winhlp32 look like a real bugs. Others failures can be probably be solved by using newer components. I can open bugreports, if anyone is interested. Regards, W.

2 1

Re: [PATCH 2/2] uninstaller: Allocate enough memory to null-terminate the command string
by Alexandre Julliard May 15, 2017

May 15, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -245,7 +245,7 @@ static int FetchFromRootKey(HKEY root) > type == REG_DWORD && value == 1) > { > static const WCHAR fmtW[] = {'m','s','i','e','x','e','c',' ','/','x','%','s',0}; > - command = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(fmtW) + lstrlenW(subKeyName)) * sizeof(WCHAR)); > + command = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(fmtW) + sizeOfSubKeyName + 1) * sizeof(WCHAR)); The %s in the format gets replaced, so the existing code is fine. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] dwrite: Fix locale data buffer length passed to GetLocaleInfoEx()
by Alexandre Julliard May 15, 2017

May 15, 2017

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -1106,8 +1109,8 @@ static HRESULT WINAPI dwritetextanalyzer_GetGlyphs(IDWriteTextAnalyzer2 *iface, > struct scriptshaping_context context; > struct scriptshaping_cache *cache = NULL; > BOOL update_cluster, need_vertical; > + WCHAR digits[native_digits_length]; It would have to be a #define if you want to do this. -- Alexandre Julliard julliard(a)winehq.org

1 0