- wine-devel - winehq.org

Re: [PATCH v2 3/5] winebus.sys: Process device reports for linux event devices
by Roderick Colenbrander 07 Mar '17

07 Mar '17

Hi Aric, Some quick feedback on this patch as well. High-level looks okay (need to have a deeper dive), one thing really implement proper support for EV_SYN and particular you MUST handle SYN_DROPPEPD, it has bitten me many times. Basically if you don't process input fast enough (can happen for various reason either you are too slow or device is too fast), evdev drops input and you can't trust the state. When input is dropped SYN_DROPPED is sent and you must follow the required procedures to recover (ignore any input data until next SYN_REPORT). I'm not sure how you are marking the end of input reports, but you may want to mark a report completed based on the proper SYN flag as well else you may build up unneeded input latency. Didn't follow too closely what you are doing yet. Thanks, Roderick On Mon, Feb 27, 2017 at 9:33 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > v2: Updates from Sebastian Lackner > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 203 ++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 197 insertions(+), 6 deletions(-) > > > > >

1 1

Re: [PATCH 5/5] usp10/tests: Add shaping tests for fLogicalOrder and fRTL.
by Sebastian Lackner 07 Mar '17

07 Mar '17

On 02.03.2017 09:38, Henri Verbeet wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/usp10/tests/usp10.c | 153 +++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 148 insertions(+), 5 deletions(-) > I'm getting a lot of test failures after this series (starting with patch 2): $ (cd dlls/usp10/tests/; make test) ../../../tools/runtest -q -P wine -T ../../.. -M usp10.dll -p usp10_test.exe.so usp10 && touch usp10.ok fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly usp10.c:1662: Test failed: 0: invalid LogClust(8) usp10.c:1662: Test failed: 1: invalid LogClust(7) usp10.c:1662: Test failed: 2: invalid LogClust(6) usp10.c:1662: Test failed: 3: invalid LogClust(6) usp10.c:1662: Test failed: 4: invalid LogClust(4) usp10.c:1662: Test failed: 5: invalid LogClust(3) usp10.c:1662: Test failed: 6: invalid LogClust(1) usp10.c:1662: Test failed: got incorrect number of glyphs (9) usp10.c:1662: Test failed: 2: uJustification incorrect (2) usp10.c:1662: Test failed: 2: fClusterStart incorrect (0) usp10.c:1662: Test failed: 3: fClusterStart incorrect (1) usp10.c:1662: Test failed: 3: fDiacritic incorrect (0) usp10.c:1662: Test failed: 3: fZeroWidth incorrect (0) usp10.c:1662: Test failed: 5: fClusterStart incorrect (0) usp10.c:1662: Test failed: 5: fDiacritic incorrect (1) usp10.c:1662: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1662: Test failed: 7: uJustification incorrect (0) usp10.c:1662: Test failed: 8: uJustification incorrect (0) usp10.c:1662: Test failed: 8: fClusterStart incorrect (1) usp10.c:1662: Test failed: 8: fDiacritic incorrect (0) usp10.c:1662: Test failed: Got unexpected glyphProp2[6].sva.uJustification 0, expected 0x2. usp10.c:1662: Test failed: Got unexpected glyphProp2[6].sva.fClusterStart 0x1, expected 0. usp10.c:1662: Test failed: Got unexpected glyphProp2[7].sva.uJustification 0x2, expected 0. usp10.c:1662: Test failed: Got unexpected glyphProp2[7].sva.fClusterStart 0, expected 0x1. fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly fixme:uniscribe:SHAPE_GetFontFeatureTags Filtering not implemented Is this a problem with the fonts shipped on Archlinux, or is something going wrong on the Wide side? The font "Estrangelo Edessa" is provided by /usr/share/fonts/OTF/SyrCOMEdessa.otf which can be downloaded at https://www.archlinux.org/packages/extra/any/xorg-fonts-misc/download/. If you need any logs or want me to open a bug report, please let me know. Best regards, Sebastian

2 4

[v5 00/20] x86: Enable User-Mode Instruction Prevention
by Ricardo Neri 07 Mar '17

07 Mar '17

This is v5 of this series. The four previous submissions can be found here [1], here [2], here[3], and here [4]. 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[6]. 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[7] does not support applications that use these instructions. It relies on WineHQ for this [8]. Furthermore, the applications for which the concern was raised run in protected mode [6]. 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 and fs 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 [9] and here [10]. [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://www.winehq.org/ [6]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html [7]. http://www.dosemu.org/ [8]. http://marc.info/?l=linux-kernel&m=147876798717927&w=2 [9]. https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/um… [10]. https://github.com/01org/luv-yocto/commit/a72a7fe7d68693c0f4100ad86de6ecabd… Thanks and BR, Ricardo 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. Thanks and BR, Ricardo Ricardo Neri (20): 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/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/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 | 305 ++++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-eval.c | 832 ++++++++++++++++++++++++++ arch/x86/mm/mpx.c | 120 +--- tools/testing/selftests/x86/entry_from_vm86.c | 39 +- 14 files changed, 1256 insertions(+), 122 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

2 22

Re: [PATCH] makedep: touch the .tab.c file to ensure ordering
by Alexandre Julliard 06 Mar '17

06 Mar '17

Marcus Meissner <marcus(a)jet.franken.de> writes: > .tab.c and .tab.h are created too close together to confuse > make. Ensure a bit better ordering by touching mcy.tab.c I don't think that's better. It shouldn't make any difference, except maybe making it a little harder to reproduce. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Reproducible builds
by wylda＠volny.cz 06 Mar '17

06 Mar '17

> Od: André Hentschel <nerv(a)dawncrow.de> >>>>>> Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >>>>>>> Anyway, there are 7 files out of 2750 which _always_ pickup some random >>>>>>> value and use that consistently. Why are these libraries built >>>>>>> inconsitently? Is that intentional? An example is attached. >>>>> >>>>> Thanks. These "random" value come from: >>>>> >>>>> * olepro_t.res >>>>> * std_ole_v2_t.res >>>>> * wuapi_tlb_t.res >>> >>> When i do: >>> >>> export WIDL_TIME_OVERRIDE="0" >>> rm dlls/olepro32/olepro_t.res >>> make -k dlls/olepro32 >>> md5sum -b dlls/olepro32/olepro_t.res >>> >>> then i always get different MD5 checksum. >>> >>> Marcus, could you send me your dlls/olepro32/Makefile please? >>> What is your distro? >> >> I tried above for both 32bit and 64bit directories, always gives the same md5 in those. >> >> openSUSE Tumbleweed, with currently gcc 6.3.1+r245113, binutils-2.27, flex-2.6.1, bison-3.0.4 >> > >I can reproduce the bug with the instructions above >Linux Mint 18.1, gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4), binutils 2.26.1, flex 2.6, biso 3.0.4 >the first bad value is at offset 269h >Which is datatype2 from MSFT_TypeInfoBase > >So initializing datatype2 in add_typedef_typeinfo or the following patch fixes the problem for me: > >diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c >index 137bb2d..7904e45 100644 >--- a/tools/widl/write_msft.c >+++ b/tools/widl/write_msft.c >@@ -798,6 +798,7 @@ static int encode_type( > if (!alignment) alignment = &scratch; > if (!decoded_size) decoded_size = &scratch; > >+ *decoded_size = 0; > > switch (vt) { > case VT_I1: > Thank Stefan / Marcus / Andre. This fixed 6 files. 7th file is libdinput.a, which also has some random stuff inside. This was for 32bit chroot. In 64bit chroot these 6 files are also fixed now. libdinput.a differs again. But 64bit chroot also shows 2 other files: * /bin/wmc * /lib64/wine/msi.dll.so These last two differs in Build-id's SHA1 of the .note.gnu.build-id section. Debian Stretch 9.0 Multiarch: * gcc (Debian 6.3.0-6) 6.3.0 20170205 * binutils 2.27.90.20170124-2 * flex 2.6.1-1.3 * bison 3.0.4.dfsg-1 Regards, W.

3 5

Re: [PATCH 3/3] wininet/test: Improve tests for InternetGetConnectedStateEx
by Bruno Jesus 06 Mar '17

06 Mar '17

On Mon, Mar 6, 2017 at 11:24 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Hi Bruno, Hi, thanks for the review ;-) > On 06.03.2017 05:24, Bruno Jesus wrote: >> - ok(sz - 1 == lstrlenW(buffer), "Expected %u bytes, got %u\n", sz - 1, lstrlenW(buffer)); >> + if (flags & INTERNET_CONNECTION_MODEM) >> + ok(lstrlenW(buffer) == 0, "Expected 0 bytes, got %u\n", lstrlenW(buffer)); >> + else >> + ok(sz - 1 == lstrlenW(buffer), "Expected %u bytes, got %u\n", sz - 1, lstrlenW(buffer)); > > > You're dropping sz value tests in case is set. What is it set to in this > case? 0? > > As a side note, you don't need strlen() to check if buffer is empty, > something like !*buffer will do the trick. You are right, I will make the change to test both !buffer[0] and sz == 0 in the three cases.

1 0

Re: [PATCH 3/3] winmm: Dispatch MCI_BREAK to the driver (try 2, resend)
by Andrew Eikum 06 Mar '17

06 Mar '17

Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> On Mon, Mar 06, 2017 at 01:24:28AM -0300, Bruno Jesus wrote: > From: Bruno Jesus <bjesus(a)codeweavers.com> > > try 2: > Fix trace (spotted by Sebastian Lackner) > > Worms 2: > trace:mci:MCI_Break (00000001, 00000100, vkey 001B, hwnd 0x2003c) > > Half-Life: > trace:mci:MCI_Break (00000002, 00000102, vkey 001B, hwnd (nil)) > > Signed-off-by: Bruno Jesus <bjesus(a)codeweavers.com> > --- > dlls/winmm/mci.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/dlls/winmm/mci.c b/dlls/winmm/mci.c > index f772388..56a537d 100644 > --- a/dlls/winmm/mci.c > +++ b/dlls/winmm/mci.c > @@ -2063,13 +2063,18 @@ static DWORD MCI_SysInfo(UINT uDevID, DWORD dwFlags, LPMCI_SYSINFO_PARMSW lpParm > */ > static DWORD MCI_Break(UINT wDevID, DWORD dwFlags, LPMCI_BREAK_PARMS lpParms) > { > + DWORD dwRet; > + > if (lpParms == NULL) > return MCIERR_NULL_PARAMETER_BLOCK; > - FIXME("(%04x) vkey %04X stub\n", dwFlags, lpParms->nVirtKey); > > - if (dwFlags & MCI_NOTIFY) > + TRACE("(%08x, %08X, vkey %04X, hwnd %p)\n", wDevID, dwFlags, > + lpParms->nVirtKey, lpParms->hwndBreak); > + > + dwRet = MCI_SendCommandFrom32(wDevID, MCI_BREAK, dwFlags, (DWORD_PTR)lpParms); > + if (!dwRet && (dwFlags & MCI_NOTIFY)) > mciDriverNotify((HWND)lpParms->dwCallback, wDevID, MCI_NOTIFY_SUCCESSFUL); > - return MMSYSERR_NOERROR; > + return dwRet; > } > > /************************************************************************** > -- > 2.9.3 > > >

1 0

Re: [PATCH 1/4] user32: Don't forward EnableWindow to the window's thread.
by Sebastian Lackner 06 Mar '17

06 Mar '17

On 05.03.2017 20:21, Zebediah Figura wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=42568 > > The only apparent use of this is to kill the focus and capture of > the window if the thread doesn't own it. However, testing reveals > that on Windows the focus isn't killed either, and the capture is > handled by DefWindowProc, as already implemented in Wine. > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/user32/message.c | 3 --- > dlls/user32/spy.c | 1 - > dlls/user32/tests/msg.c | 8 +++----- > dlls/user32/user_private.h | 1 - > dlls/user32/win.c | 12 ------------ > 5 files changed, 3 insertions(+), 22 deletions(-) > You will at least have to forward for other processes (see for example the WIN_SetStyle implementation). Best regards, Sebastian

2 1

Re: gdiplus: Check for null in GdipGetFontHeight
by Vincent Povirk 05 Mar '17

05 Mar '17

This fails the gdiplus:font tests. font.c:550: Test failed: Expected 0, got 2 font.c:627: Test failed: font_height 63875314620738696996458594304.000000 != 15.691406 font.c:640: Test failed: font_height 63875314620738696996458594304.000000 != 15.691406 font.c:550: Test failed: Expected 0, got 2 font.c:668: Test failed: font_height 63875314620738696996458594304.000000 != 13.277344 font.c:681: Test failed: font_height 63875314620738696996458594304.000000 != 13.277344 font.c:550: Test failed: Expected 0, got 2 font.c:710: Test failed: font_height 63875314620738696996458594304.000000 != 15.691406

1 0

Re: [PATCH 4/4] user32: Only process sent messages from driver in PeekMessage().
by Marvin 05 Mar '17

05 Mar '17

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=29130 Your paranoid android. === w7u (32 bit win) === win.c:1003: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00130156 fg 000301B4 in hook HCBT_MINMAX

1 0

Re: [PATCH 2/2] user32: scrollbars are vertical by default
by Nikolay Sivov 05 Mar '17

05 Mar '17

On 04.03.2017 23:29, Kees Beets wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=38029 > > Changed calculation of boolean vertical so that default is true. > > Tested on Ubuntu 16.04. > > Signed-off-by: kbeets68(a)gmail.com > --- > dlls/user32/scroll.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/user32/scroll.c b/dlls/user32/scroll.c > index 4b572e5..202fac8 100644 > --- a/dlls/user32/scroll.c > +++ b/dlls/user32/scroll.c > @@ -252,7 +252,7 @@ static BOOL SCROLL_GetScrollBarRect( HWND hwnd, INT nBar, RECT *lprect, > > case SB_CTL: > GetClientRect( hwnd, lprect ); > - vertical = ((wndPtr->dwStyle & SBS_VERT) != 0); > + vertical = ((wndPtr->dwStyle & SBS_HORZ) == 0); > break; > > default: > Hi, this doesn't look right, SBS_HORZ is 0, which makes 'vertical' always 1.

2 1

Re: GSOC 2017 - Resource/Dialog Editor
by Austin English 05 Mar '17

05 Mar '17

On Mar 3, 2017 3:16 AM, "Joseph-Eugene Winzer" <ml999(a)openmailbox.org> wrote: On 03/02/2017 10:45 PM, Austin English wrote: > On Thu, Mar 2, 2017 at 1:58 PM, Joe <ml999(a)openmailbox.org> wrote: > >> Hi, >> >> First of all, congrats for getting picked for another GSoC! >> Wine made my transition to Linux way easier and with more and more >> applications being supported the year of the desktop can come :) >> >> My name is Joseph Winzer and I am a bachelor math/CS student looking >> forward >> to contribute to open source in this year's GSoC. >> The 'Resource/Dialog Editor' project caught my eye as I remember a few >> years >> back digging through executables out of curiousity. Last time I looked >> for a >> resource editor it was either bundled with other software (Visual Studio, >> PellesC) or as mentioned in the project description bundled up with adware >> like ResEdit. >> I want to change that by contributing to Wine with an open source >> standalone >> editor anyone can use free of charge. >> Equipped with my Petzold, MSDN and the help of the community I am sure I >> will be able to realize this project. >> >> >> Looking forward working with you guys :) >> > > Hi Joseph, > > Thanks for your interest. Could you describe your experience with > C/Wine a bit? Have you thought about how you would implement/design > the resource editor at all? Could you share your plans? > > Thanks for your reply. So far, I experienced Wine exclusively from a user perspective, using it mostly for running games and apps I didn't find a substitute on Linux. I compiled Wine a few times when certain milestones were reached like improved D3D9 or bugfixes for certain apps. I did grep for stubs once in a while, browsed through the GDI implementation but wasn't confident enough to contribute. OK. Note that contributing a patch is a requirement of applicants. Patches related to the project are highly encouraged, but not required. I read more code than I wrote myself and most of it has been C or C-style C++. WinAPI-wise, I remember writing small games like connect four or apps where I tried to use what I had recently learned. I also did some reverse engineering for writing trainers or just for the fun of it. That has been awhile, though. What did you reverse engineer? If it's Microsoft code, or if you've seen Microsoft code, you're (in general) ineligible to contribute to Wine. More recently I looked at quake, tuxpaint, util-linux, .. whatever caught my interest. Concerning the technical aspects of implementing the editor, I haven't given it much thought yet. MSDN et al provide enough documentation to tackle the task and problems can be dealt with once they come up (I assume in my naivete). Design-wise it depends on what the Wine community expects it to be but personally I imagined ResEdit trimmed to reading out and altering resources with dialog creation on top. From there it can be extended in whatever direction the community sees fit. The rough sketch would be as follows: * Establishing bare bones UI (sidebar for items, main window as viewer) * Read PE compatible file resources * Export resources * Modify resources (substitute images, edit items) * Refining UI for editing/viewing This covers the basic functionality of the resource viewer. The Dialog Editor provides rendering of dialog elements what would complement part of the resource viewer and exporting as .rc. My estimate is that the dialog editor will be the biggest part of the project with parsing resources, dialog rendering, layout, .. Overall the planning and focus of the project depends on what the community expects it to be and if there is an immediate use case it can cover in Wine or thought of as a general tool. OK. Sorry for the wall of text but I hope I could describe to you my idea I have for it. Of course, in the official application the gaps for the implementation will be filled but getting feedback from the community first makes planning also easier for me. IMO walls of text are good. I'd rather see more text than brief descriptions that show a lack of thought/research ;) -- -Austin GPG: 14FB D7EA A041 937B

1 0

some source files are not listed at dl.winehq.org/wine/source/2.x/
by version2013＠openmailbox.org 04 Mar '17

04 Mar '17

https://dl.winehq.org/wine/source/2.x/ wine-2.2 and wine-2.3 are not listed. If I manually type the expected filename in the url, then I can download them.

4 4

Re: regedit/tests: Add some line concatenation tests
by Alexandre Julliard 03 Mar '17

03 Mar '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/tests/regedit.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M regedit.exe -p regedit.exe_test.exe.so regedit && touch regedit.ok regedit.c:484: Test succeeded inside todo block: Reg value shouldn't exist: Multi-Line2 regedit.c:496: Test succeeded inside todo block: Reg value shouldn't exist: Multi-Line4 Makefile:174: recipe for target 'regedit.ok' failed make[1]: *** [regedit.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Don't modify LockCount in RtlLeaveCriticalSection if section is not acquired.
by Sebastian Lackner 03 Mar '17

03 Mar '17

On 03.03.2017 18:48, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/ntdll/critsection.c | 6 ++++- > dlls/ntdll/tests/rtl.c | 59 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 64 insertions(+), 1 deletion(-) > > > > 0001-ntdll-Don-t-modify-LockCount-in-RtlLeaveCriticalSecti.diff > > > diff --git a/dlls/ntdll/critsection.c b/dlls/ntdll/critsection.c > index e2eb364..e405b08 100644 > --- a/dlls/ntdll/critsection.c > +++ b/dlls/ntdll/critsection.c > @@ -665,7 +665,11 @@ BOOL WINAPI RtlIsCriticalSectionLockedByThread( RTL_CRITICAL_SECTION *crit ) > */ > NTSTATUS WINAPI RtlLeaveCriticalSection( RTL_CRITICAL_SECTION *crit ) > { > - if (--crit->RecursionCount) interlocked_dec( &crit->LockCount ); > + if (--crit->RecursionCount) > + { > + if (crit->RecursionCount > 0) interlocked_dec( &crit->LockCount ); > + else ERR( "section %p is not acquired\n", crit ); > + } > else > { > crit->OwningThread = 0; > diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c > index 43c26bd..4b6ee35 100644 > --- a/dlls/ntdll/tests/rtl.c > +++ b/dlls/ntdll/tests/rtl.c > @@ -98,6 +98,9 @@ static NTSTATUS (WINAPI *pRtlCompressBuffer)(USHORT, const UCHAR*, ULONG, PUCHA > static BOOL (WINAPI *pRtlIsCriticalSectionLocked)(CRITICAL_SECTION *); > static BOOL (WINAPI *pRtlIsCriticalSectionLockedByThread)(CRITICAL_SECTION *); > static NTSTATUS (WINAPI *pRtlInitializeCriticalSectionEx)(CRITICAL_SECTION *, ULONG, ULONG); > +static NTSTATUS (WINAPI *pRtlInitializeCriticalSection)(CRITICAL_SECTION *); > +static NTSTATUS (WINAPI *pRtlEnterCriticalSection)(RTL_CRITICAL_SECTION *); > +static NTSTATUS (WINAPI *pRtlLeaveCriticalSection)(RTL_CRITICAL_SECTION *); > > static HMODULE hkernel32 = 0; > static BOOL (WINAPI *pIsWow64Process)(HANDLE, PBOOL); > @@ -151,6 +154,9 @@ static void InitFunctionPtrs(void) > pRtlIsCriticalSectionLocked = (void *)GetProcAddress(hntdll, "RtlIsCriticalSectionLocked"); > pRtlIsCriticalSectionLockedByThread = (void *)GetProcAddress(hntdll, "RtlIsCriticalSectionLockedByThread"); > pRtlInitializeCriticalSectionEx = (void *)GetProcAddress(hntdll, "RtlInitializeCriticalSectionEx"); > + pRtlInitializeCriticalSection = (void *)GetProcAddress(hntdll, "RtlInitializeCriticalSection"); > + pRtlEnterCriticalSection = (void *)GetProcAddress(hntdll, "RtlEnterCriticalSection"); > + pRtlLeaveCriticalSection = (void *)GetProcAddress(hntdll, "RtlLeaveCriticalSection"); Those functions should not require dynamic loading. The *Ex function is only loaded dynamically because it was introduced in later Windows versions. > } > hkernel32 = LoadLibraryA("kernel32.dll"); > ok(hkernel32 != 0, "LoadLibrary failed\n"); > @@ -2094,6 +2100,58 @@ static void test_RtlInitializeCriticalSectionEx(void) > RtlDeleteCriticalSection(&cs); > } > > +static void test_RtlLeaveCriticalSection(void) > +{ > + RTL_CRITICAL_SECTION cs; > + NTSTATUS status; > + > + pRtlInitializeCriticalSection(&cs); > + > + status = pRtlEnterCriticalSection(&cs); > + ok(!status, "RtlEnterCriticalSection failed: %x\n", status); > + todo_wine > + ok(cs.LockCount == -2, "expected LockCount == -2, got %d\n", cs.LockCount); Some of these tests seem to fail on XP (see testbot). > + ok(cs.RecursionCount == 1, "expected RecursionCount == 1, got %d\n", cs.RecursionCount); > + ok(cs.OwningThread == ULongToHandle(GetCurrentThreadId()), "unexpected OwningThread\n"); > + > + status = pRtlLeaveCriticalSection(&cs); > + ok(!status, "RtlLeaveCriticalSection failed: %x\n", status); > + ok(cs.LockCount == -1, "expected LockCount == -1, got %d\n", cs.LockCount); > + ok(cs.RecursionCount == 0, "expected RecursionCount == 0, got %d\n", cs.RecursionCount); > + ok(!cs.OwningThread, "unexpected OwningThread %p\n", cs.OwningThread); > + > + /* > + * Trying to leave a section that wasn't acquired modifies RecusionCount to an invalid values, Should this be "invalid value" ? > + * but doesn't modify LockCount so that an attempt to enter the section later will work. > + */ > + status = pRtlLeaveCriticalSection(&cs); > + ok(!status, "RtlLeaveCriticalSection failed: %x\n", status); > + ok(cs.LockCount == -1, "expected LockCount == -1, got %d\n", cs.LockCount); > + ok(cs.RecursionCount == -1, "expected RecursionCount == -1, got %d\n", cs.RecursionCount); > + ok(!cs.OwningThread, "unexpected OwningThread %p\n", cs.OwningThread); > + > + /* and again */ > + status = pRtlLeaveCriticalSection(&cs); > + ok(!status, "RtlLeaveCriticalSection failed: %x\n", status); > + ok(cs.LockCount == -1, "expected LockCount == -1, got %d\n", cs.LockCount); > + ok(cs.RecursionCount == -2, "expected RecursionCount == -1, got %d\n", cs.RecursionCount); Copy and paste error in the ok message. > + ok(!cs.OwningThread, "unexpected OwningThread %p\n", cs.OwningThread); > + > + /* entering section fixes RecursionCount */ > + status = pRtlEnterCriticalSection(&cs); > + ok(!status, "RtlEnterCriticalSection failed: %x\n", status); > + todo_wine > + ok(cs.LockCount == -2, "expected LockCount == -2, got %d\n", cs.LockCount); > + ok(cs.RecursionCount == 1, "expected RecursionCount == 1, got %d\n", cs.RecursionCount); > + ok(cs.OwningThread == ULongToHandle(GetCurrentThreadId()), "unexpected OwningThread\n"); > + > + status = pRtlLeaveCriticalSection(&cs); > + ok(!status, "RtlLeaveCriticalSection failed: %x\n", status); > + ok(cs.LockCount == -1, "expected LockCount == -1, got %d\n", cs.LockCount); > + ok(cs.RecursionCount == 0, "expected RecursionCount == 0, got %d\n", cs.RecursionCount); > + ok(!cs.OwningThread, "unexpected OwningThread %p\n", cs.OwningThread); Please delete the critical section after the test to avoid leaks. > +} > + > START_TEST(rtl) > { > InitFunctionPtrs(); > @@ -2125,4 +2183,5 @@ START_TEST(rtl) > test_RtlDecompressBuffer(); > test_RtlIsCriticalSectionLocked(); > test_RtlInitializeCriticalSectionEx(); > + test_RtlLeaveCriticalSection(); > } > > >

3 3

Re: ntdll: Don't modify LockCount in RtlLeaveCriticalSection if section is not acquired.
by Marvin 03 Mar '17

03 Mar '17

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=29096 Your paranoid android. === wxppro (32 bit rtl) === rtl.c:2113: Test failed: expected LockCount == -2, got 0 rtl.c:2129: Test failed: expected LockCount == -1, got -2 rtl.c:2136: Test failed: expected LockCount == -1, got -3 ntdll:rtl has unreported failures

1 0

Re: [PATCH 2/2] ntdll: Fix NtFlushBuffersFile() for files with FILE_APPEND_DATA access.
by Paul Gofman 03 Mar '17

03 Mar '17

Sorry for introducing that in f7d40d45da7a1bc0accd58bca6d6da4e34861937. I just verified that server_get_unix_fd() returns success if to request FILE_APPEND_DATA for handles created with (read/)write access. I also checked that requesting FILE_APPEND_DATA gets no error if using it with a usb serial port. Is it anything bad to just use FILE_APPEND_DATA instead of FILE_WRITE_DATA in server_get_unix_fd()? If its not that I am missing something why it should not be done like that, I can add test for serial port. On 03/03/2017 06:21 PM, Józef Kucia wrote: > This fixes a regression introduced by commit > f7d40d45da7a1bc0accd58bca6d6da4e34861937. > > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/ntdll/file.c | 2 ++ > dlls/ntdll/tests/file.c | 1 - > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 3f38c6f..e2cfe7f 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -3418,6 +3418,8 @@ NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile, IO_STATUS_BLOCK* IoStatusBlock > int fd, needs_close; > > ret = server_get_unix_fd( hFile, FILE_WRITE_DATA, &fd, &needs_close, &type, NULL ); > + if (ret == STATUS_ACCESS_DENIED) > + ret = server_get_unix_fd( hFile, FILE_APPEND_DATA, &fd, &needs_close, &type, NULL ); > > if (!ret && type == FD_TYPE_SERIAL) > { > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index 5e7e1ee..09bf688 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -4441,7 +4441,6 @@ static void test_flush_buffers_file(void) > ok(hfile != INVALID_HANDLE_VALUE, "could not open temp file, error %d.\n", GetLastError()); > > status = pNtFlushBuffersFile(hfile, &io_status_block); > - todo_wine > ok(status == STATUS_SUCCESS, "expected STATUS_SUCCESS, got %#x.\n", status); > > CloseHandle(hfile);

2 1

GSOC 2017 - Resource/Dialog Editor
by Joe 03 Mar '17

03 Mar '17

Hi, First of all, congrats for getting picked for another GSoC! Wine made my transition to Linux way easier and with more and more applications being supported the year of the desktop can come :) My name is Joseph Winzer and I am a bachelor math/CS student looking forward to contribute to open source in this year's GSoC. The 'Resource/Dialog Editor' project caught my eye as I remember a few years back digging through executables out of curiousity. Last time I looked for a resource editor it was either bundled with other software (Visual Studio, PellesC) or as mentioned in the project description bundled up with adware like ResEdit. I want to change that by contributing to Wine with an open source standalone editor anyone can use free of charge. Equipped with my Petzold, MSDN and the help of the community I am sure I will be able to realize this project. Looking forward working with you guys :)

3 2

Re: [PATCH 1/2] ws2_32/tests: Rework WSAStringToAddress tests
by Marvin 03 Mar '17

03 Mar '17

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=29078 Your paranoid android. === w2008s64 (64 bit sock) === ws2_32:sock returned an error (3221225477) despite having no failures ws2_32:sock has no test summary line (early exit of the main process?)

2 1

Re: [PATCH] ws2_32: Turn SIO_GET_EXTENSION_FUNCTION_POINTER into a table
by Sebastian Lackner 02 Mar '17

02 Mar '17

On 02.03.2017 06:38, Bruno Jesus wrote: > From: Bruno Jesus <bjesus(a)codeweavers.com> > > I could not find any better way to avoid compilation warning than using a typedef for the function pointer. If there is a better way I'm all ears. > > Signed-off-by: Bruno Jesus <bjesus(a)codeweavers.com> > --- > dlls/ws2_32/socket.c | 94 +++++++++++++++++++++++----------------------------- > 1 file changed, 41 insertions(+), 53 deletions(-) It works fine here without any typedefs: --- a/dlls/ws2_32/socket.c +++ b/dlls/ws2_32/socket.c @@ -4945,10 +4945,8 @@ INT WINAPI WSAIoctl(SOCKET s, DWORD code, LPVOID in_buff, DWORD in_size, LPVOID if (found) { - typedef void (*func_ptr)(void); - TRACE("-> got %s\n", guid_funcs[i].name); - *(func_ptr *)out_buff = guid_funcs[i].func_ptr; + *(void **)out_buff = guid_funcs[i].func_ptr; break; } What kind of compiler warning do you get?

2 1

Re: [PATCH 2/2] comctl32/propsheet: Implement PSPCB_ADDREF/PSPCB_RELEASE notifications
by Dmitry Timoshkov 02 Mar '17

02 Mar '17

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/comctl32/propsheet.c | 41 +++++++++++++++++++++++++++++++++++------ > dlls/comctl32/tests/propsheet.c | 4 ---- > 2 files changed, 35 insertions(+), 10 deletions(-) And of course it's a pure coincidence that you immediately started to work on PSPCB_ADDREF/PSPCB_RELEASE once a patch for it has been added to wine-staging. I'd suggest to stop such ill-behaved practices, or at least give a credit to the source if you decided to "borrow" an idea. Or is this an indication that you just ran out of your own ideas to work on? :) -- Dmitry.

3 4

Re: [PATCH 1/2] mciavi32: Implement MCI_BREAK
by Andrew Eikum 02 Mar '17

02 Mar '17

On Wed, Mar 01, 2017 at 04:10:43AM -0300, Bruno Jesus wrote: > + wma->mci_break.flags = dwFlags; > + wma->mci_break.parms = *lpParms; The rest of this looks OK to me, but please guard access to wma's members with wma->cs. Andrew

1 0

Re: [v2 2/4] dinput: Handle username in EnumDevicesBySemantics.
by Andrew Eikum 02 Mar '17

02 Mar '17

Thanks for fixing these up, they look good to me. However this patch introduces a test failure: dinput.c:573: Test succeeded inside todo block: No device should be available after action mapping available=0 dinput.c:596: Test succeeded inside todo block: This user should own no devices owned=0 This is obviously fixed by your 4/4 patch, but we like to keep the tests clean in every commit. It's fine to squash the test changes into the code changes to create a 2-patch sequence with no test failures. Then I think it should be good to go in. Thanks, Andrew On Thu, Mar 02, 2017 at 12:11:24AM +0200, Jetro Jormalainen wrote: > EnumDevicesBySemantics enums only devices with given username when > DIEDBSFL_THISUSER is set and only unowned devices when > DIEDBSFL_AVAILABLEDEVICES is set. > > v2: Fixed problems noted by Andrew Eikum. > > Tested on Arch Linux and Rally Trophy Demo. > > Signed-off-by: Jetro Jormalainen <jje-wine(a)jv.jetro.fi> > --- > dlls/dinput/dinput_main.c | 111 +++++++++++++++++++++++++++++++++++++++------- > 1 file changed, 96 insertions(+), 15 deletions(-) > > diff --git a/dlls/dinput/dinput_main.c b/dlls/dinput/dinput_main.c > index 2bf9f38ba4..a59217472c 100644 > --- a/dlls/dinput/dinput_main.c > +++ b/dlls/dinput/dinput_main.c > @@ -923,6 +923,47 @@ static HRESULT WINAPI IDirectInput8WImpl_FindDevice(LPDIRECTINPUT8W iface, REFGU > return IDirectInput2WImpl_FindDevice( &This->IDirectInput7W_iface, rguid, pszName, pguidInstance ); > } > > +static BOOL should_enumerate_device(const WCHAR *username, DWORD dwFlags, > + struct list *device_players, REFGUID guid) > +{ > + BOOL should_enumerate = TRUE; > + struct DevicePlayer *device_player; > + > + /* Check if user owns this device */ > + if (dwFlags & DIEDBSFL_THISUSER && username && *username) > + { > + should_enumerate = FALSE; > + LIST_FOR_EACH_ENTRY(device_player, device_players, struct DevicePlayer, entry) > + { > + if (IsEqualGUID(&device_player->instance_guid, guid)) > + { > + if (*device_player->username && !lstrcmpW(username, device_player->username)) > + return TRUE; /* Device username matches */ > + break; > + } > + } > + } > + > + /* Check if this device is not owned by anyone */ > + if (dwFlags & DIEDBSFL_AVAILABLEDEVICES) { > + BOOL found = FALSE; > + should_enumerate = FALSE; > + LIST_FOR_EACH_ENTRY(device_player, device_players, struct DevicePlayer, entry) > + { > + if (IsEqualGUID(&device_player->instance_guid, guid)) > + { > + if (*device_player->username) > + found = TRUE; > + break; > + } > + } > + if (!found) > + return TRUE; /* Device does not have a username */ > + } > + > + return should_enumerate; > +} > + > static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > LPDIRECTINPUT8A iface, LPCSTR ptszUserName, LPDIACTIONFORMATA lpdiActionFormat, > LPDIENUMDEVICESBYSEMANTICSCBA lpCallback, > @@ -939,6 +980,7 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > int device_count = 0; > int remain; > DIDEVICEINSTANCEA *didevis = 0; > + WCHAR *username_w = 0; > > FIXME("(this=%p,%s,%p,%p,%p,%04x): semi-stub\n", This, debugstr_a(ptszUserName), lpdiActionFormat, > lpCallback, pvRef, dwFlags); > @@ -955,6 +997,14 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > > didevi.dwSize = sizeof(didevi); > > + if (ptszUserName) > + { > + int len = MultiByteToWideChar(CP_ACP, 0, ptszUserName, -1, 0, 0); > + > + username_w = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR)*len); > + MultiByteToWideChar(CP_ACP, 0, ptszUserName, -1, username_w, len); > + } > + > /* Enumerate all the joysticks */ > for (i = 0; i < NB_DINPUT_DEVICES; i++) > { > @@ -968,7 +1018,8 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > > /* Default behavior is to enumerate attached game controllers */ > enumSuccess = dinput_devices[i]->enum_deviceA(DI8DEVCLASS_GAMECTRL, DIEDFL_ATTACHEDONLY | dwFlags, &didevi, This->dwVersion, j); > - if (enumSuccess == S_OK) > + if (enumSuccess == S_OK && > + should_enumerate_device(username_w, dwFlags, &This->device_players, &didevi.guidInstance)) > { > if (device_count++) > didevis = HeapReAlloc(GetProcessHeap(), 0, didevis, sizeof(DIDEVICEINSTANCEA)*device_count); > @@ -980,8 +1031,15 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > } > > remain = device_count; > + /* Add keyboard and mouse to remaining device count */ > if (!(dwFlags & DIEDBSFL_FORCEFEEDBACK)) > - remain += sizeof(guids)/sizeof(guids[0]); > + { > + for (i = 0; i < sizeof(guids) / sizeof(guids[0]); i++) > + { > + if (should_enumerate_device(username_w, dwFlags, &This->device_players, guids[i])) > + remain++; > + } > + } > > for (i = 0; i < device_count; i++) > { > @@ -991,26 +1049,38 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > if (lpCallback(&didevis[i], lpdid, callbackFlags, --remain, pvRef) == DIENUM_STOP) > { > HeapFree(GetProcessHeap(), 0, didevis); > + HeapFree(GetProcessHeap(), 0, username_w); > return DI_OK; > } > } > > HeapFree(GetProcessHeap(), 0, didevis); > > - if (dwFlags & DIEDBSFL_FORCEFEEDBACK) return DI_OK; > + if (dwFlags & DIEDBSFL_FORCEFEEDBACK) > + { > + HeapFree(GetProcessHeap(), 0, username_w); > + return DI_OK; > + } > > /* Enumerate keyboard and mouse */ > for(i=0; i < sizeof(guids)/sizeof(guids[0]); i++) > { > - callbackFlags = diactionformat_priorityA(lpdiActionFormat, actionMasks[i]); > + if (should_enumerate_device(username_w, dwFlags, &This->device_players, guids[i])) > + { > + callbackFlags = diactionformat_priorityA(lpdiActionFormat, actionMasks[i]); > > - IDirectInput_CreateDevice(iface, guids[i], &lpdid, NULL); > - IDirectInputDevice_GetDeviceInfo(lpdid, &didevi); > + IDirectInput_CreateDevice(iface, guids[i], &lpdid, NULL); > + IDirectInputDevice_GetDeviceInfo(lpdid, &didevi); > > - if (lpCallback(&didevi, lpdid, callbackFlags, sizeof(guids)/sizeof(guids[0]) - (i+1), pvRef) == DIENUM_STOP) > - return DI_OK; > + if (lpCallback(&didevi, lpdid, callbackFlags, --remain, pvRef) == DIENUM_STOP) > + { > + HeapFree(GetProcessHeap(), 0, username_w); > + return DI_OK; > + } > + } > } > > + HeapFree(GetProcessHeap(), 0, username_w); > return DI_OK; > } > > @@ -1049,7 +1119,8 @@ static HRESULT WINAPI IDirectInput8WImpl_EnumDevicesBySemantics( > > /* Default behavior is to enumerate attached game controllers */ > enumSuccess = dinput_devices[i]->enum_deviceW(DI8DEVCLASS_GAMECTRL, DIEDFL_ATTACHEDONLY | dwFlags, &didevi, This->dwVersion, j); > - if (enumSuccess == S_OK) > + if (enumSuccess == S_OK && > + should_enumerate_device(ptszUserName, dwFlags, &This->device_players, &didevi.guidInstance)) > { > if (device_count++) > didevis = HeapReAlloc(GetProcessHeap(), 0, didevis, sizeof(DIDEVICEINSTANCEW)*device_count); > @@ -1061,8 +1132,15 @@ static HRESULT WINAPI IDirectInput8WImpl_EnumDevicesBySemantics( > } > > remain = device_count; > + /* Add keyboard and mouse to remaining device count */ > if (!(dwFlags & DIEDBSFL_FORCEFEEDBACK)) > - remain += sizeof(guids)/sizeof(guids[0]); > + { > + for (i = 0; i < sizeof(guids) / sizeof(guids[0]); i++) > + { > + if (should_enumerate_device(ptszUserName, dwFlags, &This->device_players, guids[i])) > + remain++; > + } > + } > > for (i = 0; i < device_count; i++) > { > @@ -1083,13 +1161,16 @@ static HRESULT WINAPI IDirectInput8WImpl_EnumDevicesBySemantics( > /* Enumerate keyboard and mouse */ > for(i=0; i < sizeof(guids)/sizeof(guids[0]); i++) > { > - callbackFlags = diactionformat_priorityW(lpdiActionFormat, actionMasks[i]); > + if (should_enumerate_device(ptszUserName, dwFlags, &This->device_players, guids[i])) > + { > + callbackFlags = diactionformat_priorityW(lpdiActionFormat, actionMasks[i]); > > - IDirectInput_CreateDevice(iface, guids[i], &lpdid, NULL); > - IDirectInputDevice_GetDeviceInfo(lpdid, &didevi); > + IDirectInput_CreateDevice(iface, guids[i], &lpdid, NULL); > + IDirectInputDevice_GetDeviceInfo(lpdid, &didevi); > > - if (lpCallback(&didevi, lpdid, callbackFlags, sizeof(guids)/sizeof(guids[0]) - (i+1), pvRef) == DIENUM_STOP) > - return DI_OK; > + if (lpCallback(&didevi, lpdid, callbackFlags, --remain, pvRef) == DIENUM_STOP) > + return DI_OK; > + } > } > > return DI_OK; > -- > 2.11.0 > > >

1 0

Re: [PATCH v3 1/5] winebus.sys: Handle linux input event device via udev
by Sebastian Lackner 01 Mar '17

01 Mar '17

I haven't done a full review yet, but here are some first comments. On 01.03.2017 17:16, Aric Stewart wrote: > + subsystem = udev_device_get_subsystem(dev); > usbdev = udev_device_get_parent_with_subsystem_devtype(dev, "usb", "usb_device"); > if (usbdev) > { > + #ifdef HAS_PROPER_INPUT_HEADER > + const platform_vtbl *other_vtbl = NULL; > + DEVICE_OBJECT *dup = NULL; > + if (strcmp(subsystem, "hidraw") == 0) > + other_vtbl = &lnxev_vtbl; > + else if (strcmp(subsystem, "input") == 0) > + other_vtbl = &hidraw_vtbl; > + > + if (other_vtbl) > + dup = bus_enumerate_hid_devices(other_vtbl, check_same_device, dev); Shouldn't we have some preference of either hidraw or linux event devices? Otherwise this could lead to different results in each run. > } > > +DEVICE_OBJECT* bus_enumerate_hid_devices(const platform_vtbl *vtbl, enum_func function, void* context) > +{ > + struct pnp_device *dev; > + DEVICE_OBJECT *ret = NULL; > + > + TRACE("(%p)\n", vtbl); > + > + EnterCriticalSection(&device_list_cs); > + LIST_FOR_EACH_ENTRY(dev, &pnp_devset, struct pnp_device, entry) > + { > + struct device_extension *ext = (struct device_extension *)dev->device->DeviceExtension; > + if (ext->vtbl != vtbl) continue; > + if (function(dev->device, context) == 0) > + ret = dev->device; > + break; This is wrong and will always abort after the first function call. > + } > + LeaveCriticalSection(&device_list_cs); > + return ret; > +} > +

2 1

Re: [PATCH 3/6] wined3d: Handle raw thread group shared memory declarations.
by Sebastian Lackner 01 Mar '17

01 Mar '17

On 28.02.2017 14:42, Józef Kucia wrote: > + reg_maps->tgsm_count = reg_idx + 1; Wouldn't it be better to set it to max(reg_maps->tgsm_count, ...) to allow decreasing reg indices (even if not seen in practice yet)? Alternatively you could also get rid of this variable and update patch 6 to check the index against the capacity. Best regards, Sebastian

2 1

Re: [PATCH 2/2] winmm: Dispatch MCI_BREAK to the driver
by Sebastian Lackner 01 Mar '17

01 Mar '17

On 01.03.2017 08:10, Bruno Jesus wrote: > + TRACE("(%08x, %08X, vkey %04X\n", wDevID, dwFlags, lpParms->nVirtKey); Did you forget to add a ")" ?

2 1

Re: [PATCH 1/2] server: Added server side named pipe read and write implementation and use it for message mode pipes.
by Sebastian Lackner 01 Mar '17

01 Mar '17

On 28.02.2017 14:14, Jacek Caban wrote: > + LIST_FOR_EACH_ENTRY( message, &pipe_end->message_queue, struct pipe_message, entry ) > + avail += message->iosb->in_size - message->read_pos; > + reply_size = min( reply_size, avail ); > + > + if (avail) > + { > + message = LIST_ENTRY( list_head(&pipe_end->message_queue), struct pipe_message, entry ); > + reply_size = min( reply_size, message->iosb->in_size ); > + } Isn't there a problem with this size check? Lets assume we have two messages with 10 byte, for the first one the read_pos = 5. Then avail == 15, and reply_size is clamped to 10 - but it will attempt to copy 10 bytes starting position 5? > + > + if (!(buffer = set_reply_data_size(FIELD_OFFSET( FILE_PIPE_PEEK_BUFFER, Data[reply_size] )))) return; > + buffer->NamedPipeState = 0; /* FIXME */ > + buffer->ReadDataAvailable = avail; > + buffer->NumberOfMessages = 0; /* FIXME */ > + buffer->MessageLength = 0; /* FIXME */ > + if (avail) memcpy( buffer->Data, (const char *)message->iosb->in_data + message->read_pos, reply_size ); > +} > +

2 1

Re: [PATCH v3] oledb32: Correct length calculation in DataConvert for DBTYPE_STR
by Huw Davies 01 Mar '17

01 Mar '17

On Tue, Feb 28, 2017 at 11:17:29PM +0000, Alistair Leslie-Hughes wrote: > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -816,23 +816,23 @@ static HRESULT WINAPI convert_DataConvert(IDataConvert* iface, > case DBTYPE_STR: > { > BSTR b; > - DBLENGTH bstr_len; > + DBLENGTH length; > INT bytes_to_copy; > - hr = IDataConvert_DataConvert(iface, src_type, DBTYPE_BSTR, src_len, &bstr_len, > + hr = IDataConvert_DataConvert(iface, src_type, DBTYPE_BSTR, src_len, &length, > src, &b, sizeof(BSTR), src_status, dst_status, > precision, scale, flags); > if(hr != S_OK) return hr; > - bstr_len = SysStringLen(b); > - *dst_len = bstr_len * sizeof(char); /* Doesn't include size for '\0' */ > + *dst_len = SysStringLen(b); /* Doesn't include size for '\0' */ You've gone back to confusing the length of a BSTR with the length of the char * str. We seem to be going round in circles here, so I've just sent in the correct fix. Please take a look at it to figure out where you were going wrong. Huw.

1 0

Re: [PATCH] d3dx9_36/tests: Fix a memory leak in test_createtext.
by Matteo Bruni 01 Mar '17

01 Mar '17

2017-02-27 7:52 GMT+01:00 Alex Henrie <alexhenrie24(a)gmail.com>: > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index 95dd06e466..64b7b8823c 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -4340,8 +4340,7 @@ static void test_createtext(IDirect3DDevice9 *device, HDC hdc, const char *text, > if (!compute_text_mesh(&mesh, text, deviation, extrusion, otm.otmEMSquare, glyphs)) > { > skip("Couldn't create mesh\n"); > - d3dxmesh->lpVtbl->Release(d3dxmesh); > - return; > + goto error; > } > mesh.fvf = D3DFVF_XYZ | D3DFVF_NORMAL; I would go in the other direction and strip all the error checking branches and gotos from those tests. compute_text_mesh() returns FALSE only on allocation failure and that's not supposed to happen in the controlled conditions of the test. It's probably better to just fail and crash in those cases.

2 1

Re: [PATCH 2/2] wineinstall - Add support for parallel builds using 'nproc' to detect cpu count
by Austin English 28 Feb '17

28 Feb '17

On Fri, Feb 24, 2017 at 6:30 PM, Chris Morgan <chmorgan(a)gmail.com> wrote: > Parallel builds can greatly reduce the overall build time on modern multi-core processors. > > Fall back to two parallel builds in the case where nproc is unavailable, most modern > processors have at least two cores. > > Use the 'NPROC' value defined by the environment if it is not null. > > Signed-off-by: Chris Morgan <chmorgan(a)gmail.com> > --- > tools/wineinstall | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/tools/wineinstall b/tools/wineinstall > index bfd62e3..080d590 100755 > --- a/tools/wineinstall > +++ b/tools/wineinstall > @@ -143,10 +143,19 @@ echo "in the meantime..." > echo > std_sleep > > +# If the NPROC environment variable isn't set use nproc, if available, to determine > +# the number of processors in the system, if not, fall back to a default NPROC value > +if type nproc2 &>/dev/null I don't think this will do what you want ;) Also, I'm pretty sure &> isn't Posix. You'd want something like: if type nproc > /dev/null 2>&1 -- -Austin GPG: 14FB D7EA A041 937B

5 7

Re: [PATCH] oledb32/tests: Fix a use-after-free in test_converttobyrefwstr.
by Alistair Leslie-Hughes 28 Feb '17

28 Feb '17

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

1 0

Re: [v2] Use CP 1200 (Unicode) for Win32/Win64 version info.
by Alexandre Julliard 28 Feb '17

28 Feb '17

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > [v2] Fix test failures in mshtml.dll caused by npmshtml.dll. > According to Gecko Plugin API Reference[1], plugin's version stamp must > be set to English US and Windows Multilingual, i.e. "040904E4". > [1] https://developer.mozilla.org/en-US/docs/Plugins/Guide/Plug-in_Development_… > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/npmshtml/rsrc.rc | 1 + > dlls/version/tests/info.c | 2 -- > include/wine/wine_common_ver.rc | 24 ++++++++++++++++++++++-- > 3 files changed, 23 insertions(+), 4 deletions(-) It's still failing here: ../../../tools/runtest -q -P wine -T ../../.. -M mshtml.dll -p mshtml_test.exe.so htmldoc && touch htmldoc.ok htmldoc.c:6287: Test failed: open failed: 80040152 wine: Unhandled page fault on read access to 0xdeadbeef at address 0x7ed051dd (thread 0154), starting debugger... Unhandled exception: page fault on read access to 0xdeadbeef in 32-bit code (0x7ed051dd). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ed051dd ESP:0033fc20 EBP:0033fc78 EFLAGS:00010202( R- -- I - - - ) EAX:deadbeef EBX:7ed6a000 ECX:00000001 EDX:7ed80f00 ESI:0000188d EDI:7ed4388a Stack dump: 0x0033fc20: 00000001 7ed449d1 80040152 7ed050ad 0x0033fc30: 005e0000 00689650 005e8de8 00000000 0x0033fc40: 7ed39473 7ed7f1a0 80040152 7ed4388a 0x0033fc50: 005b4d80 7ed4388a 005e8de8 deadbeef 0x0033fc60: 7ed4521a 00000000 7ed04f0e 7ed6a000 0x0033fc70: 005b4d80 7ed4388a 0033fcd8 7ed0ddd9 Backtrace: =>0 0x7ed051dd test_open_window+0x2dd(doc=<is not available>, do_block=0) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/mshtml.h:51848] in mshtml_test (0x0033fc78) 1 0x7ed0ddd9 test_HTMLDocument_http+0x678(with_wbapp=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/htmldoc.c:7877] in mshtml_test (0x0033fcd8) 2 0x7ed128d9 func_htmldoc+0xda8() [/home/julliard/wine/wine/dlls/mshtml/tests/htmldoc.c:8742] in mshtml_test (0x0033fd58) 3 0x7ecc305d main+0x25c(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/wine/test.h:589] in mshtml_test (0x0033fe08) 4 0x7ed38d8b __wine_spec_exe_entry+0x4a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mshtml_test (0x0033fe48) 5 0x7b45e56c call_process_entry+0xb() in kernel32 (0x0033fe68) 6 0x7b45f4a9 start_process+0x68(entry=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1116] in kernel32 (0x0033fea8) 7 0x7bc8071c call_thread_func_wrapper+0xb() in ntdll (0x0033fec8) 8 0x7bc834d9 call_thread_func+0xa8(entry=0x7b45f440, arg=0x7ed38d40, frame=0x33ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2759] in ntdll (0x0033ffa8) 9 0x7bc806fa call_thread_entry_point+0x11() in ntdll (0x0033ffc8) 10 0x7bc53f73 start_process+0x12(arg=0xffcb6418) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3054] in ntdll (0x0033ffe8) 11 0xf756d8dd __x86.get_pc_thunk.di+0x2a() in libwine.so.1 (0x00000000) 12 0xf756da40 wine_switch_to_stack+0x1f(func=0x7bc53f60, arg=0xffcb6418, stack=0x340000) [/home/julliard/wine/wine/libs/wine/port.c:77] in libwine.so.1 (0xffcb63e8) 13 0x7bc59b26 LdrInitializeThunk+0x235(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3115] in ntdll (0xffcb6438) 14 0x7b4653af __wine_kernel_init+0xa4e() [/home/julliard/wine/wine/dlls/kernel32/process.c:1310] in kernel32 (0xffcb7328) 15 0x7bc5a983 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3324] in ntdll (0xffcb7398) 16 0xf756bb43 wine_init+0x2a2(argc=0x3, argv=0xffcb78e4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:956] in libwine.so.1 (0xffcb73e8) 17 0x7c000b58 main+0x97(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:254] in <wine-loader> (0xffcb7838) 18 0xf7375276 __libc_start_main+0xf5() in libc.so.6 (0x00000000) 0x7ed051dd test_open_window+0x2dd [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/mshtml.h:51848] in mshtml_test: movl 0x0(%eax),%edx 51848 return This->lpVtbl->close(This); -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/6] wined3d: Handle raw thread group shared memory declarations.
by Henri Verbeet 28 Feb '17

28 Feb '17

On 28 February 2017 at 14:42, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -1047,6 +1047,31 @@ static HRESULT shader_get_registers_used(struct wined3d_shader *shader, const st > { > reg_maps->temporary_count = ins.declaration.count; > } > + else if (ins.handler_idx == WINED3DSIH_DCL_TGSM_RAW) > + { > + unsigned int reg_idx = ins.declaration.tgsm_raw.reg.reg.idx[0].offset; > + if (reg_idx >= MAX_TGSM_REGISTERS) > + { > + ERR("Invalid TGSM register index %u.\n", reg_idx); > + break; > + } > + if (shader_version.type == WINED3D_SHADER_TYPE_COMPUTE) > + { > + struct wined3d_shader_tgsm *tgsm; > + > + if (!wined3d_array_reserve((void **)&reg_maps->tgsm, &reg_maps->tgsm_capacity, > + reg_idx + 1, sizeof(*reg_maps->tgsm))) I'm not sure about this. I guess the expectation is that these will get allocated consecutively and starting from 0, while even starting at MAX_TGSM_REGISTERS-1 and going down wouldn't be terrible. Still, I'm wondering if it wouldn't be worth it to only allocate space for the number of declarations, and use e.g. bsearch().

2 1

Re: [PATCH 1/5] wined3d: Use the command stream state in wined3d_cs_exec_draw().
by Sebastian Lackner 28 Feb '17

28 Feb '17

On 28.02.2017 06:11, Henri Verbeet wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/wined3d/cs.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > This patch causes corrupted graphics in multiple games. The problem is caused by uninitialized memory in the wined3d_state structs. Currently the struct is only cleared in wined3d_cs_exec_reset_state, but it probably should be cleared always when WINED3D_STATE_INIT_DEFAULT is passed, otherwise the CS and the main state can go out of sync. Could you please take a look? Example app (~40 MB): https://archive.org/download/MotoRacer2Demo/MotoRacer2Demo.zip (sha256: 02c8523d61619b9f65d874e15af9838ebf78938a720c5b61504d97c0b7cc68c9) Best regards, Sebastian

2 2

Re: tools: remove wineinstall
by Dmitry Timoshkov 28 Feb '17

28 Feb '17

Austin English <austinenglish(a)gmail.com> wrote: > -2. QUICK START > - > -Whenever you compile from source, it is recommended to use the Wine > -Installer to build and install Wine. From the top-level directory > -of the Wine source (which contains this file), run: > - > -./tools/wineinstall > - > -Run programs as "wine program". For more information and problem > -resolution, read the rest of this file, the Wine man page, and > -especially the wealth of information found at http://www.winehq.org. Perhaps the 2nd part of this section should stay since it doesn't have anything to do with the wineinstall script. And regarding compilation it's worth to at least mention wiki/docs/forums I'd guess. -- Dmitry.

1 0

Re: Proposal: winetest 'context'
by Sebastian Lackner 27 Feb '17

27 Feb '17

On 27.02.2017 20:19, Mark Jansen wrote: > This syntax is a lot better, > however it will break when ':' is used in the format string. > It might be a better idea to keep a list of indexes alongside the > context buffer? Not sure if its required. I think it would be a bit confusing when ":" is used inside of a context string. If devs want to use ":" as separator for variables they could also do something like: with_context("i=%d", i) with_context("j=%d", j) { // here some tests } > > As for the name, use_context or set_context ? That would also be fine, but I don't think its much better than with_context(). > > regards, > > Mark Jansen > > On Mon, Feb 27, 2017 at 12:06 AM, Sebastian Lackner > <sebastian(a)fds-team.de> wrote: >> On 25.02.2017 13:34, Józef Kucia wrote: >>> On Tue, Feb 14, 2017 at 5:04 PM, Mark Jansen <learn0more+wine(a)gmail.com> wrote: >>>> Hello, >>>> >>>> Often when testing something, helper functions are introduced that are >>>> called with different data (for example when iterating over tables). >>>> >>>> Attached patch (winetest_set_context.diff) is a proposal that allows >>>> tests to specify a 'context', that will be printed in the failure >>>> message. >>>> This way, the actual test code does not have to prefix every case with >>>> a trace, or include the data in every test macro. >>>> The patch is written so that tests do not have to use this mechanism, >>>> so there is no need to convert all tests at once. >>>> Second attachment (winetest_ctx_example.diff) shows how an existing >>>> test could be converted to use this new technique. >>> >>> For what it's worth, if we had a mechanism to set a context for test >>> messages, I would gladly use it in d3d11 tests. >>> >>> Cheers, >>> Józef >> >> I would also like to see such a feature, however I'm not really happy with >> a single context string which has to be set and reset manually. So, here is >> an alternative proposal which allows to use a block-syntax like: >> >> --- snip --- >> with_context("i = %d, j = %d", i, j) >> { >> // here some tests >> } >> --- snip --- >> >> Blocks can also be nested, and its easy to combine them with a loop: >> >> --- snip --- >> for (i = 0; i < 100; i++) with_context("test %d", i) >> { >> // here some tests (don't use break!) >> } >> --- snip --- >> >> The only disadvantage is that we need variadic macros (__VA_ARGS__), but it >> looks like they are already used in a bunch of other tests, so thats probably >> not a real problem. Please let me know what you think about this method, and >> also if you have suggestions for a better name. >> >> Best regards, >> Sebastian >>

1 0

The Wine Project has been accepted as a GSoC 2017 mentor organization!
by André Hentschel 27 Feb '17

27 Feb '17

I just invited a lot of possible Mentors, if I missed someone, please let me know

1 0

Re: [1/4] dinput: Keep username same between device objects.
by Bruno Jesus 27 Feb '17

27 Feb '17

On Wed, Feb 22, 2017 at 8:22 PM, Jetro Jormalainen <jje-wine(a)jv.jetro.fi> wrote: > Tested on Windows 10, Windows XP and Arch Linux. Hi, thanks for the patches. In order to help testing do you mind explaining how to test them? Like is there any game demo/freeware that is able to benefit from the patches?

2 1

Re: [PATCH 3/5] winebus.sys: Process device reports for linux event devices
by Sebastian Lackner 27 Feb '17

27 Feb '17

On 27.02.2017 16:09, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 163 +++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 162 insertions(+), 1 deletion(-) > > > > 0003-winebus.sys-Process-device-reports-for-linux-event-dev.txt > > > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index e2a475ccd8..2f198c7d4f 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -242,6 +242,9 @@ struct wine_input_absinfo { > struct wine_input_private { > struct platform_private base; > > + int buffer_length; > + BYTE *report_buffer; > + > int report_descriptor_size; > BYTE *report_descriptor; > > @@ -340,6 +343,87 @@ static const BYTE* what_am_I(struct udev_device *dev) > return Unknown; > } > > +static BOOL set_button_value(struct wine_input_private *ext, int code, int value) > +{ > + int index = ext->button_map[code]; > + int bindex = index / 8; > + int b = index % 8; > + BYTE mask; > + > + mask = 1<<b; > + if (value) > + ext->report_buffer[bindex] = ext->report_buffer[bindex] | mask; > + else > + { > + mask = ~mask; > + ext->report_buffer[bindex] = ext->report_buffer[bindex] & mask; > + } > + return TRUE; > +} > + > +static BOOL set_abs_axis_value(struct wine_input_private *ext, int code, int value) > +{ > + int index; > + /* check for hatswitches */ > + if (code <= ABS_HAT3Y && code >= ABS_HAT0X) > + { > + index = code - ABS_HAT0X; > + ext->hat_values[index] = value; > + if ((code - ABS_HAT0X) % 2) > + index--; > + if (ext->hat_values[index] == 0) > + { > + if (ext->hat_values[index+1] == 0) > + value = 8; > + else if (ext->hat_values[index+1] < 0) > + value = 0; > + else > + value = 4; > + } > + else if (ext->hat_values[index] > 0) > + { > + if (ext->hat_values[index+1] == 0) > + value = 2; > + else if (ext->hat_values[index+1] < 0) > + value = 1; > + else > + value = 3; > + } > + else > + { > + if (ext->hat_values[index+1] == 0) > + value = 6; > + else if (ext->hat_values[index+1] < 0) > + value = 7; > + else > + value = 5; > + } > + ext->report_buffer[ext->hat_map[index]] = value; > + return TRUE; > + } > + else if (code < HID_ABS_MAX && ABS_to_HID_map[code][0] != 0) > + { > + index = ext->abs_map[code].report_index; > + *((WORD*)&ext->report_buffer[index]) = MulDiv(value, 0xff, ext->abs_map[code].info.maximum - ext->abs_map[code].info.minimum); > + return TRUE; > + } > + return FALSE; > +} > + > +static BOOL set_rel_axis_value(struct wine_input_private *ext, int code, int value) > +{ > + int index; > + if (code < HID_REL_MAX && REL_to_HID_map[code][0] != 0) > + { > + index = ext->rel_map[code]; > + if (value > 127) value = 127; > + if (value < -127) value = -127; > + ext->report_buffer[index] = value; > + return TRUE; > + } > + return FALSE; > +} > + > static VOID build_report_descriptor(struct wine_input_private *ext, struct udev_device *dev) > { > int abs_pages[TOP_ABS_PAGE][HID_ABS_MAX+1]; > @@ -510,6 +594,37 @@ static VOID build_report_descriptor(struct wine_input_private *ext, struct udev_ > memcpy(report_ptr, report_tail, sizeof(report_tail)); > > ext->report_descriptor_size = descript_size; > + ext->buffer_length = report_size; > + ext->report_buffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, report_size); > + > + /* Initialize axis in the report */ > + for (i = 0; i < HID_ABS_MAX; i++) > + if (test_bit(absbits, i)) > + set_abs_axis_value(ext, i, ext->abs_map[i].info.value); > +} > + > +static BOOL set_report_from_event(struct wine_input_private *ext, struct input_event *ie) > +{ > + switch(ie->type) > + { > +#ifdef EV_SYN > + case EV_SYN: > + return FALSE; > +#endif > +#ifdef EV_MSC > + case EV_MSC: > + return FALSE; > +#endif > + case EV_KEY: > + return set_button_value(ext, ie->code, ie->value); > + case EV_ABS: > + return set_abs_axis_value(ext, ie->code, ie->value); > + case EV_REL: > + return set_rel_axis_value(ext, ie->code, ie->value); > + default: > + ERR("TODO: Process Report (%i, %i)\n",ie->type, ie->code); > + return FALSE; > + } > } > #endif > > @@ -846,9 +961,52 @@ static NTSTATUS lnxev_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buff > return STATUS_NOT_IMPLEMENTED; > } > > +static DWORD CALLBACK lnxev_device_report_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + struct wine_input_private *private = input_impl_from_DEVICE_OBJECT(device); > + struct pollfd plfds[2]; > + > + plfds[0].fd = private->base.device_fd; > + plfds[0].events = POLLIN; > + plfds[0].revents = 0; > + plfds[1].fd = private->base.control_pipe[0]; > + plfds[1].events = POLLIN; > + plfds[1].revents = 0; > + > + while (1) > + { > + int size; > + struct input_event ie; > + > + if (poll(plfds, 2, -1) <= 0) continue; > + if (plfds[1].revents || !private->report_buffer || private->buffer_length == 0) It would be better to catch memory allocation failures earlier than while processing device reports. > + break; > + size = read(plfds[0].fd, &ie, sizeof(ie)); > + if (size == -1) > + TRACE_(hid_report)("Read failed. Likely an unplugged device\n"); > + else if (size == 0) > + TRACE_(hid_report)("Failed to read report\n"); > + else if (set_report_from_event(private, &ie)) > + process_hid_report(device, private->report_buffer, private->buffer_length); > + } > + return 0; > +} > + > static NTSTATUS lnxev_begin_report_processing(DEVICE_OBJECT *device) > { > - return STATUS_NOT_IMPLEMENTED; > + struct wine_input_private *private = input_impl_from_DEVICE_OBJECT(device); > + You have to check that the thread was not started yet. > + pipe(private->base.control_pipe); Some error handling wouldn't hurt. > + private->base.report_thread = CreateThread(NULL, 0, lnxev_device_report_thread, device, 0, NULL); > + if (!private->base.report_thread) > + { > + ERR("Unable to create device report thread\n"); > + close(private->base.control_pipe[0]); > + close(private->base.control_pipe[1]); > + return STATUS_UNSUCCESSFUL; > + } > + return STATUS_SUCCESS; > } > > static NTSTATUS lnxev_set_output_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *written) > @@ -990,6 +1148,9 @@ static void try_remove_device(struct udev_device *dev) > close(private->control_pipe[0]); > close(private->control_pipe[1]); > CloseHandle(private->report_thread); > +#ifdef HAS_PROPER_INPUT_HEADER > + HeapFree(GetProcessHeap(), 0, ((struct wine_input_private*)private)->report_buffer); It looks like this will attempt to release an invalid pointer for hidraw devices. > +#endif > } > > dev = private->udev_device; > > >

1 0

Re: [2/4] dinput: Handle username in EnumDevicesBySemantics.
by Andrew Eikum 27 Feb '17

27 Feb '17

On Thu, Feb 23, 2017 at 01:22:19AM +0200, Jetro Jormalainen wrote: > @@ -955,6 +998,14 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > > didevi.dwSize = sizeof(didevi); > > + if (ptszUserName) > + { > + username_size = MultiByteToWideChar(CP_ACP, 0, ptszUserName, -1, 0, 0); > + MultiByteToWideChar(CP_ACP, 0, ptszUserName, -1, username_w, username_size); Normally, we use the return from MultiByteToWideChar to allocate the destination buffer. You could switch to that. I'm not opposed to doing it on the stack like this, but then there's no need for username_size. You can just pass the size of the buffer in WCHARs as the last param of MultiByteToWideChar. Andrew

1 0

Re: [1/4] dinput: Keep username same between device objects.
by Andrew Eikum 27 Feb '17

27 Feb '17

On Thu, Feb 23, 2017 at 01:22:18AM +0200, Jetro Jormalainen wrote: > @@ -1308,11 +1308,24 @@ HRESULT WINAPI IDirectInputDevice2WImpl_GetProperty(LPDIRECTINPUTDEVICE8W iface, > case (DWORD_PTR) DIPROP_USERNAME: > { > LPDIPROPSTRING ps = (LPDIPROPSTRING)pdiph; > + struct DevicePlayer *device_player; > > if (pdiph->dwSize != sizeof(DIPROPSTRING)) return DIERR_INVALIDPARAM; > > - lstrcpynW(ps->wsz, This->username, sizeof(ps->wsz)/sizeof(WCHAR)); > - break; > + LIST_FOR_EACH_ENTRY(device_player, &This->dinput->device_players, > + struct DevicePlayer, entry) > + { > + if (IsEqualGUID(&device_player->guid, &This->guid)) > + { > + if (lstrlenW(device_player->username)) Please use *username instead of strlen in places where we don't actually care about the string length. Same in the other patch. > @@ -1390,10 +1403,32 @@ HRESULT WINAPI IDirectInputDevice2WImpl_SetProperty( > case (DWORD_PTR) DIPROP_USERNAME: > { > LPCDIPROPSTRING ps = (LPCDIPROPSTRING)pdiph; > + struct DevicePlayer *device_player; > + unsigned char found = 0; Please use BOOL, TRUE, and FALSE for booleans. Some people use those symbols for their static analyzers. Same in the other patch. > @@ -56,6 +57,12 @@ struct dinput_device { > HRESULT (*create_device)(IDirectInputImpl *dinput, REFGUID rguid, REFIID riid, LPVOID *pdev, int unicode); > }; > > +struct DevicePlayer { > + GUID guid; "guid" is a little vague. This refers to the specific device instance, right? Maybe device_guid or instance_guid? Andrew

1 0

Re: [PATCH 2/5] winebus.sys: Build device reports for linux event devices
by Sebastian Lackner 27 Feb '17

27 Feb '17

On 27.02.2017 16:09, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 437 +++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 435 insertions(+), 2 deletions(-) > > > > 0002-winebus.sys-Build-device-reports-for-linux-event-devic.txt > > > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 2dcc7fb442..e2a475ccd8 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -63,6 +63,10 @@ > #include "wine/debug.h" > #include "wine/unicode.h" > > +#ifdef HAS_PROPER_INPUT_HEADER > +# include "hidusage.h" > +#endif > + > #include "bus.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > @@ -97,6 +101,418 @@ static inline struct platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *de > return (struct platform_private *)get_platform_private(device); > } > > +#ifdef HAS_PROPER_INPUT_HEADER > +static const BYTE report_header[] = { > + 0x05, 0x01, /* USAGE_PAGE (Generic Desktop) */ > + 0x09, 0x00, /* USAGE (??) */ > + 0xa1, 0x01, /* COLLECTION (Application) */ > + 0x09, 0x01, /* USAGE () */ > + 0xa1, 0x00, /* COLLECTION (Physical) */ > +}; > + > +#define IDX_HEADER_PAGE 1 > +#define IDX_HEADER_USAGE 3 > + > +static const BYTE report_buttons[] = { > + 0x05, 0x09, /* USAGE_PAGE (Button) */ > + 0x19, 0x01, /* USAGE_MINIMUM (Button 1) */ > + 0x29, 0x03, /* USAGE_MAXIMUM (Button 3) */ > + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ > + 0x25, 0x01, /* LOGICAL_MAXIMUM (1) */ > + 0x35, 0x00, /* LOGICAL_MINIMUM (0) */ > + 0x45, 0x01, /* LOGICAL_MAXIMUM (1) */ > + 0x95, 0x03, /* REPORT_COUNT (3) */ > + 0x75, 0x01, /* REPORT_SIZE (1) */ > + 0x81, 0x02, /* INPUT (Data,Var,Abs) */ > +}; > +#define IDX_BUTTON_MIN_USAGE 3 > +#define IDX_BUTTON_MAX_USAGE 5 > +#define IDX_BUTTON_COUNT 11 > + > +static const BYTE report_padding[] = { > + 0x95, 0x03, /* REPORT_COUNT (3) */ > + 0x75, 0x01, /* REPORT_SIZE (1) */ > + 0x81, 0x03, /* INPUT (Cnst,Var,Abs) */ > +}; > +#define IDX_PADDING_BIT_COUNT 1 > + > +static const BYTE report_axis_header[] = { > + 0x05, 0x01, /* USAGE_PAGE (Generic Desktop) */ > +}; > +#define IDX_AXIS_PAGE 1 > + > + > +static const BYTE report_axis_usage[] = { > + 0x09, 0x30, /* USAGE (X) */ > +}; > +#define IDX_AXIS_USAGE 1 > + > +static const BYTE report_abs_axis_tail[] = { > + 0x16, 0x00, 0x00, /* LOGICAL_MINIMUM (0) */ > + 0x26, 0xff, 0x00, /* LOGICAL_MAXIMUM (0xff) */ > + 0x35, 0x00, /* PHYSICAL_MINIMUM (0) */ > + 0x46, 0xff, 0x00, /* PHYSICAL_MAXIMUM (256) */ > + 0x75, 0x10, /* REPORT_SIZE (16) */ > + 0x95, 0x00, /* REPORT_COUNT (2) */ > + 0x81, 0x02, /* INPUT (Data,Var,Abs) */ > +}; > +#define IDX_ABS_AXIS_COUNT 14 > + > +static const BYTE report_rel_axis_tail[] = { > + 0x15, 0x81, /* LOGICAL_MINIMUM (0) */ > + 0x25, 0x7f, /* LOGICAL_MAXIMUM (0xffff) */ > + 0x75, 0x08, /* REPORT_SIZE (16) */ > + 0x95, 0x02, /* REPORT_COUNT (2) */ > + 0x81, 0x06, /* INPUT (Data,Var,Rel) */ > +}; > +#define IDX_REL_AXIS_COUNT 7 > + > +static const BYTE report_hatswitch[] = { > + 0x05, 0x01, /* USAGE_PAGE (Generic Desktop) */ > + 0x09, 0x39, /* USAGE (Hatswitch) */ > + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ > + 0x25, 0x08, /* LOGICAL_MAXIMUM (0x08) */ > + 0x35, 0x00, /* PHYSICAL_MINIMUM (0) */ > + 0x45, 0x08, /* PHYSICAL_MAXIMUM (8) */ > + 0x75, 0x08, /* REPORT_SIZE (8) */ > + 0x95, 0x01, /* REPORT_COUNT (1) */ > + 0x81, 0x02, /* INPUT (Data,Var,Abs) */ > +}; > +#define IDX_HATSWITCH_COUNT 15 > + > +static const BYTE report_tail[] = { > + 0xc0, /* END_COLLECTION */ > + 0xc0 /* END_COLLECTION */ > +}; > + > +static const BYTE ABS_to_HID_map[][2] = { > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_X}, /*ABS_X*/ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_Y}, /*ABS_Y*/ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_Z}, /*ABS_Z*/ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_RX}, /*ABS_RX*/ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_RY}, /*ABS_RY*/ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_RZ}, /*ABS_RZ*/ > + {HID_USAGE_PAGE_SIMULATION, HID_USAGE_SIMULATION_THROTTLE}, /*ABS_THROTTLE*/ > + {HID_USAGE_PAGE_SIMULATION, HID_USAGE_SIMULATION_RUDDER}, /*ABS_RUDDER*/ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_WHEEL}, /*ABS_WHEEL*/ > + {HID_USAGE_PAGE_SIMULATION, 0xC4}, /*ABS_GAS*/ > + {HID_USAGE_PAGE_SIMULATION, 0xC5}, /*ABS_BRAKE*/ > + {0,0}, /*ABS_HAT0X*/ > + {0,0}, /*ABS_HAT0Y*/ > + {0,0}, /*ABS_HAT1X*/ > + {0,0}, /*ABS_HAT1Y*/ > + {0,0}, /*ABS_HAT2X*/ > + {0,0}, /*ABS_HAT2Y*/ > + {0,0}, /*ABS_HAT3X*/ > + {0,0}, /*ABS_HAT3Y*/ > + {HID_USAGE_PAGE_DIGITIZER, 0x30}, /*ABS_PRESSURE*/ > + {0, 0}, /*ABS_DISTANCE*/ > + {HID_USAGE_PAGE_DIGITIZER, 0x3D}, /*ABS_TILT_X*/ > + {HID_USAGE_PAGE_DIGITIZER, 0x3F}, /*ABS_TILT_Y*/ > + {0, 0}, /*ABS_TOOL_WIDTH*/ > + {0, 0}, > + {0, 0}, > + {0, 0}, > + {HID_USAGE_PAGE_CONSUMER, 0xE0} /*ABS_VOLUME*/ > +}; > +#define HID_ABS_MAX (ABS_VOLUME+1) > +#define TOP_ABS_PAGE (HID_USAGE_PAGE_DIGITIZER+1) > + > +static const BYTE REL_to_HID_map[][2] = { > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_X}, /* REL_X */ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_Y}, /* REL_Y */ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_Z}, /* REL_Z */ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_RX}, /* REL_RX */ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_RY}, /* REL_RY */ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_RZ}, /* REL_RZ */ > + {0, 0}, /* REL_HWHEEL */ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_DIAL}, /* REL_DIAL */ > + {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_WHEEL}, /* REL_WHEEL */ > + {0, 0} /* REL_MISC */ > +}; > + > +#define HID_REL_MAX (REL_MISC+1) > +#define TOP_REL_PAGE (HID_USAGE_PAGE_CONSUMER+1) > + > +struct wine_input_absinfo { > + struct input_absinfo info; > + BYTE report_index; > +}; > + > +struct wine_input_private { > + struct platform_private base; > + > + int report_descriptor_size; > + BYTE *report_descriptor; > + > + BYTE button_map[KEY_MAX]; > + BYTE rel_map[HID_REL_MAX]; > + BYTE hat_map[8]; > + int hat_values[8]; > + struct wine_input_absinfo abs_map[HID_ABS_MAX]; > +}; > + > +#define test_bit(arr,bit) (((BYTE*)(arr))[(bit)>>3]&(1<<((bit)&7))) > + > +static BYTE *add_button_block(BYTE* report_ptr, BYTE usage_min, BYTE usage_max) > +{ > + memcpy(report_ptr, report_buttons, sizeof(report_buttons)); > + report_ptr[IDX_BUTTON_MIN_USAGE] = usage_min; > + report_ptr[IDX_BUTTON_MAX_USAGE] = usage_max; > + report_ptr[IDX_BUTTON_COUNT] = (usage_max - usage_min) + 1; > + return report_ptr + sizeof(report_buttons); > +} > + > +static BYTE *add_axis_block(BYTE *report_ptr, BYTE count, BYTE page, BYTE *usages, BOOL absolute) > +{ > + int i; > + memcpy(report_ptr, report_axis_header, sizeof(report_axis_header)); > + report_ptr[IDX_AXIS_PAGE] = page; > + report_ptr += sizeof(report_axis_header); > + for (i = 0; i < count; i++) > + { > + memcpy(report_ptr, report_axis_usage, sizeof(report_axis_usage)); > + report_ptr[IDX_AXIS_USAGE] = usages[i]; > + report_ptr += sizeof(report_axis_usage); > + } > + if (absolute) > + { > + memcpy(report_ptr, report_abs_axis_tail, sizeof(report_abs_axis_tail)); > + report_ptr[IDX_ABS_AXIS_COUNT] = count; > + report_ptr += sizeof(report_abs_axis_tail); > + } > + else > + { > + memcpy(report_ptr, report_rel_axis_tail, sizeof(report_rel_axis_tail)); > + report_ptr[IDX_REL_AXIS_COUNT] = count; > + report_ptr += sizeof(report_rel_axis_tail); > + } > + return report_ptr; > +} > + > +static BYTE *add_padding_block(BYTE *report_ptr, BYTE bitcount) > +{ > + memcpy(report_ptr, report_padding, sizeof(report_padding)); > + report_ptr[IDX_PADDING_BIT_COUNT] = bitcount; > + return report_ptr + sizeof(report_padding); > +} > + > +static BYTE *add_hatswitch(BYTE *report_ptr, INT count) > +{ > + memcpy(report_ptr, report_hatswitch, sizeof(report_hatswitch)); > + report_ptr[IDX_HATSWITCH_COUNT] = count; > + return report_ptr + sizeof(report_hatswitch); > +} > + > +static const BYTE* what_am_I(struct udev_device *dev) > +{ > + static const BYTE Unknown[2] = {HID_USAGE_PAGE_GENERIC, 0}; > + static const BYTE Mouse[2] = {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_MOUSE}; > + static const BYTE Keyboard[2] = {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_KEYBOARD}; > + static const BYTE Gamepad[2] = {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_GAMEPAD}; > + static const BYTE Keypad[2] = {HID_USAGE_PAGE_GENERIC, HID_USAGE_GENERIC_KEYPAD}; > + static const BYTE Tablet[2] = {HID_USAGE_PAGE_DIGITIZER, 0x2}; > + static const BYTE Touchscreen[2] = {HID_USAGE_PAGE_DIGITIZER, 0x4}; > + static const BYTE Touchpad[2] = {HID_USAGE_PAGE_DIGITIZER, 0x5}; > + > + struct udev_device *parent = dev; > + > + /* Look to the parents until we get a clue */ > + while (parent) > + { > + if (udev_device_get_property_value(parent, "ID_INPUT_MOUSE")) > + return Mouse; > + else if (udev_device_get_property_value(parent, "ID_INPUT_KEYBOARD")) > + return Keyboard; > + else if (udev_device_get_property_value(parent, "ID_INPUT_JOYSTICK")) > + return Gamepad; > + else if (udev_device_get_property_value(parent, "ID_INPUT_KEY")) > + return Keypad; > + else if (udev_device_get_property_value(parent, "ID_INPUT_TOUCHPAD")) > + return Touchpad; > + else if (udev_device_get_property_value(parent, "ID_INPUT_TOUCHSCREEN")) > + return Touchscreen; > + else if (udev_device_get_property_value(parent, "ID_INPUT_TABLET")) > + return Tablet; > + > + parent = udev_device_get_parent_with_subsystem_devtype(parent, "input", NULL); > + } > + return Unknown; > +} > + > +static VOID build_report_descriptor(struct wine_input_private *ext, struct udev_device *dev) > +{ > + int abs_pages[TOP_ABS_PAGE][HID_ABS_MAX+1]; > + int rel_pages[TOP_REL_PAGE][HID_REL_MAX+1]; > + BYTE absbits[(ABS_MAX+7)/8]; > + BYTE relbits[(REL_MAX+7)/8]; > + BYTE keybits[(KEY_MAX+7)/8]; > + BYTE *report_ptr; > + INT i, descript_size; > + INT report_size; > + INT button_count, abs_count, rel_count, hat_count; > + const BYTE *device_usage = what_am_I(dev); > + > + if (ioctl(ext->base.device_fd, EVIOCGBIT(EV_REL, sizeof(relbits)), relbits) == -1) > + { > + WARN("ioctl(EVIOCGBIT, EV_REL) failed: %d %s\n", errno, strerror(errno)); > + return; > + } > + if (ioctl(ext->base.device_fd, EVIOCGBIT(EV_ABS, sizeof(absbits)), absbits) == -1) > + { > + WARN("ioctl(EVIOCGBIT, EV_ABS) failed: %d %s\n", errno, strerror(errno)); > + return; > + } > + if (ioctl(ext->base.device_fd, EVIOCGBIT(EV_KEY, sizeof(keybits)), keybits) == -1) > + { > + WARN("ioctl(EVIOCGBIT, EV_KEY) failed: %d %s\n", errno, strerror(errno)); > + return; > + } > + > + descript_size = sizeof(report_header) + sizeof(report_tail); > + report_size = 0; > + > + /* For now lump all buttons just into incremental usages, Ignore Keys */ > + button_count = 0; > + for (i = BTN_MISC; i < KEY_MAX; i++) > + { > + if (test_bit(keybits, i)) > + { > + ext->button_map[i] = button_count; > + button_count++; > + } > + } > + if (button_count) > + { > + descript_size += sizeof(report_buttons); > + if (button_count % 8) > + descript_size += sizeof(report_padding); > + report_size = (button_count + 7) / 8; > + } > + > + abs_count = 0; > + memset(abs_pages, 0, sizeof(abs_pages)); > + for (i = 0; i < HID_ABS_MAX; i++) > + if (test_bit(absbits, i)) > + { > + abs_pages[ABS_to_HID_map[i][0]][0]++; > + abs_pages[ABS_to_HID_map[i][0]][abs_pages[ABS_to_HID_map[i][0]][0]] = i; > + > + ioctl(ext->base.device_fd, EVIOCGABS(i), &(ext->abs_map[i])); > + if (abs_pages[ABS_to_HID_map[i][0]][0] == 1) > + { > + descript_size += sizeof(report_axis_header); > + descript_size += sizeof(report_abs_axis_tail); > + } > + } > + /* Skip page 0, aka HID_USAGE_PAGE_UNDEFINED */ > + for (i = 1; i < TOP_ABS_PAGE; i++) > + if (abs_pages[i][0] > 0) > + { > + int j; > + descript_size += sizeof(report_axis_usage) * abs_pages[i][0]; > + for (j = 1; j <= abs_pages[i][0]; j++) > + { > + ext->abs_map[abs_pages[i][j]].report_index = report_size; > + report_size+=2; > + } > + abs_count++; > + } > + > + rel_count = 0; > + memset(rel_pages, 0, sizeof(rel_pages)); > + for (i = 0; i < HID_REL_MAX; i++) > + if (test_bit(relbits, i)) > + { > + rel_pages[REL_to_HID_map[i][0]][0]++; > + rel_pages[REL_to_HID_map[i][0]][rel_pages[REL_to_HID_map[i][0]][0]] = i; > + if (rel_pages[REL_to_HID_map[i][0]][0] == 1) > + { > + descript_size += sizeof(report_axis_header); > + descript_size += sizeof(report_rel_axis_tail); > + } > + } > + /* Skip page 0, aka HID_USAGE_PAGE_UNDEFINED */ > + for (i = 1; i < TOP_REL_PAGE; i++) > + if (rel_pages[i][0] > 0) > + { > + int j; > + descript_size += sizeof(report_axis_usage) * rel_pages[i][0]; > + for (j = 1; j <= rel_pages[i][0]; j++) > + { > + ext->rel_map[rel_pages[i][j]] = report_size; > + report_size++; > + } > + rel_count++; > + } > + > + hat_count = 0; > + for (i = ABS_HAT0X; i <=ABS_HAT3X; i+=2) > + if (test_bit(absbits, i)) > + { > + ext->hat_map[i - ABS_HAT0X] = report_size; > + ext->hat_values[i - ABS_HAT0X] = 0; > + ext->hat_values[i - ABS_HAT0X + 1] = 0; > + report_size++; > + hat_count++; > + } > + > + TRACE("Report Descriptor will be %i bytes\n", descript_size); > + TRACE("Report will be %i bytes\n", report_size); > + > + ext->report_descriptor = HeapAlloc(GetProcessHeap(), 0, descript_size); > + report_ptr = ext->report_descriptor; > + > + memcpy(report_ptr, report_header, sizeof(report_header)); > + report_ptr[IDX_HEADER_PAGE] = device_usage[0]; > + report_ptr[IDX_HEADER_USAGE] = device_usage[1]; > + report_ptr += sizeof(report_header); > + if (button_count) > + { > + report_ptr = add_button_block(report_ptr, 1, button_count); > + if (button_count % 8) > + { > + BYTE padding = 8 - (button_count % 8); > + report_ptr = add_padding_block(report_ptr, padding); > + } > + } > + if (abs_count) > + { > + for (i = 1; i < TOP_ABS_PAGE; i++) > + { > + if (abs_pages[i][0]) > + { > + BYTE usages[HID_ABS_MAX]; > + int j; > + for (j = 0; j < abs_pages[i][0]; j++) > + usages[j] = ABS_to_HID_map[abs_pages[i][j+1]][1]; > + report_ptr = add_axis_block(report_ptr, abs_pages[i][0], i, usages, TRUE); > + } > + } > + } > + if (rel_count) > + { > + for (i = 1; i < TOP_REL_PAGE; i++) > + { > + if (rel_pages[i][0]) > + { > + BYTE usages[HID_REL_MAX]; > + int j; > + for (j = 0; j < rel_pages[i][0]; j++) > + usages[j] = REL_to_HID_map[rel_pages[i][j+1]][1]; > + report_ptr = add_axis_block(report_ptr, rel_pages[i][0], i, usages, FALSE); > + } > + } > + } > + if (hat_count) > + report_ptr = add_hatswitch(report_ptr, hat_count); > + > + memcpy(report_ptr, report_tail, sizeof(report_tail)); > + > + ext->report_descriptor_size = descript_size; > +} > +#endif > + > static inline WCHAR *strdupAtoW(const char *src) > { > WCHAR *dst; > @@ -406,9 +822,23 @@ static const platform_vtbl hidraw_vtbl = > > #ifdef HAS_PROPER_INPUT_HEADER > > +static inline struct wine_input_private *input_impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) > +{ > + return (struct wine_input_private*)get_platform_private(device); > +} > + > static NTSTATUS lnxev_get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length) > { > - return STATUS_NOT_IMPLEMENTED; > + struct wine_input_private *ext = input_impl_from_DEVICE_OBJECT(device); > + > + *out_length = ext->report_descriptor_size; > + > + if (length < ext->report_descriptor_size) > + return STATUS_BUFFER_TOO_SMALL; > + > + memcpy(buffer, ext->report_descriptor, ext->report_descriptor_size); > + > + return STATUS_SUCCESS; > } > > static NTSTATUS lnxev_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length) > @@ -511,7 +941,7 @@ static void try_add_device(struct udev_device *dev) > #ifdef HAS_PROPER_INPUT_HEADER > else if (strcmp(subsystem, "input") == 0) > { > - device = bus_create_hid_device(udev_driver_obj, lnxev_busidW, vid, pid, version, 0, serial, (gamepad != NULL), &GUID_DEVCLASS_LINUXEVENT, &lnxev_vtbl, sizeof(struct platform_private)); > + device = bus_create_hid_device(udev_driver_obj, lnxev_busidW, vid, pid, version, 0, serial, (gamepad != NULL), &GUID_DEVCLASS_LINUXEVENT, &lnxev_vtbl, sizeof(struct wine_input_private)); > } > #endif > > @@ -520,6 +950,9 @@ static void try_add_device(struct udev_device *dev) > struct platform_private *private = impl_from_DEVICE_OBJECT(device); > private->udev_device = udev_device_ref(dev); > private->device_fd = fd; > +#ifdef HAS_PROPER_INPUT_HEADER > + build_report_descriptor((struct wine_input_private*)private, dev); I don't think you want this code to be executed for hidraw devices. > +#endif > IoInvalidateDeviceRelations(device, BusRelations); > } > else > > >

1 0

Re: [PATCH v2 2/2] wined3d: Add quirk for Nvidia viewport subpixel bits bug.
by Sebastian Lackner 27 Feb '17

27 Feb '17

On 27.02.2017 13:42, Józef Kucia wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > > Version 2: Test if the pixel center offset works as expected. > > Tested with nouveau, radeonsi and Nvidia blob. > wined3d_caps_gl_ctx_test_viewport_subpixel_bits() fails only with Nvidia blob. As you might be aware, the problem on Nvidia binary can also be worked around by using slightly different offsets (basically reverting 1bed10abee7d2439a5c7358596c860c454f06b53). Do you think its better to disable it, or should we just use different pixel center offsets? > > --- > dlls/wined3d/directx.c | 27 ++++++++++++++++++++++++ > dlls/wined3d/utils.c | 47 ++++++++++++++++++++++++++++++++++++++++++ > dlls/wined3d/wined3d_private.h | 2 ++ > 3 files changed, 76 insertions(+) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 7f1a850..3495710 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -913,6 +913,17 @@ static BOOL match_broken_arb_fog(const struct wined3d_gl_info *gl_info, struct w > return data[0] != 0x00ff0000 || data[3] != 0x0000ff00; > } > > +static BOOL match_broken_viewport_subpixel_bits(const struct wined3d_gl_info *gl_info, > + struct wined3d_caps_gl_ctx *ctx, const char *gl_renderer, enum wined3d_gl_vendor gl_vendor, > + enum wined3d_pci_vendor card_vendor, enum wined3d_pci_device device) > +{ > + if (!gl_info->supported[ARB_VIEWPORT_ARRAY]) > + return FALSE; > + if (wined3d_settings.offscreen_rendering_mode != ORM_FBO) > + return FALSE; > + return !wined3d_caps_gl_ctx_test_viewport_subpixel_bits(ctx); > +} > + > static void quirk_apple_glsl_constants(struct wined3d_gl_info *gl_info) > { > /* MacOS needs uniforms for relative addressing offsets. This can accumulate to quite a few uniforms. > @@ -1041,6 +1052,17 @@ static void quirk_broken_arb_fog(struct wined3d_gl_info *gl_info) > gl_info->quirks |= WINED3D_QUIRK_BROKEN_ARB_FOG; > } > > +static void quirk_broken_viewport_subpixel_bits(struct wined3d_gl_info *gl_info) > +{ > + TRACE("Disabling ARB_viewport_array.\n"); > + gl_info->supported[ARB_VIEWPORT_ARRAY] = FALSE; > + if (gl_info->supported[ARB_CLIP_CONTROL]) > + { > + TRACE("Disabling ARB_clip_control.\n"); > + gl_info->supported[ARB_CLIP_CONTROL] = FALSE; > + } > +} > + > struct driver_quirk > { > BOOL (*match)(const struct wined3d_gl_info *gl_info, struct wined3d_caps_gl_ctx *ctx, > @@ -1132,6 +1154,11 @@ static const struct driver_quirk quirk_table[] = > quirk_broken_arb_fog, > "ARBfp fogstart == fogend workaround" > }, > + { > + match_broken_viewport_subpixel_bits, > + quirk_broken_viewport_subpixel_bits, > + "Nvidia viewport subpixel bits bug" > + }, > }; > > /* Certain applications (Steam) complain if we report an outdated driver version. In general, > diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c > index b076783..c392388 100644 > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -3509,6 +3509,53 @@ fail: > return FALSE; > } > > +BOOL wined3d_caps_gl_ctx_test_viewport_subpixel_bits(struct wined3d_caps_gl_ctx *ctx) > +{ > + static const struct wined3d_color red = {1.0f, 0.0f, 0.0f, 1.0f}; > + const struct wined3d_gl_info *gl_info = ctx->gl_info; > + static const float offset = -63.0f / 128.0f; > + GLuint texture, fbo; > + DWORD readback[4]; > + unsigned int i; > + > + gl_info->gl_ops.gl.p_glGenTextures(1, &texture); > + gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_2D, texture); > + gl_info->gl_ops.gl.p_glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0); > + gl_info->gl_ops.gl.p_glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, ARRAY_SIZE(readback), 1, 0, > + GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, NULL); > + gl_info->fbo_ops.glGenFramebuffers(1, &fbo); > + gl_info->fbo_ops.glBindFramebuffer(GL_FRAMEBUFFER, fbo); > + gl_info->fbo_ops.glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, > + GL_TEXTURE_2D, texture, 0); > + checkGLcall("create resources"); > + > + gl_info->gl_ops.gl.p_glClearColor(1.0f, 1.0f, 1.0f, 1.0f); > + gl_info->gl_ops.gl.p_glClear(GL_COLOR_BUFFER_BIT); > + GL_EXTCALL(glViewportIndexedf(0, offset, offset, 4.0f, 1.0f)); > + draw_test_quad(ctx, NULL, &red); > + checkGLcall("draw"); > + > + gl_info->gl_ops.gl.p_glBindTexture(GL_TEXTURE_2D, texture); > + gl_info->gl_ops.gl.p_glGetTexImage(GL_TEXTURE_2D, 0, > + GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, readback); > + checkGLcall("readback"); > + > + TRACE("Readback colors are 0x%08x, 0x%08x, 0x%08x, 0x%08x.\n", > + readback[0], readback[1], readback[2], readback[3]); > + > + gl_info->gl_ops.gl.p_glDeleteTextures(1, &texture); > + gl_info->fbo_ops.glDeleteFramebuffers(1, &fbo); > + gl_info->fbo_ops.glBindFramebuffer(GL_FRAMEBUFFER, 0); > + checkGLcall("delete resources"); > + > + for (i = 0; i < ARRAY_SIZE(readback); ++i) > + { > + if (readback[i] != 0xffff0000) > + return FALSE; > + } > + return TRUE; > +} > + > float wined3d_adapter_find_polyoffset_scale(struct wined3d_caps_gl_ctx *ctx, GLenum format) > { > const struct wined3d_gl_info *gl_info = ctx->gl_info; > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 7950011..3cd7ae5 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2354,6 +2354,8 @@ BOOL wined3d_adapter_init_format_info(struct wined3d_adapter *adapter, > struct wined3d_caps_gl_ctx *ctx) DECLSPEC_HIDDEN; > UINT64 adapter_adjust_memory(struct wined3d_adapter *adapter, INT64 amount) DECLSPEC_HIDDEN; > > +BOOL wined3d_caps_gl_ctx_test_viewport_subpixel_bits(struct wined3d_caps_gl_ctx *ctx) DECLSPEC_HIDDEN; > + > void install_gl_compat_wrapper(struct wined3d_gl_info *gl_info, enum wined3d_gl_extension ext) DECLSPEC_HIDDEN; > > enum projection_types >

2 3

Re: winmm: Fix some spec file entries
by Andrew Eikum 27 Feb '17

27 Feb '17

On Wed, Feb 22, 2017 at 11:23:08PM +0100, André Hentschel wrote: > -@ stdcall PlaySound(ptr long long) PlaySoundA > -@ stdcall PlaySoundA(ptr long long) > -@ stdcall PlaySoundW(ptr long long) > +@ stdcall PlaySound(str long long) PlaySoundA > +@ stdcall PlaySoundA(str long long) > +@ stdcall PlaySoundW(wstr long long) The first parameter is not always a string, sometimes it's a resource identifier or even a raw pointer: https://msdn.microsoft.com/en-us/library/windows/desktop/dd743679(v=vs.85).… Andrew

1 0

Re: [PATCH] oledb32: Correct length calculation in DataConvert for DBTYPE_STR
by Huw Davies 27 Feb '17

27 Feb '17

On Fri, Feb 24, 2017 at 06:45:16AM +0000, Alistair Leslie-Hughes wrote: > v2 - Correct failing test under wine > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/convert.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index ac462f2..20ef917 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -816,23 +816,23 @@ static HRESULT WINAPI convert_DataConvert(IDataConvert* iface, > case DBTYPE_STR: > { > BSTR b; > - DBLENGTH bstr_len; > + DBLENGTH length; > INT bytes_to_copy; > - hr = IDataConvert_DataConvert(iface, src_type, DBTYPE_BSTR, src_len, &bstr_len, > + hr = IDataConvert_DataConvert(iface, src_type, DBTYPE_BSTR, src_len, &length, > src, &b, sizeof(BSTR), src_status, dst_status, > precision, scale, flags); > if(hr != S_OK) return hr; > - bstr_len = SysStringLen(b); > - *dst_len = bstr_len * sizeof(char); /* Doesn't include size for '\0' */ > + length = WideCharToMultiByte(CP_ACP, 0, b, -1, NULL, 0, NULL, NULL); > + *dst_len = SysStringLen(b); /* Doesn't include size for '\0' */ This obviously can't be right. As I said, you want to pass SysStringLen(b) as the wstr_len to WideCharToMultiByte(). Then whatever that returns will be the length of the ansi string excluding the '\0'. That should go into *dst_len. > *dst_status = DBSTATUS_S_OK; > - bytes_to_copy = min(*dst_len + sizeof(char), dst_max_len); > + bytes_to_copy = min(length, dst_max_len); bytes_to_copy should be min(length + 1, dst_max_len), so unchanged, but let's get rid of sizeof(char). > if(dst) > { > if(bytes_to_copy >= sizeof(char)) > { > - WideCharToMultiByte(CP_ACP, 0, b, bytes_to_copy - sizeof(char), dst, dst_max_len, NULL, NULL); > + WideCharToMultiByte(CP_ACP, 0, b, -1, dst, dst_max_len, NULL, NULL); Again SysStringLen(b) here for the wstr_len. > *((char *)dst + bytes_to_copy / sizeof(char) - 1) = 0; This is correct, but again let's get rid of the sizeof(char). > - if(bytes_to_copy < *dst_len + sizeof(char)) > + if(bytes_to_copy < length) should be length + 1. You probably want to add a test for a STR -> STR conversion of "test\0ed" and pass in interesting src lengths like 6, 7 and 8, then check the returned dst (using memcmp, not strcmp). Huw.

1 0

Re: iphlpapi/tests: Don't skip because of an obsolete function
by Nikolay Sivov 27 Feb '17

27 Feb '17

On 27.02.2017 16:05, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/iphlpapi/tests/iphlpapi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/iphlpapi/tests/iphlpapi.c b/dlls/iphlpapi/tests/iphlpapi.c > index 953bbc9..ddea4f8 100644 > --- a/dlls/iphlpapi/tests/iphlpapi.c > +++ b/dlls/iphlpapi/tests/iphlpapi.c > @@ -1583,7 +1583,7 @@ static void test_AllocateAndGetTcpExTableFromStack(void) > > if (!pAllocateAndGetTcpExTableFromStack) > { > - skip("AllocateAndGetTcpExTableFromStack not available\n"); > + trace("AllocateAndGetTcpExTableFromStack not available, skipping\n"); > return; > } > > What's a point of this change?

1 0

Re: ntdll: Fix RtlExpandEnvironmentStrings_U spec file entry (try 2)
by Alexandre Julliard 27 Feb '17

27 Feb '17

André Hentschel <nerv(a)dawncrow.de> writes: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/ntdll/ntdll.spec | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index 66618fc..7d7c34b 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -589,7 +589,7 @@ > @ stdcall RtlEraseUnicodeString(ptr) > @ stdcall RtlExitUserProcess(long) > @ stdcall RtlExitUserThread(long) > -@ stdcall RtlExpandEnvironmentStrings_U(ptr ptr ptr ptr) > +@ stdcall RtlExpandEnvironmentStrings_U(wstr ptr ptr ptr) That's not a string either. -- Alexandre Julliard julliard(a)winehq.org

1 0

Coverity reports for test suite
by Alex Henrie 27 Feb '17

27 Feb '17

Hello, I recently noticed that we don't currently get Coverity reports for files in the test suite. I emailed Amine Khaldi, who does the Coverity reports, and asked if we could start getting reports on the tests. Amine made it sound like this had been discussed before and due to the large volume of reports, there was not interest in getting reports for anything other than the actual Wine code. Is there enough interest now to start looking at the test suite reports? Would it hurt anything to be able to see that information? -Alex

6 10

Re: [PATCH] wined3d: Add quirk for Nvidia viewport subpixel bits bug.
by Henri Verbeet 27 Feb '17

27 Feb '17

On 26 February 2017 at 19:55, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static BOOL match_nvidia_viewport_subpixel_bits(const struct wined3d_gl_info *gl_info, const char *gl_renderer, > + enum wined3d_gl_vendor gl_vendor, enum wined3d_pci_vendor card_vendor, enum wined3d_pci_device device) > +{ > + return gl_vendor == GL_VENDOR_NVIDIA && gl_info->supported[ARB_VIEWPORT_ARRAY]; > +} If reasonably possible, we'd like to avoid matching on gl_vendor and the like. It's not the most reliable information we have, and would prevent the feature from working in the future if the driver is ever fixed. I'll grant the chances aren't great on the latter, but out of principle, it should be possible to test if the feature itself is working.

1 0

Re: iphlpapi/tests: Fix test failure for ScopeID with bad DAD
by Bruno Jesus 27 Feb '17

27 Feb '17

On Wed, Feb 22, 2017 at 5:01 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > diff --git a/dlls/iphlpapi/tests/iphlpapi.c b/dlls/iphlpapi/tests/iphlpapi.c > index e0701a3..2f818ff 100644 > --- a/dlls/iphlpapi/tests/iphlpapi.c > +++ b/dlls/iphlpapi/tests/iphlpapi.c > @@ -2067,6 +2067,9 @@ static void test_GetUnicastIpAddressEntry(void) > if (row.Address.si_family == AF_INET6) > ok(row.ScopeId.Value == row.Address.Ipv6.sin6_scope_id, "Expected %d, got %d\n", > row.Address.Ipv6.sin6_scope_id, row.ScopeId.Value); > + else if (row.DadState == IpDadStateTentative) > + ok(row.ScopeId.Value == aa->IfIndex, "Expected %d, got %d\n", > + aa->IfIndex, row.ScopeId.Value); > else > ok(row.ScopeId.Value == 0, "Expected 0, got %d\n", row.ScopeId.Value); > ok(row.CreationTimeStamp.QuadPart, "CreationTimeStamp is 0\n"); It may be bikeshedding but 2 things call my attention. The first is that ScopeID is a IPv6 only field, it is very weird that Windows is using it for something. The second is that it may be by chance that ScopeID matches the interface index, tentative means that the DAD mechanism is still working into checking the IP in the network, so ScopeID in such case would be meaningless until it turns into IpDadStatePreferred or maybe one of the other error states.

2 2

Proposal: winetest 'context'
by Mark Jansen 26 Feb '17

26 Feb '17

Hello, Often when testing something, helper functions are introduced that are called with different data (for example when iterating over tables). Attached patch (winetest_set_context.diff) is a proposal that allows tests to specify a 'context', that will be printed in the failure message. This way, the actual test code does not have to prefix every case with a trace, or include the data in every test macro. The patch is written so that tests do not have to use this mechanism, so there is no need to convert all tests at once. Second attachment (winetest_ctx_example.diff) shows how an existing test could be converted to use this new technique. Regards, Mark Jansen

3 2

Re: [PATCH] rasapi32: Ensure device count matches data returned
by Sebastian Lackner 26 Feb '17

26 Feb '17

On 26.02.2017 20:41, Bruno Jesus wrote: > From: Bruno Jesus <bjesus(a)codeweavers.com> > > Based on original patch by Qian Hong. > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=30378 > > Signed-off-by: Bruno Jesus <bjesus(a)codeweavers.com> > --- > dlls/rasapi32/rasapi.c | 1 + > dlls/rasapi32/tests/rasapi.c | 24 ++++++++++++++++++++++++ > 2 files changed, 25 insertions(+) > > diff --git a/dlls/rasapi32/rasapi.c b/dlls/rasapi32/rasapi.c > index fcd0cb8..f97d4c1 100644 > --- a/dlls/rasapi32/rasapi.c > +++ b/dlls/rasapi32/rasapi.c > @@ -254,6 +254,7 @@ DWORD WINAPI RasEnumDevicesA(LPRASDEVINFOA lpRasDevinfo, LPDWORD lpcb, LPDWORD l > if(lpRasDevinfo && lpRasDevinfo->dwSize != sizeof(RASDEVINFOA)) > return ERROR_INVALID_SIZE; > > + *lpcDevices = 1; > if (!lpRasDevinfo || (*lpcb < sizeof(RASDEVINFOA))) { > *lpcb = sizeof(RASDEVINFOA); > return ERROR_BUFFER_TOO_SMALL; > diff --git a/dlls/rasapi32/tests/rasapi.c b/dlls/rasapi32/tests/rasapi.c > index e0ff25f..e982f6c 100644 > --- a/dlls/rasapi32/tests/rasapi.c > +++ b/dlls/rasapi32/tests/rasapi.c > @@ -77,80 +77,104 @@ static void test_rasenum(void) > > /* test first parameter */ > cb = bufsize; > + cDevices = 0xdead; > result = pRasEnumDevicesA(NULL, &cb, &cDevices); > ok(result == ERROR_BUFFER_TOO_SMALL || > result == ERROR_INVALID_USER_BUFFER, /* win98 */ > "Expected ERROR_BUFFER_TOO_SMALL, got %08d\n", result); > + ok(cDevices > 0 && cDevices != 0xdead, "Unexpected device count %d\n", cDevices); > > rasDevInfo[0].dwSize = 0; > cb = bufsize; > + cDevices = 0xdead; > result = pRasEnumDevicesA(rasDevInfo, &cb, &cDevices); > ok(result == ERROR_INVALID_SIZE || > result == ERROR_INVALID_USER_BUFFER, /* win98 */ > "Expected ERROR_INVALID_SIZE, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > rasDevInfo[0].dwSize = sizeof(RASDEVINFOA) -1; > cb = bufsize; > + cDevices = 0xdead; > result = pRasEnumDevicesA(rasDevInfo, &cb, &cDevices); > ok(result == ERROR_INVALID_SIZE || > result == ERROR_INVALID_USER_BUFFER, /* win98 */ > "Expected ERROR_INVALID_SIZE, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > rasDevInfo[0].dwSize = sizeof(RASDEVINFOA) +1; > cb = bufsize; > + cDevices = 0xdead; > result = pRasEnumDevicesA(rasDevInfo, &cb, &cDevices); > ok(result == ERROR_INVALID_SIZE || > result == ERROR_INVALID_USER_BUFFER, /* win98 */ > "Expected ERROR_INVALID_SIZE, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > /* test second parameter */ > rasDevInfo[0].dwSize = sizeof(RASDEVINFOA); > result = pRasEnumDevicesA(rasDevInfo, NULL, &cDevices); > + cDevices = 0xdead; Whats the point to set this after the function call? And also, how is this better than Qian Hongs original patch? Using %u is more correct for unsigned values, and the empty line after the assignment of *lpcDevices also didn't hurt. > ok(result == ERROR_INVALID_PARAMETER, > "Expected ERROR_INVALID_PARAMETER, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > rasDevInfo[0].dwSize = sizeof(RASDEVINFOA); > cb = 0; > result = pRasEnumDevicesA(rasDevInfo, &cb, &cDevices); > + cDevices = 0xdead; > ok(result == ERROR_BUFFER_TOO_SMALL || > result == ERROR_INVALID_SIZE, /* vista, 2k8 */ > "Expected ERROR_BUFFER_TOO_SMALL/ERROR_INVALID_SIZE, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > rasDevInfo[0].dwSize = sizeof(RASDEVINFOA); > cb = bufsize -1; > result = pRasEnumDevicesA(rasDevInfo, &cb, &cDevices); > + cDevices = 0xdead; > ok(result == ERROR_BUFFER_TOO_SMALL, > "Expected ERROR_BUFFER_TOO_SMALL, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > rasDevInfo[0].dwSize = sizeof(RASDEVINFOA); > cb = bufsize +1; > + cDevices = 0xdead; > result = pRasEnumDevicesA(rasDevInfo, &cb, &cDevices); > ok(result == ERROR_SUCCESS, > "Expected ERROR_SUCCESS, got %08d\n", result); > + ok(cDevices > 0 && cDevices != 0xdead, "Unexpected device count %d\n", cDevices); > > /* test third parameter */ > rasDevInfo[0].dwSize = sizeof(RASDEVINFOA); > cb = bufsize; > + cDevices = 0xdead; > result = pRasEnumDevicesA(rasDevInfo, &cb, NULL); > ok(result == ERROR_INVALID_PARAMETER, > "Expected ERROR_INVALID_PARAMETER, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > /* test combinations of invalid parameters */ > + cDevices = 0xdead; > result = pRasEnumDevicesA(NULL, NULL, &cDevices); > ok(result == ERROR_INVALID_PARAMETER, > "Expected ERROR_INVALID_PARAMETER, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > + cDevices = 0xdead; > result = pRasEnumDevicesA(NULL, &cb, NULL); > ok(result == ERROR_INVALID_PARAMETER || > result == ERROR_INVALID_USER_BUFFER, /* win98 */ > "Expected ERROR_INVALID_PARAMETER, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > cb = 0; > rasDevInfo[0].dwSize = 0; > + cDevices = 0xdead; > result = pRasEnumDevicesA(rasDevInfo, &cb, &cDevices); > ok(result == ERROR_INVALID_SIZE || > broken(result == ERROR_BUFFER_TOO_SMALL), /* win98 */ > "Expected ERROR_INVALID_SIZE, got %08d\n", result); > + ok(cDevices == 0xdead, "Unexpected device count %d\n", cDevices); > > HeapFree(GetProcessHeap(), 0, rasDevInfo); > } > -- 2.9.3 >

2 1

Re: include: Avoid overflow (warning) in RGBA_MAKE.
by Dmitry Timoshkov 26 Feb '17

26 Feb '17

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > --- a/include/d3dtypes.h > +++ b/include/d3dtypes.h > @@ -53,7 +53,7 @@ typedef LONG D3DFIXED; > #define RGBA_GETRED(rgb) (((rgb) >> 16) & 0xff) > #define RGBA_GETGREEN(rgb) (((rgb) >> 8) & 0xff) > #define RGBA_GETBLUE(rgb) ((rgb) & 0xff) > -#define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((a) << 24) | ((r) << 16) | ((g) << 8) | (b))) > +#define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((unsigned)(a) << 24) | ((r) << 16) | ((g) << 8) | (b))) This is a public header, probably you need to fix the callers of this macro instead. -- Dmitry.

3 4

Re: [PATCH 03/18] comctl32: Added basic implementation for task dialogs and add tests
by Fabian Maurer 26 Feb '17

26 Feb '17

Thanks for the reply, > If this will stay, please use functions, not macros. STR_SIZE does not > look useful. Well, I figured it makes the code a bit easier. Should I should just write it out everywhere or make it a function? > Usually there's no need to allocate 'struct list' itself. You're right, I'll rewrite that. > You can't free list node like that. What do you mean? I allocated the list and it's contents with HeapAlloc, so I need to free it that way. Or am I missing something? > This one is already defined in a header. Thanks, I'll use the headers instead of adding another define for that. > Static string for that doesn't look right. Why is that? I've looked into the other code, and strings are often defined as static const WCHAR, that was the recommended method, too. Of course that needs to be changed later, since we (probably) want to take localization into account. Regards, Fabian Maurer

3 4

Re: [PATCH 04/18] comctl32: Extend TaskDialog, add simple callback and tests
by Nikolay Sivov 26 Feb '17

26 Feb '17

On 25.02.2017 19:01, Fabian Maurer wrote: > +/* FIXME: Make thread safe? */ > +static const TASKDIALOGCONFIG *task_config = 0; > +static HRESULT callback(HWND hwnd, UINT uNotification, WPARAM wParam, LPARAM lParam) > +{ > + if(task_config->pfCallback) > + return task_config->pfCallback(hwnd, uNotification, wParam, lParam, task_config->lpCallbackData); > + return S_OK; > +} > + > static INT_PTR CALLBACK DialogProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam) > { > + HRESULT ret_callback; > + > switch (uMsg) > { > + case WM_INITDIALOG: > + callback(hwndDlg, TDN_DIALOG_CONSTRUCTED, 0, 0); > + callback(hwndDlg, TDN_CREATED, 0, 0); > + return TRUE; How is this going to work with global variable? > +/* For message checking we use a simplified version from the code used for user32 messages */ > + > +#define TDN_NO_MORE_MESSAGES 0xffffffff > + > +typedef struct > +{ > + UINT msg; > + WPARAM wparam; > + LPARAM lparam; > + > + struct list entry; > +}message_data; > + > +static struct list messages = LIST_INIT(messages); > + > +/* Message lists to test against */ > + > +static const message_data mes_simple_show[] = { > + { TDN_DIALOG_CONSTRUCTED, 0, 0 }, > + { TDN_CREATED, 0, 0 }, > + { TDN_BUTTON_CLICKED, IDOK, 0 }, > + { TDN_DESTROYED, 0, 0 }, > + { TDN_NO_MORE_MESSAGES } > +}; > + > +/* Functions handling message processing */ > + > +static void message_add(UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + message_data *data = HeapAlloc(GetProcessHeap(), 0, sizeof(message_data)); > + > + data->msg = msg; > + data->wparam = wparam; > + data->lparam = lparam; > + > + list_add_tail(&messages, &data->entry); > +} > + > +#define ok_sequence(exp ) \ > + ok_sequence_((exp), __FILE__, __LINE__) > + > +static void ok_sequence_(const message_data *expected_list, const char *file, int line) > +{ > + message_data *message; > + BOOL dump = FALSE; > + UINT count; > + For that please use msg.h from comctl32/tests.

2 3

Re: [PATCH 06/18] comctl32: TaskDialog - Implement main and content text controls
by Nikolay Sivov 26 Feb '17

26 Feb '17

On 25.02.2017 19:01, Fabian Maurer wrote: > + PostMessageW(GetDlgItem(hwndDlg, ID_TEXTMAIN), WM_SETFONT, (WPARAM)font_main, TRUE); > + PostMessageW(GetDlgItem(hwndDlg, ID_TEXTCONTENT), WM_SETFONT, (WPARAM)font_default, TRUE); Why Post*? Dialog handling in user32 has an ability to do this for you. > + case WM_CTLCOLORSTATIC: > + if((HWND)lParam == GetDlgItem(hwndDlg, ID_TEXTMAIN)) > + { > + HDC hdc = (HDC) wParam; > + > + SetTextColor(hdc, RGB(50,50,220)); > + SetBkColor(hdc, GetSysColor(COLOR_3DFACE)); > + > + return (INT_PTR)GetSysColorBrush(COLOR_3DFACE); > + } > + break; Where does this come from? > + font_default = CreateFontW (16, 0, 0, 0, FW_DONTCARE, FALSE, FALSE, FALSE, > + DEFAULT_CHARSET, 0, 0, CLEARTYPE_QUALITY, FF_DONTCARE, font_name); > + font_main = CreateFontW (19, 0, 0, 0, FW_DONTCARE, FALSE, FALSE, FALSE, > + DEFAULT_CHARSET, 0, 0, CLEARTYPE_QUALITY, FF_DONTCARE, font_name); > + Why Tahoma is hardcoded? If you're using dialog code this should be handled automatically using template data. > + if(!IS_INTRESOURCE(pTaskConfig->pszMainInstruction) && !STR_EMPTY(pTaskConfig->pszMainInstruction)) > + { > + RECT rect; > + > + SelectObject(dc_dummy, font_main); > + rect = text_get_rect(dc_dummy, pTaskConfig->pszMainInstruction, dialog_width); > + > + controls_add(controls, ID_TEXTMAIN, class_static, pTaskConfig->pszMainInstruction, > + WS_CHILD | WS_VISIBLE, 5, dialog_height + 5, rect.right, rect.bottom); > + > + dialog_height += rect.bottom + 10; > + SelectObject(dc_dummy, font_default); > + } > + > + if(!IS_INTRESOURCE(pTaskConfig->pszContent) && !STR_EMPTY(pTaskConfig->pszContent)) > + { > + RECT rect = text_get_rect(dc_dummy, pTaskConfig->pszContent, dialog_width); > + > + controls_add(controls, ID_TEXTCONTENT, class_static, pTaskConfig->pszContent, > + WS_CHILD | WS_VISIBLE, 5, dialog_height + 5, rect.right, rect.bottom); > + > + dialog_height += rect.bottom + 10; > + } > + > + controls_add(controls, IDOK, class_button, text_ok, > + WS_CHILD | WS_VISIBLE | BS_DEFPUSHBUTTON, dialog_width - 40 - 10, dialog_height + 5, 40, 10); > + dialog_height += 10 + 10; There's a lot of magic offsets here that should be grouped together and probably have some defined names too.

2 3

Re: [PATCH v2 4/6] ddraw: Keep a ddraw object reference in d3d7 vertex buffers.
by Henri Verbeet 26 Feb '17

26 Feb '17

On 24 February 2017 at 19:37, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -4257,6 +4257,7 @@ static HRESULT WINAPI d3d7_CreateVertexBuffer(IDirect3D7 *iface, D3DVERTEXBUFFER > { > TRACE("Created vertex buffer %p.\n", object); > *vertex_buffer = &object->IDirect3DVertexBuffer7_iface; > + IDirectDraw7_AddRef(&ddraw->IDirectDraw7_iface); > } It seems more appropriate to do this in d3d_vertex_buffer_create() when storing the ddraw pointer.

1 0

Re: [PATCH 14/18] comctl32: TaskDialog - Changed tests to make them more reliable
by Marvin 25 Feb '17

25 Feb '17

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=28901 Your paranoid android. === w7pro64 (64 bit taskdialog) === 0824:taskdialog: unhandled exception c0000005 at 00000000004620FE

2 1

Re: [09/18] comctl32: TaskDialog - make thread-safe
by Nikolay Sivov 25 Feb '17

25 Feb '17

On 24.02.2017 23:04, Fabian Maurer wrote: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/comctl32/taskdialog.c | 137 ++++++++++++++++++++++++++++++++++----------- > 1 file changed, 105 insertions(+), 32 deletions(-) > > diff --git a/dlls/comctl32/taskdialog.c b/dlls/comctl32/taskdialog.c > index 3d6b99000c..63848303f5 100644 > --- a/dlls/comctl32/taskdialog.c > +++ b/dlls/comctl32/taskdialog.c > @@ -69,6 +69,26 @@ typedef struct > UINT y; > }button_info; > > +typedef struct > +{ > + struct list entry; > + const TASKDIALOGCONFIG *task_config; > + HFONT font_default; > + HFONT font_main; > + HWND hwnd; > +}taskdialog_info; > + > +struct list taskdialogs = LIST_INIT(taskdialogs); > + > +static CRITICAL_SECTION taskdialog_section; > +static CRITICAL_SECTION_DEBUG taskdialog_section_debug = > +{ > + 0, 0, &taskdialog_section, > + { &taskdialog_section_debug.ProcessLocksList, &taskdialog_section_debug.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": taskdialog_section") } > +}; > +static CRITICAL_SECTION taskdialog_section = { &taskdialog_section_debug, -1, 0, 0, 0, 0 }; > + Why would you need something like that? What is unsafe about regular dialog window?

2 5

Re: [PATCH 18/18] comctl32: TaskDialog - Add ability to cancel dialog
by Marvin 25 Feb '17

25 Feb '17

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=28906 Your paranoid android. === w8 (32 bit taskdialog) === 02f0:taskdialog: unhandled exception c0000005 at 00472B00 === w7pro64 (64 bit taskdialog) === 0828:taskdialog: unhandled exception c0000005 at 000000000046211E === w864 (64 bit taskdialog) === 0fb0:taskdialog: unhandled exception c0000005 at 000000000046211E

1 0

Re: [PATCH 17/18] comctl32: TaskDialog - Implement TDM_HELP and add tests
by Marvin 25 Feb '17

25 Feb '17

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=28905 Your paranoid android. === w7pro64 (64 bit taskdialog) === 0270:taskdialog: unhandled exception c0000005 at 000000000046211E === w864 (64 bit taskdialog) === 0f88:taskdialog: unhandled exception c0000005 at 00007FFB25902CE1 === w1064 (64 bit taskdialog) === 0f6c:taskdialog: unhandled exception c0000005 at 000000000046211E

1 0

Re: [PATCH 16/18] comctl32: Taskdialog - Implement TDM_ENABLE_BUTTON and add tests
by Marvin 25 Feb '17

25 Feb '17

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=28904 Your paranoid android. === w1064 (32 bit taskdialog) === 108c:taskdialog: unhandled exception c0000005 at 00472B00 === w7pro64 (64 bit taskdialog) === 0274:taskdialog: unhandled exception c0000005 at 000000000046211E === w864 (64 bit taskdialog) === 0f50:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 0ac8:taskdialog: unhandled exception c0000005 at 000000000046211E

1 0

Re: [PATCH 15/18] comctl32: TaskDialog - Set default button and add tests
by Marvin 25 Feb '17

25 Feb '17

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=28902 Your paranoid android. === w7pro64 (64 bit taskdialog) === 0828:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 0e28:taskdialog: unhandled exception c0000005 at 000000000046211E

1 0

Re: [06/18] comctl32: TaskDialog - Implement main and content text controls
by Joachim Priesner 24 Feb '17

24 Feb '17

Glad to see that someone is finally implementing this properly :) > @@ -276,7 +324,33 @@ HRESULT WINAPI TaskDialogIndirect(const TASKDIALOGCONFIG *pTaskConfig, int *pnBu > > /* Start creating controls */ > > - controls_add(controls, IDOK, class_button, text_ok, WS_CHILD | WS_VISIBLE, 105, 85, 40, 10); > + if(!STR_EMPTY(pTaskConfig->pszMainInstruction)) > + { > + RECT rect; > + > + SelectObject(dc_dummy, font_main); > + rect = text_get_rect(dc_dummy, pTaskConfig->pszMainInstruction, dialog_width); > + > + controls_add(controls, ID_TEXTMAIN, class_static, pTaskConfig->pszMainInstruction, > + WS_CHILD | WS_VISIBLE, 5, dialog_height + 5, rect.right, rect.bottom); The psz* parameters (e.g. pszMainInstruction) can contain a resource ID instead of a string. (Passing an invalid ID just results in an empty string.) Right now passing something that is not a string crashes the dialog, which probably should not happen. To get the string if a resource ID has been passed you can use something like +/* Fills "result" with a pointer to the string specified by "text", which may be a resource identifier. */ +static HRESULT TASKDIALOG_GetText(const WCHAR *text, HINSTANCE instance, const WCHAR **result) +{ + if (IS_INTRESOURCE(text)) + { + SetLastError(S_OK); + LoadStringW(instance, LOWORD(text), (LPWSTR)result, 0); + return HRESULT_FROM_WIN32(GetLastError()); + } + else + { + *result = text; + return S_OK; + } +}

2 3

RE: wineinstall - Add support for parallel builds using 'nproc' to detect cpu count
by wylda＠volny.cz 24 Feb '17

24 Feb '17

Hi, i like/use "make -j 1" for log comparison. Can you leave NPROC=1 or allow override? W.

5 12

Re: [18/18] comctl32: TaskDialog - Add ability to cancel dialog
by Marvin 24 Feb '17

24 Feb '17

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=28889 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:631: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:631: Test failed: TaskDialogIndirect not exported by name. === w7pro64 (64 bit taskdialog) === 0718:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 0b44:taskdialog: unhandled exception c0000005 at 000000000046211E

1 0

Re: [17/18] comctl32: TaskDialog - Implement TDM_HELP and add tests
by Marvin 24 Feb '17

24 Feb '17

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=28888 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:550: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:550: Test failed: TaskDialogIndirect not exported by name. === w7pro64 (64 bit taskdialog) === 06fc:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 0e6c:taskdialog: unhandled exception c0000005 at 000000000046211E

1 0

Re: [16/18] comctl32: Taskdialog - Implement TDM_ENABLE_BUTTON and add tests
by Marvin 24 Feb '17

24 Feb '17

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=28887 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:531: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:531: Test failed: TaskDialogIndirect not exported by name. === w7pro64 (64 bit taskdialog) === 0438:taskdialog: unhandled exception c0000005 at 000000000046211E === w864 (64 bit taskdialog) === 0f54:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 0e44:taskdialog: unhandled exception c0000005 at 000000000046211E

1 0

Re: [15/18] comctl32: TaskDialog - Set default button and add tests
by Marvin 24 Feb '17

24 Feb '17

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=28886 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:456: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:456: Test failed: TaskDialogIndirect not exported by name. === w7pro64 (64 bit taskdialog) === 0824:taskdialog: unhandled exception c0000005 at 000000000046211E === w1064 (64 bit taskdialog) === 074c:taskdialog: unhandled exception c0000005 at 000000000046211E

1 0

Re: [03/18] comctl32: Added basic implementation for task dialogs and add tests
by Nikolay Sivov 24 Feb '17

24 Feb '17

On 24.02.2017 23:03, Fabian Maurer wrote: > The dialog doesn't show text and can basically do nothing, > but it sets the foundation. > > +} > + > +/* Functions for turning our dialog structures into a usable dialog template > + * We don't load the dialog template from a resource, we instead create it in memory > + * This way we can easily handle variable control numbers */ I think this is an overkill. How about using static template and then destroying controls you don't need?

1 1

Re: [14/18] comctl32: TaskDialog - Changed tests to make them more reliable
by Marvin 24 Feb '17

24 Feb '17

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=28881 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:364: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:364: Test failed: TaskDialogIndirect not exported by name. === w7pro64 (64 bit taskdialog) === 0828:taskdialog: unhandled exception c0000005 at 00000000004620FE === w1064 (64 bit taskdialog) === 0fdc:taskdialog: unhandled exception c0000005 at 00000000004620FE

1 0

Re: [13/18] comctl32: TaskDialog - Flush evens before testing
by Marvin 24 Feb '17

24 Feb '17

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=28880 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:305: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:305: Test failed: TaskDialogIndirect not exported by name.

1 0

Re: [12/18] comctl32: TaskDialog - Simplified test structure
by Marvin 24 Feb '17

24 Feb '17

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=28879 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:287: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:287: Test failed: TaskDialogIndirect not exported by name.

1 0

Re: [11/18] comctl32: TaskDialog - Add button return value and tests
by Marvin 24 Feb '17

24 Feb '17

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=28878 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:270: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:270: Test failed: TaskDialogIndirect not exported by name.

1 0

Re: [10/18] comctl32: TaskDialog - Changed the way tests work, allow them to send messages
by Marvin 24 Feb '17

24 Feb '17

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=28877 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:237: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:237: Test failed: TaskDialogIndirect not exported by name. === wvistau64 (32 bit taskdialog) === 0bb4:taskdialog: unhandled exception c0000005 at 0047267B === w2008s64 (32 bit taskdialog) === 0b30:taskdialog: unhandled exception c0000005 at 0047267B === w7u (32 bit taskdialog) === 049c:taskdialog: unhandled exception c0000005 at 0047267B === w7pro64 (32 bit taskdialog) === 0894:taskdialog: unhandled exception c0000005 at 0047267B === w8 (32 bit taskdialog) === 0194:taskdialog: unhandled exception c0000005 at 0047267B === w864 (32 bit taskdialog) === 03e8:taskdialog: unhandled exception c0000005 at 0047267B === w1064 (32 bit taskdialog) === 0db4:taskdialog: unhandled exception c0000005 at 0047267B === wvistau64 (64 bit taskdialog) === 0808:taskdialog: unhandled exception c0000005 at 0000000000461CE9 === w2008s64 (64 bit taskdialog) === 0b30:taskdialog: unhandled exception c0000005 at 0000000000461CE9 === w7pro64 (64 bit taskdialog) === 071c:taskdialog: unhandled exception c0000005 at 0000000000461CE9 === w864 (64 bit taskdialog) === 0f94:taskdialog: unhandled exception c0000005 at 0000000000461CE9 === w1064 (64 bit taskdialog) === 0318:taskdialog: unhandled exception c0000005 at 0000000000461CE9

1 0

Re: [04/18] comctl32: Extend TaskDialog, add simple callback and tests
by Marvin 24 Feb '17

24 Feb '17

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=28876 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:178: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:178: Test failed: TaskDialogIndirect not exported by name.

1 0

Re: [03/18] comctl32: Added basic implementation for task dialogs and add tests
by Marvin 24 Feb '17

24 Feb '17

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=28875 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:80: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:80: Test failed: TaskDialogIndirect not exported by name.

1 0

Re: [01/18] comctl32: Move TaskDialogIndirect and tests into own source files
by Marvin 24 Feb '17

24 Feb '17

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=28874 Your paranoid android. === wxppro (32 bit taskdialog) === taskdialog.c:46: Test failed: TaskDialogIndirect not exported by name. === w2003std (32 bit taskdialog) === taskdialog.c:46: Test failed: TaskDialogIndirect not exported by name.

1 0

[PATCH v4 00/17] x86: Enable User-Mode Instruction Prevention
by Ricardo Neri 24 Feb '17

24 Feb '17

This is v4 of this series. Again, it took me a while to complete the updates as support for 16-bit address encodings for protected mode required extra rework. The two previous submissions can be found here [1], here [2] and here [3]. === 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[4]. For instance, these applications rely on sidt returning a non- accessible memory location[5]. 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[6] does not support applications that use these instructions. It relies on WineHQ for this [7]. Furthermore, the applications for which the concern was raised run in protected mode [5]. === 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 enabed: 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 were performed to test all the combinations of ModRM, SiB and displacements for 16-bit and 32-bit encodings for the ss, ds, es and fs segments. This was done for both virtual-8086 and protected mode. Code of these tests can be found here [8]. [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://www.winehq.org/ [5]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html [6]. http://www.dosemu.org/ [7]. http://marc.info/?l=linux-kernel&m=147876798717927&w=2 [8]. https://github.com/01org/luv-yocto/blob/rneri/umip/meta-luv/recipes-core/um… Thanks and BR, Ricardo 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 (17): 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 function 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-eval: Add support to resolve 16-bit addressing 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 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/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 | 303 +++++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-eval.c | 742 ++++++++++++++++++++++++++ arch/x86/mm/mpx.c | 120 +---- tools/testing/selftests/x86/entry_from_vm86.c | 39 +- 14 files changed, 1164 insertions(+), 122 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

9 32

Outreachy May-August 2017
by Delight Mawoyo 24 Feb '17

24 Feb '17

Hello everyone. My name is Delight Mawoyo, I'm 21years old from Zimbabwe studying Computer Science. I would like to participate in the next Outreachy round by working on the appDB webapp. I have not yet submitted a contribution but I have a local clone of the repo and would appreciate any suggestions for issues I could look at. I would ultimately like my work on appDB to center around rebuilding the entire site... I was honestly shocked when I saw the php code been run and how untidy the site is. Most of my work would center on changing the legacy php code structure to be powered by a PHP MVC framework... I had BonFire in mind.(basically CodeIgniter with a built in customiszable admin interface) For UI I would like to use Twitter Bootstrap and possibly use AngularJS for the user dashboard to make the site more responsive. The main site, the one indexable by search engines won't use AngularJS. I have experience in all the aforementioned and migrating legacy PHP code to an MVC framework. Please any help, tips and suggestions in line with my project proposal is greatly appreciated. I am also interested in the wine test graphical user interface project but I am a bit rusty in C. Thank you!!!

2 1

Re: kernel32: Disable diagnostics when testing corner cases in test_heap().
by Erich E. Hoover 24 Feb '17

24 Feb '17

On Sat, Feb 11, 2017 at 2:41 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > ... > With that dlls/kernel32/tests/heap.c triggers three warnings, all of > which are correct positives, but in fact do want to test those corner > cases: I'm not convinced that this statement is true. For example, while "~(SIZE_T)0 - 7" gives us 4294967288 (matching what is indicated by the warning), HeapReAlloc accepts a SIZE_T. So, this should support a maximum value of 4294967295 (not 2147483647). This says to me that gcc thinks SIZE_T is a signed value instead of an unsigned value, do you have any idea why this might be the case? Best, Erich

3 3

Re: wineinstall - Add support for parallel builds using 'nproc' to detect cpu count
by wylda＠volny.cz 24 Feb '17

24 Feb '17

______________________________________________________________ > Od: Chris Morgan <chmorgan(a)gmail.com> > Komu: Austin English <austinenglish(a)gmail.com> > Datum: 24.02.2017 13:53 > Předmět: Re: wineinstall - Add support for parallel builds using 'nproc' to > > CC: <wine-devel(a)winehq.org> >On Fri, Feb 24, 2017 at 3:11 AM, Austin English <austinenglish(a)gmail.com> >wrote: > >> On Fri, Feb 24, 2017 at 2:05 AM, <wylda(a)volny.cz> wrote: >> > Hi, >> > i like/use "make -j 1" for log comparison. Can you leave NPROC=1 or >> allow override? >> > >> > W. >> > >> > >> >> Hi Wylda, >> >> Are you doing that with wineinstall? This doesn't affect normal >> ./configure && make, only ./tools/wineinstall. >> >> That said, allowing the user to set it via NPROC or similar would be a >> good idea IMO. >> >> -- >> -Austin >> GPG: 14FB D7EA A041 937B >> > > > >Is this what you had in mind? I wasn't sure how to document that you could >do: > >NPROC=50 ./tools/wineinstall > >to force 50 parallel processes. > > >commit 83321d6452706b5f8f93687ed4e0909aac47fd68 >Author: Chris Morgan <chmorgan(a)gmail.com> >Date: Tue Feb 21 17:03:30 2017 -0500 > > wineinstall - Add support for parallel builds using 'nproc' to detect >cpu count > > Parallel builds can greatly reduce the overall build time on modern >multi-core processors. > > Fall back to two parallel builds in the case where nproc is >unavailable, most modern > processors have at least two cores. > > Use the 'NPROC' value defined by the environment if it is not null. > >diff --git a/tools/wineinstall b/tools/wineinstall >index e8e22bf..a757343 100755 >--- a/tools/wineinstall >+++ b/tools/wineinstall >@@ -143,10 +143,22 @@ echo "in the meantime..." > echo > std_sleep > >+# determine ideal number of parallel processes if NPROC isn't set >+# in the environment >+if [ ! -n $NPROC ] >+then >+ if [ -x `which nproc 2>/dev/null` ] >+ then >+ NPROC=$(nproc --all) >+ else >+ NPROC=2 >+ fi >+fi >+ > # try to just make wine, if this fails 'make depend' and try to remake >-if ! { make; } >+if ! { make -j$NPROC; } > then >- if ! { make depend && make; } >+ if ! { make depend && make -j$NPROC; } > then > echo > echo "Compilation failed, aborting install." > > Hi, as Austin noted, i'm probably not affected by your changes ;) sorry for the noise. But as a user i like the possibility to pass values by command line. Thank you. W.

1 0

Re: [PATCH] mouse.c - Wrap XInput2 dependent functions with appropriate #ifdef
by Bruno Jesus 24 Feb '17

24 Feb '17

On Thu, Feb 23, 2017 at 10:23 PM, Chris Morgan <chmorgan(a)gmail.com> wrote: > Fixes a compilation issue in mouse.c when XInput2 isn't available. Both patches you sent are missing a signed-off line. Please see https://wiki.winehq.org/Submitting_Patches#The_commit_message

1 0

Re: [PATCH] dpwsockx: Implementation of GetCaps callback
by Bruno Jesus 24 Feb '17

24 Feb '17

On Fri, Feb 24, 2017 at 3:45 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Based on patch by Ismael Barros > > Changes > - Removed todo_wine from tests > - Adjusted the DPWS_GUARANTEED_MAXBUFFERSIZE and DPWS_MAXBUFFERSIZE > to be the correct values > - Remove unused defines. > - Remove Adjustment of dwMaxBufferSize by sizeof(DPSP_MSG_HEADER) > - Added check for structure size. Thanks for your work on this, very minor stuff follows. > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dplayx/dplay.c | 3 +++ > dlls/dplayx/tests/dplayx.c | 6 ++---- > dlls/dpwsockx/dpwsockx_dll.h | 10 ++++++++++ > dlls/dpwsockx/dpwsockx_main.c | 27 +++++++++++++++++++++++++-- > 4 files changed, 40 insertions(+), 6 deletions(-) > > diff --git a/dlls/dplayx/dplay.c b/dlls/dplayx/dplay.c > index f4d934f..b8d2f15 100644 > --- a/dlls/dplayx/dplay.c > +++ b/dlls/dplayx/dplay.c > @@ -2894,6 +2894,9 @@ static HRESULT WINAPI IDirectPlay4Impl_GetPlayerCaps( IDirectPlay4 *iface, DPID > if ( This->dp2->connectionInitialized == NO_PROVIDER ) > return DPERR_UNINITIALIZED; > > + if( caps->dwSize != sizeof(DPCAPS) ) > + return DPERR_INVALIDPARAMS; > + > /* Query the service provider */ > data.idPlayer = player; > data.dwFlags = flags; > diff --git a/dlls/dplayx/tests/dplayx.c b/dlls/dplayx/tests/dplayx.c > index de392aa..32e5e1f 100644 > --- a/dlls/dplayx/tests/dplayx.c > +++ b/dlls/dplayx/tests/dplayx.c > @@ -1088,7 +1088,7 @@ static void test_GetCaps(void) > > /* dpcaps not ininitialized */ > hr = IDirectPlayX_GetCaps( pDP, &dpcaps, 0 ); > - todo_wine checkHR( DPERR_INVALIDPARAMS, hr ); > + checkHR( DPERR_INVALIDPARAMS, hr ); > > dpcaps.dwSize = sizeof(DPCAPS); > > @@ -1098,9 +1098,7 @@ static void test_GetCaps(void) > { > > hr = IDirectPlayX_GetCaps( pDP, &dpcaps, dwFlags ); > - todo_wine checkHR( DP_OK, hr ); > - > - > + checkHR( DP_OK, hr ); > if ( hr == DP_OK ) > { Since now the test must always pass in wine it could be useful to add a win_skip to the else branch or invert the if and use continue. If the if was added only for wine the whole if could be removed then. > check( sizeof(DPCAPS), dpcaps.dwSize ); > diff --git a/dlls/dpwsockx/dpwsockx_dll.h b/dlls/dpwsockx/dpwsockx_dll.h > index 1a6ad6c..debcc11 100644 > --- a/dlls/dpwsockx/dpwsockx_dll.h > +++ b/dlls/dpwsockx/dpwsockx_dll.h > @@ -26,6 +26,16 @@ > #include "wine/dplaysp.h" > > > +#define DPWS_MAXQUEUESIZE 0 > +#define DPWS_HUNDREDBAUD 0 > +#define DPWS_LATENCY 500 > +#define DPWS_MAXLOCALPLAYERS 65536 > +#define DPWS_TIMEOUT 5000 > +#define DPWS_MAXBUFFERSIZE 65479 > +#define DPWS_MAXPLAYERS 65536 > +#define DPWS_GUARANTEED_MAXBUFFERSIZE 1048547 > +#define DPWS_GUARANTEED_MAXPLAYERS 64 > + There is an extra new line before the defines. > typedef struct tagDPWS_THREADDATA > { > BOOL is_running; > diff --git a/dlls/dpwsockx/dpwsockx_main.c b/dlls/dpwsockx/dpwsockx_main.c > index 548f37e..9606d73 100644 > --- a/dlls/dpwsockx/dpwsockx_main.c > +++ b/dlls/dpwsockx/dpwsockx_main.c > @@ -100,9 +100,32 @@ static HRESULT WINAPI DPWSCB_GetAddress( LPDPSP_GETADDRESSDATA data ) > > static HRESULT WINAPI DPWSCB_GetCaps( LPDPSP_GETCAPSDATA data ) > { > - FIXME( "(%d,%p,0x%08x,%p)\n", > + TRACE( "(%d,%p,0x%08x,%p)\n", > data->idPlayer, data->lpCaps, data->dwFlags, data->lpISP ); > - return DPERR_UNSUPPORTED; > + Is it worth to test a NULL data?

1 0

Re: ntdll: Fix some more spec file entries
by Alexandre Julliard 24 Feb '17

24 Feb '17

André Hentschel <nerv(a)dawncrow.de> writes: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/ntdll/ntdll.spec | 10 +++++----- > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 4 ++-- > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index 66618fc..e666b90 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -101,7 +101,7 @@ > # @ stub NtAccessCheckByTypeResultList > # @ stub NtAccessCheckByTypeResultListAndAuditAlarm > # @ stub NtAccessCheckByTypeResultListAndAuditAlarmByHandle > -@ stdcall NtAddAtom(ptr long ptr) > +@ stdcall NtAddAtom(wstr long ptr) Functions that take a string length don't always get null-terminated strings so you don't want to print them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] ddraw/tests: Test depth fill results in test_color_fill().
by Marvin 24 Feb '17

24 Feb '17

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=28861 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:10191: Test failed: Got unexpected color 0x00ffffff.

1 0

Re: SECURITY ALERT -- Remotely exploitable wine <= 2.x bugs via unencrypted plaintext HTTP intermediation
by Michael Müller 23 Feb '17

23 Feb '17

Hello Kristian, it is true that the download is done via HTTP, but there is a checksum verification using a hardcoded hash value after the download. See http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/appwiz.cpl/addons.c for more details. It could be discussed whether sha1 is still considered secure enough, but I think there is a reason why it was chosen. Wine is modular and can be built without a cryptographic library (gnutls / CommonCrypto) and then lacks support for TLS and most hash functions. SHA1 is built into Wine though. Using this method guarantees that the download will also work in a minimal Wine built. Regards, Michael Am 02.02.2017 um 15:00 schrieb Kristian Erik Hermansen: > Hello Wine Maintainers :) > > Wine v2.x, and likely all earlier version, contain remotely > exploitable flaws because binaries are downloaded via insecure > plaintext HTTP and appear to contain insufficient signature > verification. This can occur when prompted to download missing files > such as Wine Gecko. The connection occurs over HTTP and can be > intermediated to compromise the client machine with a malicious > payload. Please advise if you are not already aware of this, when a > fix is planned, and if you need any additional information. Thanks :) >

2 1

Re: [PATCH 2/7] wined3d: Fix handling of SM4+ integer registers.
by Henri Verbeet 23 Feb '17

23 Feb '17

On 23 February 2017 at 15:00, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -2972,40 +3016,27 @@ static void shader_glsl_add_src_param_ext(const struct wined3d_shader_instructio > shader_glsl_get_register_name(&wined3d_src->reg, glsl_src->reg_name, &is_color, ins); > shader_glsl_get_swizzle(wined3d_src, is_color, mask, swizzle_str); > > - if (wined3d_src->reg.type == WINED3DSPR_IMMCONST > - || wined3d_src->reg.type == WINED3DSPR_PRIMID > - || wined3d_src->reg.type == WINED3DSPR_LOCALTHREADINDEX > - || wined3d_src->reg.type == WINED3DSPR_THREADID > - || wined3d_src->reg.type == WINED3DSPR_THREADGROUPID > - || wined3d_src->reg.type == WINED3DSPR_LOCALTHREADID) > + switch (wined3d_src->reg.type) > { > - shader_glsl_gen_modifier(wined3d_src->modifiers, glsl_src->reg_name, swizzle_str, glsl_src->param_str); > + case WINED3DSPR_IMMCONST: > + param_data_type = data_type; > + break; This matches the existing behaviour, and in that regard this is fine, and it probably won't matter in practice, but note that shader_glsl_get_register_name() uses "reg->data_type", which isn't necessarily the same as "data_type" here. I think the usage of sprintf() is more problematic. That too matches the existing code, but we should be using string_buffer_sprintf() for this kind of thing.

1 0

Re: [PATCH 3/3] shell32: Added SHGetPathFromIDListEx implementation.
by Marvin 23 Feb '17

23 Feb '17

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=28846 Your paranoid android. === wvistau64 (32 bit shlfolder) === shlfolder.c:457: Test failed: 0: got 7480017f expected 7080017f shlfolder.c:457: Test failed: 1: got f480017f expected 7080017f shlfolder.c:457: Test failed: 2: got 44400177 expected 40400177 shlfolder.c:457: Test failed: 3: got 44400177 expected 40400177 shlfolder.c:457: Test failed: 4: got 44400177 expected 40400177 === wvistau64 (64 bit shlfolder) === shlfolder.c:457: Test failed: 0: got 7480017f expected 7080017f shlfolder.c:457: Test failed: 1: got f480017f expected 7080017f shlfolder.c:457: Test failed: 2: got 44400177 expected 40400177 shlfolder.c:457: Test failed: 3: got 44400177 expected 40400177 shlfolder.c:457: Test failed: 4: got 44400177 expected 40400177 === w1064 (64 bit shlfolder) === shlfolder.c:4950: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 40000) shlfolder.c:4933: Test failed: MKDIR: expected notification type 8, got: 40000 shlfolder.c:4940: Test failed: GetDisplayNameOf failed: 0x80070057 shlfolder.c:4950: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 8)

2 1

Re: msvcrt: Fix _CxxThrowException spec file entry
by Piotr Caban 23 Feb '17

23 Feb '17

Hi, On 02/22/17 21:28, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/msvcrt/msvcrt.spec | 2 +- > dlls/msvcrt20/msvcrt20.spec | 2 +- > dlls/msvcrt40/msvcrt40.spec | 2 +- > dlls/msvcrtd/msvcrtd.spec | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) Could you please also change the _CxxThrowException spec entry in other msvcrXX/ucrtbase/... dlls? Thanks, Piotr

1 0

Re: mscms: Fix some spec file entries
by Hans Leidekker 23 Feb '17

23 Feb '17

On Wed, 2017-02-22 at 23:23 +0100, André Hentschel wrote: > -@ stdcall SetStandardColorSpaceProfileA(ptr long ptr) > -@ stdcall SetStandardColorSpaceProfileW(ptr long ptr) > +@ stdcall SetStandardColorSpaceProfileA(str long ptr) > +@ stdcall SetStandardColorSpaceProfileW(wstr long ptr) The last parameter should also be w/str.

1 0

Re: widl: Initialize variables that are not necessarily filled in encode_type
by Huw Davies 23 Feb '17

23 Feb '17

On Mon, Feb 20, 2017 at 10:06:46PM +0100, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > > This helps with reproducable builds > > tools/widl/write_msft.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c > index 137bb2d..39be30b 100644 > --- a/tools/widl/write_msft.c > +++ b/tools/widl/write_msft.c > @@ -2195,7 +2195,7 @@ static void add_union_typeinfo(msft_typelib_t *typelib, type_t *tunion) > static void add_typedef_typeinfo(msft_typelib_t *typelib, type_t *tdef) > { > msft_typeinfo_t *msft_typeinfo = NULL; > - int alignment, datatype1, datatype2, size, duplicate = 0; > + int alignment = 0, datatype1 = 0, datatype2 = 0, size = 0, duplicate = 0; encode_type() initializes alignment, datatype1 and size in all cases, so these are unnecessary. The question then becomes where is the best place to initialize datatype2 (a.k.a. decoded_size). Since no caller to encode_type() relies on the existing value being preserved, it makes sense to initialize it in encode_type(). So just send the patch you originally sent to wine-devel. Huw.

2 2

Re: [PATCH] oledb32: Correct length calculation in DataConvert for DBTYPE_STR
by Huw Davies 23 Feb '17

23 Feb '17

On Thu, Feb 23, 2017 at 06:49:58AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/convert.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index ac462f2..7030eb5 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -816,23 +816,23 @@ static HRESULT WINAPI convert_DataConvert(IDataConvert* iface, > case DBTYPE_STR: > { > BSTR b; > - DBLENGTH bstr_len; > + DBLENGTH length; > INT bytes_to_copy; > - hr = IDataConvert_DataConvert(iface, src_type, DBTYPE_BSTR, src_len, &bstr_len, > + hr = IDataConvert_DataConvert(iface, src_type, DBTYPE_BSTR, src_len, &length, > src, &b, sizeof(BSTR), src_status, dst_status, > precision, scale, flags); > if(hr != S_OK) return hr; > - bstr_len = SysStringLen(b); > - *dst_len = bstr_len * sizeof(char); /* Doesn't include size for '\0' */ > + length = WideCharToMultiByte(CP_ACP, 0, b, -1, NULL, 0, NULL, NULL); > + *dst_len = length - 1; /* Doesn't include size for '\0' */ > *dst_status = DBSTATUS_S_OK; > - bytes_to_copy = min(*dst_len + sizeof(char), dst_max_len); > + bytes_to_copy = min(length, dst_max_len); > if(dst) > { > if(bytes_to_copy >= sizeof(char)) > { > - WideCharToMultiByte(CP_ACP, 0, b, bytes_to_copy - sizeof(char), dst, dst_max_len, NULL, NULL); > + WideCharToMultiByte(CP_ACP, 0, b, -1, dst, dst_max_len, NULL, NULL); > *((char *)dst + bytes_to_copy / sizeof(char) - 1) = 0; > - if(bytes_to_copy < *dst_len + sizeof(char)) > + if(bytes_to_copy < length) > *dst_status = DBSTATUS_S_TRUNCATED; > } > else This fails the tests: convert.c:1926: Test failed: got 2 I suspect you want to use SysStringLen(b) as the wstr len in the calls to WideCharToMultiByte. It would also be worth adding a test for DBTYPE_STR | DBTYPE_BYREF in this case too. Huw.

1 0

Re: user32: Fix some spec file entries
by Alexandre Julliard 23 Feb '17

23 Feb '17

André Hentschel <nerv(a)dawncrow.de> writes: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/user32/user32.spec | 34 +++++++++++++++++----------------- > 1 file changed, 17 insertions(+), 17 deletions(-) > > diff --git a/dlls/user32/user32.spec b/dlls/user32/user32.spec > index c2d43e7..b64a630 100644 > --- a/dlls/user32/user32.spec > +++ b/dlls/user32/user32.spec > @@ -7,8 +7,8 @@ > @ stdcall AllowSetForegroundWindow (long) > @ stdcall AnimateWindow(long long long) > @ stdcall AnyPopup() > -@ stdcall AppendMenuA(long long long ptr) > -@ stdcall AppendMenuW(long long long ptr) > +@ stdcall AppendMenuA(long long long str) > +@ stdcall AppendMenuW(long long long wstr) Strings in menu calls are not always strings, you don't want to print them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] user32: Translate WM_(NC)XBUTTONUP to WM_APPCOMMAND in DefWindowProc.
by Marvin 23 Feb '17

23 Feb '17

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=28823 Your paranoid android. === w7u (32 bit msg) === msg.c:7920: Test failed: destroy child on thread exit: 1: the msg sequence is not complete: expected 000f - actual 0000

1 0

Re: d3dx9_36: Fix some spec file entries
by Matteo Bruni 22 Feb '17

22 Feb '17

2017-02-22 21:28 GMT+01:00 André Hentschel <nerv(a)dawncrow.de>: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> BTW, the other d3dx9_xx.spec files seem to need the same fix.

1 0

Re: [PATCH] d3d9/tests: AMD r500 needs dummy texture output from vertex shaders for point sprites to work (v2).
by Marvin 22 Feb '17

22 Feb '17

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=28812 Your paranoid android. === w8 (32 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). === w864 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test. === w1064 (64 bit visual) === visual.c:7941: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00ff0000 for no color attribute test.

1 0

Outreachy project
by Ekta Parmar 22 Feb '17

22 Feb '17

Hey! Ekta Parmar here, I am currently pursuing B.Tech degree in Information and Communication Technology and I am in second year.I am quite new to open source contribution.I am interested in Winetest Graphical User Interface project.Please guide me further.

2 1

iphlpapi test failure
by André Hentschel 22 Feb '17

22 Feb '17

Hi François, It seems I introduced some test failures in iphlpapi and your machines seem to produce them reliable (testbot doesn't). Could you please run with the attached patch as soon as you have time for it, so I can shed some light on the problem? See https://test.winehq.org/data/tests/iphlpapi:iphlpapi.html

2 2

Re: [PATCH 7/7] server: Pass existing async object to fd_queue_async.
by Alexandre Julliard 22 Feb '17

22 Feb '17

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -2030,23 +2030,22 @@ void default_poll_event( struct fd *fd, int event ) > else if (!fd->inode) set_fd_events( fd, fd->fd_ops->get_poll_events( fd ) ); > } > > -struct async *fd_queue_async( struct fd *fd, const async_data_t *data, struct iosb *iosb, int type ) > +void fd_queue_async( struct fd *fd, struct async *async, int type ) > { > struct async_queue *queue; > - struct async *async; > > switch (type) > { > case ASYNC_TYPE_READ: > - if (!fd->read_q && !(fd->read_q = create_async_queue( fd ))) return NULL; > + if (!fd->read_q && !(fd->read_q = create_async_queue( fd ))) return; > queue = fd->read_q; > break; > case ASYNC_TYPE_WRITE: > - if (!fd->write_q && !(fd->write_q = create_async_queue( fd ))) return NULL; > + if (!fd->write_q && !(fd->write_q = create_async_queue( fd ))) return; > queue = fd->write_q; > break; > case ASYNC_TYPE_WAIT: > - if (!fd->wait_q && !(fd->wait_q = create_async_queue( fd ))) return NULL; > + if (!fd->wait_q && !(fd->wait_q = create_async_queue( fd ))) return; > queue = fd->wait_q; > break; > default: > @@ -2054,18 +2053,15 @@ struct async *fd_queue_async( struct fd *fd, const async_data_t *data, struct io > assert(0); > } > > - if ((async = create_async( current, data, iosb ))) > + queue_async( queue, async ); > + > + if (type != ASYNC_TYPE_WAIT) > { > - queue_async( queue, async ); > - if (type != ASYNC_TYPE_WAIT) > - { > - if (!fd->inode) > - set_fd_events( fd, fd->fd_ops->get_poll_events( fd ) ); > - else /* regular files are always ready for read and write */ > - async_wake_up( queue, STATUS_ALERTED ); > - } > + if (!fd->inode) > + set_fd_events( fd, fd->fd_ops->get_poll_events( fd ) ); > + else /* regular files are always ready for read and write */ > + async_wake_up( queue, STATUS_ALERTED ); > } > - return async; > } > > void fd_async_wake_up( struct fd *fd, int type, unsigned int status ) > @@ -2098,11 +2094,8 @@ void no_fd_queue_async( struct fd *fd, struct async *async, int type, int count > > void default_fd_queue_async( struct fd *fd, struct async *async, int type, int count ) > { > - if ((async = fd_queue_async( fd, async_get_data( async ), NULL, type ))) > - { > - release_object( async ); > - set_error( STATUS_PENDING ); > - } > + fd_queue_async( fd, async, type ); > + if (!get_error()) set_error( STATUS_PENDING ); I think it would be better to still have fd_queue_async() return a success flag instead of relying on the error code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [v2 PATCH 1/2] include: Add mfreadwrite.idl
by Alex Henrie 22 Feb '17

22 Feb '17

+ HRESULT ReadSample([in] DWORD index, [in] DWORD flags, [out] DWORD *actualindex, [out] DWORD *Streamflags, + [out] LONGLONG *timestamp, [out] IMFSample **sample); +cpp_quote("HRESULT WINAPI MFCreateSourceReaderFromMediaSource(IMFMediaSource *source,") +cpp_quote(" IMFAttributes *attributes, IMFSourceReader **reader);") Please choose a consistent indentation style. I think most commonly Wine code indents the second line of parameters to start at the column after the ( in the first line. It would also be OK to indent the second line by 12 spaces like you did in the first example. The same goes for the second patch in this series. Additionally, the capital S is "Streamflags" looks like a mistake. -Alex

1 0

Re: [PATCH 4/4] d3d9/tests: Check encryption support, not WARP in test_create_depth_stencil_surface_ex.
by Henri Verbeet 21 Feb '17

21 Feb '17

On 20 February 2017 at 23:31, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > This change intentionally accepts the success on Wine despite unsupported > D3DUSAGE_RESTRICTED_CONTENT. > Why would you want to do that? This should probably rename "broken_warp" to "optional", and then validate the results are consistent with CheckDeviceFormat().

2 1

Re: ntdll: Use environment variable "WINESERVER" first on search for wineserver to start.
by Sebastian Lackner 21 Feb '17

21 Feb '17

On 15.02.2017 15:27, Ralf Habacker wrote: > This fixes the issue that WINESERVER environment variable is only > used if @bindir@/wineserver does not exist. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=40811 Maybe I'm missing something, but what would be the purpose of running a different wineserver? If the protocol version does not match this will not work anyway. > > Signed-off-by: Ralf Habacker <ralf.habacker(a)freenet.de> > --- > libs/wine/config.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/libs/wine/config.c b/libs/wine/config.c > index 3b5dd68..433666b 100644 > --- a/libs/wine/config.c > +++ b/libs/wine/config.c > @@ -530,6 +530,13 @@ void wine_exec_wine_binary( const char *name, char > **argv, const char *env_var ) It looks like your mail client corrupted the patch. > use_preloader = 0; > #endif > + /* first specified environment variable */ > + if (env_var) > + { > + argv[0] = (char *)env_var; > + preloader_exec( argv, use_preloader ); > + } > + > if ((ptr = strrchr( name, '/' ))) > { > /* if we are in build dir and name contains a path, try that */ > @@ -542,7 +549,7 @@ void wine_exec_wine_binary( const char *name, char > **argv, const char *env_var ) > name = ptr + 1; /* get rid of path */ > } > - /* first, bin directory from the current libdir or argv0 */ > + /* then, bin directory from the current libdir or argv0 */ > if (bindir) > { > argv[0] = build_path( bindir, name ); > @@ -550,13 +557,6 @@ void wine_exec_wine_binary( const char *name, char > **argv, const char *env_var ) > free( argv[0] ); > } > - /* then specified environment variable */ > - if (env_var) > - { > - argv[0] = (char *)env_var; > - preloader_exec( argv, use_preloader ); > - } > - > /* now search in the Unix path */ > if ((path = getenv( "PATH" ))) > { >

4 8

Uninitialized varying test on r500 on Windows
by Stefan Dösinger 21 Feb '17

21 Feb '17

Hi Matteo, I'm trying to make my Windows systems test failure free and I'd like to ask you for your opinion of a failure I am getting in test_uninitialized_varyings on my r500 GPU (Radeon X1600M) I have attached the output of d3d9:visual to this mail. I am a bit lost how those results fit in the grand scheme of things. Is it just another case of some varying components being initialized to 0 and others to 1, or do you see a pattern in these? The .y=0.5 result in test cases 14 and 17 are weird as well. The test failure in line 7362 (pretransformed_varying_test) seems related too, although here my card behaves in the same way as WARP. The d3d8 version of test_uninitialized_varyings is affected as well. The line numbers are from commit 9eb56e25e37b4adec0d72875455ffb787238672f. Cheers, Stefan

2 1

Re: qcap: Define O_CLOEXEC when needed (try 2)
by Sebastian Lackner 21 Feb '17

21 Feb '17

On 21.02.2017 00:21, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > > https://bugs.winehq.org/show_bug.cgi?id=42478 > Thanks Bruno for the note on octal > > dlls/qcap/v4l.c | 4 +++ > dlls/setupapi/devinst.c | 71 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/setupapi/dialog.c | 2 ++ > dlls/setupapi/dirid.c | 2 ++ > dlls/setupapi/diskspace.c | 10 +++++++ > dlls/setupapi/install.c | 10 +++++++ > dlls/setupapi/misc.c | 42 +++++++++++++++++++++++++++ > dlls/setupapi/parser.c | 27 +++++++++++++++++ > dlls/setupapi/query.c | 12 ++++++++ > dlls/setupapi/queue.c | 44 ++++++++++++++++++++++++++++ > dlls/setupapi/setupcab.c | 2 ++ > dlls/setupapi/stringtable.c | 13 +++++++++ > dlls/setupapi/stubs.c | 63 ++++++++++++++++++++++++++++++++++++++++ > 13 files changed, 302 insertions(+) It looks like you added various unrelated changes. Also, defining O_CLOEXEC will have no effect when its not supported by the operating system. We could use fcntl( fd, F_SETFD, FD_CLOEXEC ); as a portable way to set close-on-exec for all platforms.

2 1

Re: [PATCH 2/3] storage.dll16: Correctly handle block values of -1.
by Alexandre Julliard 21 Feb '17

21 Feb '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > @@ -610,9 +610,10 @@ STORAGE_get_nth_next_small_blocknr(stream_access16*str,int blocknr,int nr) { > READ_HEADER(str); > assert(blocknr>=0); > while ((nr--) && (blocknr>=0)) { > - if (lastblocknr/128!=blocknr/128) { > + if (lastblocknr>>7 != blocknr>>7) > + { > int bigblocknr; > - bigblocknr = STORAGE_get_nth_next_big_blocknr(str,sth.sbd_startblock,blocknr/128); > + bigblocknr = STORAGE_get_nth_next_big_blocknr(str,sth.sbd_startblock,blocknr>>7); I'm not sure what you are trying to fix. Most places already check that blocknr is >= 0, and if it's really negative, you can't rely on right shift doing the right thing. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] oledb32: Suport converting to DBTYPE_BYREF | DBTYPE_STR in DataConvert
by Huw Davies 21 Feb '17

21 Feb '17

On Wed, Feb 15, 2017 at 04:36:38AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/convert.c | 26 ++++++++++++ > dlls/oledb32/tests/convert.c | 94 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 120 insertions(+) > > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index 0a1518d9a9..cd4161c886 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -845,6 +845,32 @@ static HRESULT WINAPI convert_DataConvert(IDataConvert* iface, > return hr; > } > > + case DBTYPE_BYREF | DBTYPE_STR: > + { > + BSTR b; > + char **d = dst; > + DBLENGTH bstr_len; > + hr = IDataConvert_DataConvert(iface, src_type, DBTYPE_BSTR, src_len, &bstr_len, > + src, &b, sizeof(BSTR), src_status, dst_status, > + precision, scale, flags); > + if(hr != S_OK) return hr; > + > + bstr_len = SysStringLen(b) * sizeof(char); > + *dst_len = bstr_len; /* Doesn't include size for '\0' */ dst_len should be calculated by calling WideCharToMultiByte(). This is also a bug in the DBTYPE_STR handling above (which I guess is where this came from). > + *dst_status = DBSTATUS_S_OK; > + *d = CoTaskMemAlloc(bstr_len + sizeof(char)); And this should be dst_len; It probably makes sense to move this case below DBTYPE_BYREF | DBTYPE_WSTR, to mirror the order of DBTYPE_WSTR / DBTYPE_STR. Huw.

2 1

Re: [PATCH 1/6] usp10: Introduce an enumeration for GPOS lookup types.
by Aric Stewart 21 Feb '17

21 Feb '17

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> On 2/19/17 12:02 PM, Henri Verbeet wrote: > As opposed to using magic numbers. > > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > This supersedes patch 130419. > --- > dlls/usp10/opentype.c | 57 ++++++++++++++++++++++++++++++++++++--------------- > 1 file changed, 40 insertions(+), 17 deletions(-) > > diff --git a/dlls/usp10/opentype.c b/dlls/usp10/opentype.c > index a9aa4f4..a67bba7 100644 > --- a/dlls/usp10/opentype.c > +++ b/dlls/usp10/opentype.c > @@ -48,6 +48,19 @@ WINE_DEFAULT_DEBUG_CHANNEL(uniscribe); > /* These are all structures needed for the cmap format 12 table */ > #define CMAP_TAG MS_MAKE_TAG('c', 'm', 'a', 'p') > > +enum gpos_lookup_type > +{ > + GPOS_LOOKUP_ADJUST_SINGLE = 0x1, > + GPOS_LOOKUP_ADJUST_PAIR = 0x2, > + GPOS_LOOKUP_ATTACH_CURSIVE = 0x3, > + GPOS_LOOKUP_ATTACH_MARK_TO_BASE = 0x4, > + GPOS_LOOKUP_ATTACH_MARK_TO_LIGATURE = 0x5, > + GPOS_LOOKUP_ATTACH_MARK_TO_MARK = 0x6, > + GPOS_LOOKUP_POSITION_CONTEXT = 0x7, > + GPOS_LOOKUP_POSITION_CONTEXT_CHAINED = 0x8, > + GPOS_LOOKUP_POSITION_EXTENSION = 0x9, > +}; > + > typedef struct { > WORD platformID; > WORD encodingID; > @@ -1587,7 +1600,7 @@ static const BYTE *GPOS_get_subtable(const OT_LookupTable *look, int index) > { > int offset = GET_BE_WORD(look->SubTable[index]); > > - if (GET_BE_WORD(look->LookupType) == 9) > + if (GET_BE_WORD(look->LookupType) == GPOS_LOOKUP_POSITION_EXTENSION) > { > const GPOS_ExtensionPosFormat1 *ext = (const GPOS_ExtensionPosFormat1 *)((const BYTE *)look + offset); > if (GET_BE_WORD(ext->PosFormat) == 1) > @@ -2250,13 +2263,15 @@ static INT GPOS_apply_lookup(ScriptCache *psc, LPOUTLINETEXTMETRICW lpotm, LPLOG > int offset; > const OT_LookupTable *look; > int ppem = lpotm->otmTextMetrics.tmAscent + lpotm->otmTextMetrics.tmDescent - lpotm->otmTextMetrics.tmInternalLeading; > - WORD type; > + enum gpos_lookup_type type; > > offset = GET_BE_WORD(lookup->Lookup[lookup_index]); > look = (const OT_LookupTable*)((const BYTE*)lookup + offset); > type = GET_BE_WORD(look->LookupType); > - TRACE("type %i, flag %x, subtables %i\n",type,GET_BE_WORD(look->LookupFlag),GET_BE_WORD(look->SubTableCount)); > - if (type == 9) > + TRACE("type %#x, flag %#x, subtables %u.\n", type, > + GET_BE_WORD(look->LookupFlag), GET_BE_WORD(look->SubTableCount)); > + > + if (type == GPOS_LOOKUP_POSITION_EXTENSION) > { > if (GET_BE_WORD(look->SubTableCount)) > { > @@ -2278,7 +2293,7 @@ static INT GPOS_apply_lookup(ScriptCache *psc, LPOUTLINETEXTMETRICW lpotm, LPLOG > } > switch (type) > { > - case 1: > + case GPOS_LOOKUP_ADJUST_SINGLE: > { > double devX, devY; > POINT adjust = {0,0}; > @@ -2299,7 +2314,8 @@ static INT GPOS_apply_lookup(ScriptCache *psc, LPOUTLINETEXTMETRICW lpotm, LPLOG > } > break; > } > - case 2: > + > + case GPOS_LOOKUP_ADJUST_PAIR: > { > POINT advance[2]= {{0,0},{0,0}}; > POINT adjust[2]= {{0,0},{0,0}}; > @@ -2333,7 +2349,8 @@ static INT GPOS_apply_lookup(ScriptCache *psc, LPOUTLINETEXTMETRICW lpotm, LPLOG > } > return index; > } > - case 3: > + > + case GPOS_LOOKUP_ATTACH_CURSIVE: > { > POINT desU = {0,0}; > double devX, devY; > @@ -2348,7 +2365,8 @@ static INT GPOS_apply_lookup(ScriptCache *psc, LPOUTLINETEXTMETRICW lpotm, LPLOG > } > break; > } > - case 4: > + > + case GPOS_LOOKUP_ATTACH_MARK_TO_BASE: > { > double devX, devY; > POINT desU = {0,0}; > @@ -2366,7 +2384,8 @@ static INT GPOS_apply_lookup(ScriptCache *psc, LPOUTLINETEXTMETRICW lpotm, LPLOG > } > break; > } > - case 5: > + > + case GPOS_LOOKUP_ATTACH_MARK_TO_LIGATURE: > { > double devX, devY; > POINT desU = {0,0}; > @@ -2379,7 +2398,8 @@ static INT GPOS_apply_lookup(ScriptCache *psc, LPOUTLINETEXTMETRICW lpotm, LPLOG > } > break; > } > - case 6: > + > + case GPOS_LOOKUP_ATTACH_MARK_TO_MARK: > { > double devX, devY; > POINT desU = {0,0}; > @@ -2393,14 +2413,17 @@ static INT GPOS_apply_lookup(ScriptCache *psc, LPOUTLINETEXTMETRICW lpotm, LPLOG > } > break; > } > - case 7: > - return GPOS_apply_ContextPos(psc, lpotm, lplogfont, analysis, piAdvance, lookup, look, glyphs, glyph_index, glyph_count, ppem, pGoffset); > - case 8: > - { > - return GPOS_apply_ChainContextPos(psc, lpotm, lplogfont, analysis, piAdvance, lookup, look, glyphs, glyph_index, glyph_count, ppem, pGoffset); > - } > + > + case GPOS_LOOKUP_POSITION_CONTEXT: > + return GPOS_apply_ContextPos(psc, lpotm, lplogfont, analysis, piAdvance, > + lookup, look, glyphs, glyph_index, glyph_count, ppem, pGoffset); > + > + case GPOS_LOOKUP_POSITION_CONTEXT_CHAINED: > + return GPOS_apply_ChainContextPos(psc, lpotm, lplogfont, analysis, piAdvance, > + lookup, look, glyphs, glyph_index, glyph_count, ppem, pGoffset); > + > default: > - FIXME("We do not handle SubType %i\n",type); > + FIXME("Unhandled GPOS lookup type %#x.\n", type); > } > return glyph_index+1; > } >

1 0

HID success
by Marcus Meissner 21 Feb '17

21 Feb '17

Hi, Small success story on HID ;) I just helped a colleague to enable the "Polar Loop 2" wristband for his wive. The device uses HID to synchronize settings and update firmware. While the device can be (later) configured used with Bluetooth and a Smartphone App, the basic initialization must be done with a Windows App. Wine worked nicely after the usual chmod og+rw /dev/hidraw0 (The reconnect after the firmware update had a bit of trouble, but the syncing of settings worked.) https://flow.polar.com/ Ciao, Marcus

2 1

Re: msxml3: Add __WINE_ALLOC_SIZE attributes to heap_xxx() functions.
by Nikolay Sivov 21 Feb '17

21 Feb '17

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>

1 0

Re: comctl32: Update the tooltip rectangle when a tool button is hidden
by Nikolay Sivov 21 Feb '17

21 Feb '17

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>

1 0

Re: [PATCH 3/4] d3d9/tests: AMD r500 needs dummy texture output from vertex shaders for point sprites to work.
by Marvin 21 Feb '17

21 Feb '17

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=28786 Your paranoid android. === w864 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 2/4] d3d9/tests: Work around a r500 Windows point sprite bug.
by Marvin 21 Feb '17

21 Feb '17

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=28785 Your paranoid android. === w1064 (64 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00000080 for no color attribute test.

1 0

Re: [PATCH 1/4] d3d8/tests: Work around a r500 Windows point sprite bug.
by Marvin 21 Feb '17

21 Feb '17

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=28784 Your paranoid android. === wvistau64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w2008s64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w7pro64 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w864 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?) === w1064 (64 bit visual) === d3d8:visual has no test summary line (early exit of the main process?)

1 0

Re: [PATCH 3/4] d3d9/tests: AMD r500 needs dummy texture output from vertex shaders for point sprites to work.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 23:31, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -10445,6 +10445,8 @@ static void test_pointsize(void) > vertex_pointsize = {64.0f, 64.0f, 0.1f, 48.0f}, > vertex_pointsize_scaled = {64.0f, 64.0f, 0.1f, 24.0f}, > vertex_pointsize_zero = {64.0f, 64.0f, 0.1f, 0.0f}; > + /* Writing a texture coordinate from the shader is technically unnecessary, but is required > + * to make AMD drivers work. Without it, texture coordinates in the pixel shaders are 0. */ Could you make that comment a bit more specific and mention the affected hardware and driver version?

1 0

Re: comctl32: Update the tooltip rectangle when a tool button is hidden
by Nikolay Sivov 20 Feb '17

20 Feb '17

On 20.02.2017 22:17, Eric Kohl wrote: > Signed-off-by: Eric Kohl <eric.kohl(a)t-online.de> > --- > dlls/comctl32/toolbar.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/comctl32/toolbar.c b/dlls/comctl32/toolbar.c > index 784745c..bb53d66 100644 > --- a/dlls/comctl32/toolbar.c > +++ b/dlls/comctl32/toolbar.c > @@ -1690,6 +1690,7 @@ TOOLBAR_LayoutToolbar(TOOLBAR_INFO *infoPtr) > if (btnPtr->fsState & TBSTATE_HIDDEN) > { > SetRectEmpty (&btnPtr->rect); > + TOOLBAR_TooltipSetRect(infoPtr, btnPtr); > continue; > } > Hi, Eric. What are symptoms of that? I'd guess it's causing tooltips to appear when they shouldn't, or tooltips from one button to appear for another. Do you have an demo application for that or any easy way to reproduce?

2 1

Re: qcap: Define O_CLOEXEC when needed
by Bruno Jesus 20 Feb '17

20 Feb '17

On Mon, Feb 20, 2017 at 7:28 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > > https://bugs.winehq.org/show_bug.cgi?id=42478 > > dlls/qcap/v4l.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/dlls/qcap/v4l.c b/dlls/qcap/v4l.c > index d67df73..19c6f2e 100644 > --- a/dlls/qcap/v4l.c > +++ b/dlls/qcap/v4l.c > @@ -71,6 +71,10 @@ WINE_DEFAULT_DEBUG_CHANNEL(qcap_v4l); > > #ifdef VIDIOCMCAPTURE > > +#ifndef O_CLOEXEC > +#define O_CLOEXEC 2000000 > +#endif Hi, comparing to my fcntl.h the value should be octal: #define O_CLOEXEC 02000000 /* set close_on_exec */ But FreeBSD 10 defines like: #define O_CLOEXEC 0x00100000 02000000 = 524288 0x00100000 = 1048576 So I guess it is better to define as zero or #ifdef it out.

1 1

Re: [PATCH 3/5] d3d9/tests: r500 GPUs only generate point sprite coords on texture coordinate 0.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 19 February 2017 at 12:47, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > @@ -10746,7 +10746,8 @@ static void test_pointsize(void) > IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > > /* The following code tests point sprites with two textures, to see if each texture coordinate unit > - * generates texture coordinates for the point(result: Yes, it does) > + * generates texture coordinates for the point. Result: Yes, it does, except on some older hardware > + * (r500 and earlier, probably others). > * > * However, not all GL implementations support point sprites(they need GL_ARB_point_sprite), but there > * is no point sprite cap bit in d3d because native d3d software emulates point sprites. Until the > @@ -10802,6 +10803,11 @@ static void test_pointsize(void) > color = getPixelColor(device, 64-4, 64-4); > ok(color == 0x00ff0000, "pSprite: Pixel (64-4),(64-4) has color 0x%08x, expected 0x00ff0000\n", color); > color = getPixelColor(device, 64-4, 64+4); > + if (color == 0x00ff0000) > + { > + skip("Hardware generates point sprite coordinates on texture unit 0 only.\n"); > + goto cleanup_1tex; > + } > ok(color == 0x00000000, "pSprite: Pixel (64-4),(64+4) has color 0x%08x, expected 0x00000000\n", color); > color = getPixelColor(device, 64+4, 64+4); > ok(color == 0x0000ff00, "pSprite: Pixel (64+4),(64+4) has color 0x%08x, expected 0x0000ff00\n", color); This test has been around for a while, did it always fail? I also have the impression the hardware should be able to do this, does this fail on Linux, Windows, or both?

2 1

Re: [PATCH 1/2] ddraw/tests: Check pointer after CreateSurface without a descriptor.
by Stefan Dösinger 20 Feb '17

20 Feb '17

Am 2017-02-17 um 06:05 schrieb Alex Henrie: > dlls/ddraw/tests/dsurface.c | 10 ++++++++++ The rule is to not add new things to these old files, even if it is a minor obvious fix. If you want to change a test in there move it to tests/ddraw*.c (changing the code style, using the existing helper functions in the file, test all versions etc) and implement the change there. See e.g. http://source.winehq.org/patches/data/130355 . Yeah, it's a pesky work, but it needs to be done in the long run anyway.

3 3

Re: [PATCH 3/6] d3d8: Allocate WINED3DCAPS on stack.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 13:12, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d8/d3d8_private.h | 106 +++++++++++++++++++++++------------------------ > dlls/d3d8/device.c | 12 ++---- > dlls/d3d8/directx.c | 12 ++---- > 3 files changed, 61 insertions(+), 69 deletions(-) > Ideally we'd get rid of the macro as well.

1 0

Re: [PATCH 2/6] wined3d: Fix swizzle for ld_raw instruction.
by Henri Verbeet 20 Feb '17

20 Feb '17

On 20 February 2017 at 13:12, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -5063,9 +5071,9 @@ static void shader_glsl_ld_raw(const struct wined3d_shader_instruction *ins) > &dst, dst.reg.data_type))) > continue; > > - shader_glsl_swizzle_to_str(src->swizzle, FALSE, write_mask, dst_swizzle); > - shader_addline(buffer, "%s(%s_%s%u, %s / 4)%s);\n", > - function, prefix, resource, src->reg.idx[0].offset, offset.param_str, dst_swizzle); > + swizzle = shader_glsl_swizzle_get_component(src->swizzle, write_mask); That doesn't look right, should that use "i" instead of "write_mask"?

1 0

Re: Reproducible builds
by wylda＠volny.cz 20 Feb '17

20 Feb '17

> Od: Marcus Meissner <marcus(a)jet.franken.de> > > CC: <stefandoesinger(a)gmail.com, wine-devel(a)winehq.org> >On Sun, Feb 19, 2017 at 05:36:30PM +0100, wylda(a)volny.cz wrote: >> > Od: Stefan Dösinger <stefandoesinger(a)gmail.com> >> > >> >Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >> >> Anyway, there are 7 files out of 2750 which _always_ pickup some random >> >> value and use that consistently. Why are these libraries built >> >> inconsitently? Is that intentional? An example is attached. >> > >> >Have you looked at the .o files of those libraries? Finding the .c file >> >that introduces the difference might give some hints to pin down the >> >problem. >> > >> >> Thanks. These "random" value come from: >> >> * olepro_t.res >> * std_ole_v2_t.res >> * wuapi_tlb_t.res >> >> Anyway, all the other folders also have *.res files. Can these 3 be "fixed" >> so that they behave like the rest of dll-folders? Or can i pass some kind >> of parameter or switch? > >std_ole_v2_t.res always comes out the same for me, in 32 and 64bit builds >when I set WIDL_TIME_OVERRIDE="0". > >Same for olepro_t.res > >(current git state) When i do: export WIDL_TIME_OVERRIDE="0" rm dlls/olepro32/olepro_t.res make -k dlls/olepro32 md5sum -b dlls/olepro32/olepro_t.res then i always get different MD5 checksum. Marcus, could you send me your dlls/olepro32/Makefile please? What is your distro?

4 3

winetricks alldlls=builtin update based on wine-2.2
by wylda＠volny.cz 20 Feb '17

20 Feb '17

Hi, in case you find it useful... W.

2 1

Re: [PATCH] winemp3.acm: Fixes compilation for older mpg123 library versions
by Sebastian Lackner 19 Feb '17

19 Feb '17

On 19.02.2017 19:54, Bruno Jesus wrote: > From: Bruno Jesus <00cpxxx(a)gmail.com> > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=42483 > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/winemp3.acm/mpegl3.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/winemp3.acm/mpegl3.c b/dlls/winemp3.acm/mpegl3.c > index 28a1998..100aa49 100644 > --- a/dlls/winemp3.acm/mpegl3.c > +++ b/dlls/winemp3.acm/mpegl3.c > @@ -249,12 +249,14 @@ static LRESULT MPEG3_StreamOpen(PACMDRVSTREAMINSTANCE adsi) > aad->mh = mpg123_new(NULL,&err); > mpg123_open_feed(aad->mh); > > +#ifdef MPG123_IGNORE_INFOFRAME Are you sure this works? On my system it is an enum, not a define. > /* mpg123 may find a XING header in the mp3 and use that information > * to ask for seeks in order to read specific frames in the file. > * We cannot allow that since the caller application is feeding us. > * This fixes problems for mp3 files encoded with LAME (bug 42361) > */ > mpg123_param(aad->mh, MPG123_ADD_FLAGS, MPG123_IGNORE_INFOFRAME, 0); > +#endif > } > /* no encoding yet > else if (adsi->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM && >

2 5

Re: [v2 PATCH 2/2] comctl32/tests: Some tests for property page initialization
by Sebastian Lackner 19 Feb '17

19 Feb '17

On 19.02.2017 19:24, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > Resending, it depends on header change in 1/2. > > dlls/comctl32/tests/propsheet.c | 142 ++++++++++++++++++++++++++++++++++++++++ > include/prsht.h | 1 + > 2 files changed, 143 insertions(+) > > diff --git a/dlls/comctl32/tests/propsheet.c b/dlls/comctl32/tests/propsheet.c > index 7547e793e8..d11fac4bb0 100644 > --- a/dlls/comctl32/tests/propsheet.c > +++ b/dlls/comctl32/tests/propsheet.c > @@ -987,6 +987,147 @@ if (0) > DestroyWindow(hdlg); > } > > +struct custom_proppage > +{ > + union > + { > + PROPSHEETPAGEA pageA; > + PROPSHEETPAGEW pageW; > + } u; > + unsigned int addref_called; > + unsigned int release_called; > +}; > + > +static UINT CALLBACK proppage_callback_a(HWND hwnd, UINT msg, PROPSHEETPAGEA *psp) > +{ > + struct custom_proppage *cpage = (struct custom_proppage *)psp->lParam; > + PROPSHEETPAGEA *psp_orig = &cpage->u.pageA; > + > + ok(hwnd == NULL, "Expected NULL hwnd, got %p\n", hwnd); > + > + ok(psp->lParam && psp->lParam != (LPARAM)psp, "Expected newly allocated page description, got %lx, %p\n", > + psp->lParam, psp); > + ok(psp_orig->pszTitle == psp->pszTitle, "Expected same page title pointer\n"); > + ok(!lstrcmpA(psp_orig->pszTitle, psp->pszTitle), "Expected same page title string\n"); > + > + switch (msg) > + { > + case PSPCB_ADDREF: > + ok(psp->dwSize > PROPSHEETPAGEA_V1_SIZE, "Expected ADDREF for V2+ only, got size %u\n", psp->dwSize); > + cpage->addref_called++; > + break; > + case PSPCB_RELEASE: > + ok(psp->dwSize >= PROPSHEETPAGEA_V1_SIZE, "Unexpected RELEASE, got size %u\n", psp->dwSize); > + cpage->release_called++; > + break; > + default: > + ok(0, "Unexpected message %u\n", msg); > + } > + > + return 1; > +} > + > +static UINT CALLBACK proppage_callback_w(HWND hwnd, UINT msg, PROPSHEETPAGEW *psp) > +{ > + struct custom_proppage *cpage = (struct custom_proppage *)psp->lParam; > + PROPSHEETPAGEW *psp_orig = &cpage->u.pageW; > + > + ok(hwnd == NULL, "Expected NULL hwnd, got %p\n", hwnd); > + ok(psp->lParam && psp->lParam != (LPARAM)psp, "Expected newly allocated page description, got %lx, %p\n", > + psp->lParam, psp); > + ok(psp_orig->pszTitle == psp->pszTitle, "Expected same page title pointer\n"); > + ok(!lstrcmpW(psp_orig->pszTitle, psp->pszTitle), "Expected same page title string\n"); > + > + switch (msg) > + { > + case PSPCB_ADDREF: > + ok(psp->dwSize > PROPSHEETPAGEW_V1_SIZE, "Expected ADDREF for V2+ only, got size %u\n", psp->dwSize); > + cpage->addref_called++; > + break; > + case PSPCB_RELEASE: > + ok(psp->dwSize >= PROPSHEETPAGEW_V1_SIZE, "Unexpected RELEASE, got size %u\n", psp->dwSize); > + cpage->release_called++; > + break; > + default: > + ok(0, "Unexpected message %u\n", msg); > + } > + > + return 1; > +} > + > +static void test_CreatePropertySheetPage(void) > +{ > + static const WCHAR titleW[] = {'T','i','t','l','e',0}; > + struct custom_proppage page; > + HPROPSHEETPAGE hpsp; > + BOOL ret; > + > + memset(&page.u.pageA, 0, sizeof(page.u.pageA)); > + page.u.pageA.dwFlags = PSP_USECALLBACK; > + page.u.pageA.pfnDlgProc = page_dlg_proc_messages; > + page.u.pageA.pfnCallback = proppage_callback_a; > + page.u.pageA.lParam = (LPARAM)&page; > + page.u.pageA.pszTitle = "Title"; > + > + /* Only minimal size validation is performed */ > + for (page.u.pageA.dwSize = PROPSHEETPAGEA_V1_SIZE - 1; page.u.pageA.dwSize <= PROPSHEETPAGEA_V4_SIZE + 1; page.u.pageA.dwSize++) > + { > + page.addref_called = 0; > + hpsp = CreatePropertySheetPageA(&page.u.pageA); > + > + if (page.u.pageA.dwSize < PROPSHEETPAGEA_V1_SIZE) > + todo_wine > + ok(hpsp == NULL, "Expected failure, size %u\n", page.u.pageA.dwSize); > + else > + { > + ok(hpsp != NULL, "Failed to create a page, size %u\n", page.u.pageA.dwSize); > + todo_wine_if(page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) > + ok(page.addref_called == (page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) ? 1 : 0, "Expected ADDREF callback message\n"); > + } > + > + if (hpsp) > + { > + page.release_called = FALSE; It would be better to use 0 when its a counter. > + ret = DestroyPropertySheetPage(hpsp); > + ok(ret, "Failed to destroy a page\n"); > + todo_wine > + ok(page.release_called == 1, "Expected RELEASE callback message\n"); > + } > + } > + > + memset(&page.u.pageW, 0, sizeof(page.u.pageW)); > + page.u.pageW.dwFlags = PSP_USECALLBACK; > + page.u.pageW.pfnDlgProc = page_dlg_proc_messages; > + page.u.pageW.pfnCallback = proppage_callback_w; > + page.u.pageW.lParam = (LPARAM)&page; > + page.u.pageW.pszTitle = titleW; > + > + for (page.u.pageW.dwSize = PROPSHEETPAGEW_V1_SIZE - 1; page.u.pageW.dwSize <= PROPSHEETPAGEW_V4_SIZE + 1; page.u.pageW.dwSize++) > + { > + page.addref_called = 0; > + hpsp = CreatePropertySheetPageW(&page.u.pageW); > + > + if (page.u.pageW.dwSize < PROPSHEETPAGEW_V1_SIZE) > + todo_wine > + ok(hpsp == NULL, "Expected failure, size %u\n", page.u.pageW.dwSize); > + else > + { > + ok(hpsp != NULL, "Failed to create a page, size %u\n", page.u.pageW.dwSize); > + todo_wine_if(page.u.pageA.dwSize > PROPSHEETPAGEA_V1_SIZE) Shouldn't it be pageW here? > + ok(page.addref_called == (page.u.pageW.dwSize > PROPSHEETPAGEW_V1_SIZE) ? 1 : 0, "Expected ADDREF callback message\n"); > + } > + > + if (hpsp) > + { > + page.release_called = 0; > + ret = DestroyPropertySheetPage(hpsp); > + ok(ret, "Failed to destroy a page\n"); > + todo_wine > + ok(page.release_called == 1, "Expected RELEASE callback message\n"); > + } > + } > +} > + > START_TEST(propsheet) > { > test_title(); > @@ -998,4 +1139,5 @@ START_TEST(propsheet) > test_messages(); > test_PSM_ADDPAGE(); > test_PSM_INSERTPAGE(); > + test_CreatePropertySheetPage(); > } > diff --git a/include/prsht.h b/include/prsht.h > index f12f402afc..2b2a3e18f3 100644 > --- a/include/prsht.h > +++ b/include/prsht.h > @@ -293,6 +293,7 @@ DECL_PRSHT_TYPE_AW(LPCPROPSHEETPAGE, LATEST) > #define PSP_USEFUSIONCONTEXT 0x00004000 > #define PSP_COMMANDLINKS 0x00040000 > > +#define PSPCB_ADDREF 0 > #define PSPCB_RELEASE 1 > #define PSPCB_CREATE 2 > > -- 2.11.0 >

2 2

Re: Reproducible builds
by wylda＠volny.cz 19 Feb '17

19 Feb '17

> Od: Stefan Dösinger <stefandoesinger(a)gmail.com> > >Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >> Anyway, there are 7 files out of 2750 which _always_ pickup some random >> value and use that consistently. Why are these libraries built >> inconsitently? Is that intentional? An example is attached. > >Have you looked at the .o files of those libraries? Finding the .c file >that introduces the difference might give some hints to pin down the >problem. > Thanks. These "random" value come from: * olepro_t.res * std_ole_v2_t.res * wuapi_tlb_t.res Anyway, all the other folders also have *.res files. Can these 3 be "fixed" so that they behave like the rest of dll-folders? Or can i pass some kind of parameter or switch? Thank you! W.

2 1

Re: [PATCH 4/5] usp10: Iterate in visual order in GPOS_apply_feature().
by Henri Verbeet 19 Feb '17

19 Feb '17

On 19 February 2017 at 18:16, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > In particular, cursive attachment application depends on previous visual order > glyph offsets. Affects e.g. wordpad with Nastaliq fonts. > Actually, ignore this one for the moment, it depends on a few other patches.

1 0

Reproducible builds
by wylda＠volny.cz 19 Feb '17

19 Feb '17

Hi, i wanted to make a reproducible wine builds, so that striped files produce exactly same checksum. To achieve that, I run make that with: export WIDL_TIME_OVERRIDE="0" Anyway, there are 7 files out of 2750 which _always_ pickup some random value and use that consistently. Why are these libraries built inconsitently? Is that intentional? An example is attached. Thanks for hint. W.

2 1

Re: [PATCH 5/5] d3d9/tests: Allow a higher slop for test_updatetexture.
by Marvin 19 Feb '17

19 Feb '17

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=28758 Your paranoid android. === w8 (32 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test. === w1064 (32 bit visual) === visual.c:7941: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 3/5] d3d9/tests: r500 GPUs only generate point sprite coords on texture coordinate 0.
by Marvin 19 Feb '17

19 Feb '17

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=28756 Your paranoid android. === w1064 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 1/5] ddraw/tests: Rewrite SrcColorKey32BlitTest (v2).
by Marvin 19 Feb '17

19 Feb '17

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=28754 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:10154: Test failed: Got unexpected color 0x00ffffff.

1 0

Re: [PATCH] Some tests for lsa
by Sebastian Lackner 19 Feb '17

19 Feb '17

On 17.02.2017 00:29, Julius Schwartzenberg wrote: > --- > dlls/secur32/tests/Makefile.in | 1 + > dlls/secur32/tests/lsa.c | 206 +++++++++++++++++++++++++++++++++++++++++ > include/ntsecapi.h | 50 ++++++++++ > 3 files changed, 257 insertions(+) > create mode 100644 dlls/secur32/tests/lsa.c Thanks for providing the updated version. Unfortunately there are still various problems left, see the comments below. Patches should have a subject like "component: title". In this case something like "secur32/tests: Add some tests for lsa functions." might be appropriate. > > diff --git a/dlls/secur32/tests/Makefile.in b/dlls/secur32/tests/Makefile.in > index 089d1c3..d9f140a 100644 > --- a/dlls/secur32/tests/Makefile.in > +++ b/dlls/secur32/tests/Makefile.in > @@ -2,6 +2,7 @@ TESTDLL = secur32.dll > IMPORTS = secur32 crypt32 advapi32 ws2_32 > > C_SRCS = \ > + lsa.c \ > main.c \ > negotiate.c \ > ntlm.c \ > diff --git a/dlls/secur32/tests/lsa.c b/dlls/secur32/tests/lsa.c > new file mode 100644 > index 0000000..7668df1 > --- /dev/null > +++ b/dlls/secur32/tests/lsa.c It is preferred to add tests to existing files. You can still add your own copyright of course. Splitting in separate files is usually done when there are sufficient tests. > @@ -0,0 +1,206 @@ > +/* > + * Lsa tests > + * > + * Copyright 2017 Julius Schwartzenberg > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#define SECURITY_WIN32 > + > +#include <stdio.h> > +#include <ntstatus.h> > +#define WIN32_NO_STATUS > +#include <windows.h> > +#include <ntsecapi.h> > + > +#include "wine/test.h" > + > +static void test_LsaConnectUntrusted_null_handle(void) > +{ > + NTSTATUS status; > + > + status = LsaConnectUntrusted(NULL); > + > + todo_wine ok(status == STATUS_ACCESS_VIOLATION || status == RPC_NT_NULL_REF_POINTER, > + "LsaConnectUntrusted(NULL) returned 0x%x\n", status); > +} > + > +static void test_LsaConnectUntrusted_correct_handle(void) There is no need to add a separate function for each testcase. Its better to group them, for example all tests for LsaConnectUntrusted in one function, and so on. > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + There are still some lines (see for example above) with trailing whitespace in your patch. > + status = LsaConnectUntrusted(&lsa_handle); > + > + ok(status == STATUS_SUCCESS, "LsaConnectUntrusted(valid_handle) returned 0x%x\n", status); You should try to avoid leaks and always close handles at the end of each test - in this case with LsaDeregisterLogonProcess(). > +} > + > +static void test_LsaLookupAuthenticationPackage_null_handle(void) > +{ > + NTSTATUS status; > + LSA_STRING package_name; > + ULONG auth_package; > + char name[] = MICROSOFT_KERBEROS_NAME_A; > + package_name.Buffer = name; > + package_name.Length = sizeof(MICROSOFT_KERBEROS_NAME_A) - 1; > + > + status = LsaLookupAuthenticationPackage(NULL, &package_name, &auth_package); > + > + todo_wine ok(status == STATUS_INVALID_HANDLE || status == STATUS_INVALID_CONNECTION, Please always try to document where you observed which status value. Depending on what you consider more correct, you could mark the other value as broken() and a comment which Windows versions are affected. > + "LsaLookupAuthenticationPackage(NULL, \"Kerberos\", ...) returned 0x%x\n", status); > +} > + > +static void test_LsaLookupAuthenticationPackage_correct_handle(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + LSA_STRING package_name; > + ULONG auth_package; > + char name[] = MICROSOFT_KERBEROS_NAME_A; > + package_name.Buffer = name; > + package_name.Length = sizeof(MICROSOFT_KERBEROS_NAME_A) - 1; > + > + LsaConnectUntrusted(&lsa_handle); > + status = LsaLookupAuthenticationPackage(lsa_handle, &package_name, &auth_package); > + LsaDeregisterLogonProcess(&lsa_handle); You should remove the & here. Also, you might want to check the result of each function, even if they are also tested separately. > + > + ok(status == STATUS_SUCCESS, > + "LsaLookupAuthenticationPackage(valid_handle, \"Kerberos\", ...) returned 0x%x\n", status); You might also want to test the auth_package output parameter here. > +} > + > +static void test_LsaLookupAuthenticationPackage_correct_handle_wrong_name(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + LSA_STRING package_name; > + ULONG auth_package; > + package_name.Buffer = "this is probably not a valid authentication package name"; This triggers a compiler warning here: lsa.c:90:25: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] package_name.Buffer = "this is probably not a valid authentication package name"; > + package_name.Length = (USHORT)strlen(package_name.Buffer); The explicit cast to USHORT should not be necessary here. > + > + LsaConnectUntrusted(&lsa_handle); > + status = LsaLookupAuthenticationPackage(lsa_handle, &package_name, &auth_package); > + LsaDeregisterLogonProcess(&lsa_handle); Similar to above, the & is wrong here. > + > + todo_wine ok(status == STATUS_NO_SUCH_PACKAGE, > + "LsaLookupAuthenticationPackage(valid_handle, invalid, ...) returned 0x%x\n", status); > +} > + > +static void test_LsaCallAuthenticationPackage_invalid_handle(void) > +{ > + NTSTATUS status; > + ULONG submit_buffer_length = 0; > + > + VOID *protocol_return_buffer = NULL; > + ULONG *return_buffer_length = 0; > + PNTSTATUS protocol_status = NULL; > + > + status = LsaCallAuthenticationPackage( > + NULL, 0xdeadbeef, NULL, submit_buffer_length, You do not really need a separate variable just to pass 0 to a function. > + protocol_return_buffer, return_buffer_length, protocol_status Those are supposed to be output pointers (&buffer, ...). Passing NULL is probably also fine, but no need for separate variables then. > + ); > + > + todo_wine ok(status == STATUS_INVALID_HANDLE || status == STATUS_INVALID_CONNECTION, > + "LsaCallAuthenticationPackage(NULL, ...) returned 0x%x\n", status); > +} > + > +static void test_LsaCallAuthenticationPackage_invalid_package(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + ULONG submit_buffer_length = 0; > + > + VOID *protocol_return_buffer = NULL; > + ULONG *return_buffer_length = 0; > + PNTSTATUS protocol_status = NULL; > + > + LsaConnectUntrusted(&lsa_handle); > + status = LsaCallAuthenticationPackage( > + lsa_handle, 0xdeadbeef, NULL, submit_buffer_length, > + protocol_return_buffer, return_buffer_length, protocol_status > + ); > + LsaDeregisterLogonProcess(&lsa_handle); > + > + todo_wine ok(status == STATUS_NO_SUCH_PACKAGE, > + "LsaCallAuthenticationPackage(valid_handle, invalid, ...) returned 0x%x\n", status); > +} > + > +static void test_LsaCallAuthenticationPackage_null_submit_buffer(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + LSA_STRING package_name; > + ULONG auth_package; > + ULONG submit_buffer_length = 0; > + VOID *protocol_return_buffer = NULL; > + ULONG *return_buffer_length = 0; > + PNTSTATUS protocol_status = NULL; > + char name[] = MICROSOFT_KERBEROS_NAME_A; > + package_name.Buffer = name; > + package_name.Length = sizeof(MICROSOFT_KERBEROS_NAME_A) - 1; > + > + LsaConnectUntrusted(&lsa_handle); > + LsaLookupAuthenticationPackage(lsa_handle, &package_name, &auth_package); > + status = LsaCallAuthenticationPackage( > + lsa_handle, auth_package, NULL, submit_buffer_length, > + protocol_return_buffer, return_buffer_length, protocol_status > + ); > + LsaDeregisterLogonProcess(&lsa_handle); > + > + todo_wine ok(status == STATUS_INVALID_PARAMETER, > + "LsaCallAuthenticationPackage(...) returned 0x%x\n", status); > +} > + > +static void test_LsaCallAuthenticationPackage_correct_submit_buffer(void) > +{ > + NTSTATUS status; > + HANDLE lsa_handle; > + LSA_STRING package_name; > + ULONG auth_package; > + PKERB_RETRIEVE_TKT_REQUEST protocol_submit_buffer; > + VOID *protocol_return_buffer = NULL; > + ULONG *return_buffer_length = 0; > + PNTSTATUS protocol_status = NULL; > + char name[] = MICROSOFT_KERBEROS_NAME_A; > + package_name.Buffer = name; > + package_name.Length = sizeof(MICROSOFT_KERBEROS_NAME_A) - 1; > + > + LsaConnectUntrusted(&lsa_handle); > + LsaLookupAuthenticationPackage(lsa_handle, &package_name, &auth_package); > + > + protocol_submit_buffer = LocalAlloc(LMEM_ZEROINIT, sizeof(KERB_RETRIEVE_TKT_REQUEST)); > + protocol_submit_buffer->MessageType = KerbRetrieveEncodedTicketMessage; If you use memory allocations, please also free them at the end of the function. Also, please note that it is usually preferred to use HeapAlloc(), unless the API requires to use a very specific one. In this case (fixed size struct) you could also consider allocating the memory directly on the stack. > + > + status = LsaCallAuthenticationPackage( > + lsa_handle, auth_package, protocol_submit_buffer, sizeof(KERB_RETRIEVE_TKT_REQUEST), > + protocol_return_buffer, return_buffer_length, protocol_status > + ); > + LsaDeregisterLogonProcess(&lsa_handle); > + > + ok(status == STATUS_SUCCESS, "LsaCallAuthenticationPackage(...) returned 0x%x\n", status); > +} > + > +START_TEST(lsa) > +{ > + test_LsaConnectUntrusted_null_handle(); > + test_LsaConnectUntrusted_correct_handle(); > + test_LsaLookupAuthenticationPackage_null_handle(); > + test_LsaLookupAuthenticationPackage_correct_handle(); > + test_LsaLookupAuthenticationPackage_correct_handle_wrong_name(); > + test_LsaCallAuthenticationPackage_invalid_handle(); > + test_LsaCallAuthenticationPackage_invalid_package(); > + test_LsaCallAuthenticationPackage_null_submit_buffer(); > + test_LsaCallAuthenticationPackage_correct_submit_buffer(); > +} > diff --git a/include/ntsecapi.h b/include/ntsecapi.h > index 2bb3d31..e8a2af4 100644 > --- a/include/ntsecapi.h > +++ b/include/ntsecapi.h > @@ -387,6 +387,56 @@ NTSTATUS WINAPI LsaSetTrustedDomainInformation(LSA_HANDLE,PSID,TRUSTED_INFORMATI > NTSTATUS WINAPI LsaStorePrivateData(LSA_HANDLE,PLSA_UNICODE_STRING,PLSA_UNICODE_STRING); > NTSTATUS WINAPI LsaUnregisterPolicyChangeNotification(POLICY_NOTIFICATION_INFORMATION_CLASS,HANDLE); > > +#ifndef MICROSOFT_KERBEROS_NAME_A > + > +#define MICROSOFT_KERBEROS_NAME_A "Kerberos" > +#define MICROSOFT_KERBEROS_NAME_W (const WCHAR []){'K','e','r','b','e','r','o','s',0} > +#define MICROSOFT_KERBEROS_NAME MICROSOFT_KERBEROS_NAME_W > +#endif > + > +typedef enum _KERB_PROTOCOL_MESSAGE_TYPE { > + KerbDebugRequestMessage = 0, You are using tabs here, but the file seems to use spaces. > + KerbQueryTicketCacheMessage, > + KerbChangeMachinePasswordMessage, > + KerbVerifyPacMessage, > + KerbRetrieveTicketMessage, > + KerbUpdateAddressesMessage, > + KerbPurgeTicketCacheMessage, > + KerbChangePasswordMessage, > + KerbRetrieveEncodedTicketMessage, > + KerbDecryptDataMessage, > + KerbAddBindingCacheEntryMessage, > + KerbSetPasswordMessage, > + KerbSetPasswordExMessage, > + KerbVerifyCredentialsMessage, > + KerbQueryTicketCacheExMessage, > + KerbPurgeTicketCacheExMessage, > + KerbRefreshSmartcardCredentialsMessage, > + KerbAddExtraCredentialsMessage, > + KerbQuerySupplementalCredentialsMessage, > + KerbTransferCredentialsMessage, > + KerbQueryTicketCacheEx2Message > +} KERB_PROTOCOL_MESSAGE_TYPE,*PKERB_PROTOCOL_MESSAGE_TYPE; > + > +#ifndef __SECHANDLE_DEFINED__ > + typedef struct _SecHandle { > + ULONG_PTR dwLower; > + ULONG_PTR dwUpper; > + } SecHandle,*PSecHandle; > + > +#define __SECHANDLE_DEFINED__ > +#endif > + > +typedef struct _KERB_RETRIEVE_TKT_REQUEST { > + KERB_PROTOCOL_MESSAGE_TYPE MessageType; > + LUID LogonId; > + UNICODE_STRING TargetName; > + ULONG TicketFlags; > + ULONG CacheOptions; > + LONG EncryptionType; > + SecHandle CredentialsHandle; > +} KERB_RETRIEVE_TKT_REQUEST,*PKERB_RETRIEVE_TKT_REQUEST; > + > #ifdef __cplusplus > } /* extern "C" */ > #endif /* defined(__cplusplus) */ > -- 1.9.1 >

2 1

[GSoC 2017]
by Saksham Bassi 18 Feb '17

18 Feb '17

Hello, I am Saksham. I am pursuing Bachelors of Engineering (Information Technology) at PICT, Pune. I would like to start contributing and GSoC can be stepping stone towards it. I am new to open source community. I went through the GSoC site. I really liked previous year projects and would love to be a part of GSoC this year. I would like to familiarise myself with the code. How can I start contributing?

3 2

Wine has been accepted into Outreachy (May-August 2017)
by Austin English 18 Feb '17

18 Feb '17

For more info, please see: https://wiki.gnome.org/Outreachy/2017/MayAugust https://wiki.winehq.org/Outreachy I am the administration coordinator, so please contact me with any questions. Please forward this to any students you know that may be eligible. -- -Austin GPG: 14FB D7EA A041 937B

3 4

Re: wine/test.h: Identify test result lines printed by child processes.
by Alexandre Julliard 18 Feb '17

18 Feb '17

Francois Gouget <fgouget(a)codeweavers.com> writes: > Currently the child process result lines are indistinguishable from the > main process one. This makes it impossible to automatically detect > when a process exits abruptly, i.e. without printing a result line, > if it has run a subprocess. By making the subprocess result lines > different analysis tools will detect that the main result line is > missing and automatically consider that the main process crashed, > thus marking the test as failed. > > Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> > --- > > This should fix bug 32354: > https://bugs.winehq.org/show_bug.cgi?id=32354 I don't think the test framework should be modifying the environment in all the tests. It already breaks some things: ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so environ && touch environ.ok environ.c:198: Test failed: Expected environment block pointer element to be non-NULL wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed2a986 (thread 0074), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH v5] compobj.dll16: Implement CoGetClassObject16().
by Sebastian Lackner 17 Feb '17

17 Feb '17

On 17.02.2017 22:32, Zebediah Figura wrote: > + SEGPTR seg_rclsid = MapLS(rclsid); > + SEGPTR seg_riid = MapLS(riid); > + SEGPTR seg_ppv = MapLS(ppv); You should also unmap them in case of an error. (Or alternatively, you could change the specfile, and pass through the SEGPTRs).

1 0

Re: [PATCH 2/5] wined3d: Handle CS op emission from CS op handlers.
by Sebastian Lackner 17 Feb '17

17 Feb '17

On 17.02.2017 14:08, Henri Verbeet wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/wined3d/cs.c | 37 +++++++++++++++++++++++++++++-------- > dlls/wined3d/wined3d_private.h | 2 +- > 2 files changed, 30 insertions(+), 9 deletions(-) > > diff --git a/dlls/wined3d/cs.c b/dlls/wined3d/cs.c > index 55706cd..10905c0 100644 > --- a/dlls/wined3d/cs.c > +++ b/dlls/wined3d/cs.c > @@ -1576,26 +1576,47 @@ static void (* const wined3d_cs_op_handlers[])(struct wined3d_cs *cs, const void > > static void *wined3d_cs_st_require_space(struct wined3d_cs *cs, size_t size) > { > - if (size > cs->data_size) > + if (size > (cs->data_size - cs->end)) > { > + size_t new_size; > void *new_data; > > - size = max( size, cs->data_size * 2 ); > - if (!(new_data = HeapReAlloc(GetProcessHeap(), 0, cs->data, size))) > + new_size = max(size, cs->data_size * 2); > + if (!cs->end) > + new_data = HeapReAlloc(GetProcessHeap(), 0, cs->data, new_size); > + else > + new_data = HeapAlloc(GetProcessHeap(), 0, new_size); > + if (!new_data) > return NULL; > > - cs->data_size = size; > + cs->data_size = new_size; > + cs->start = cs->end = 0; > cs->data = new_data; > } > > - return cs->data; > + cs->end += size; > + > + return (BYTE *)cs->data + cs->start; > } > > static void wined3d_cs_st_submit(struct wined3d_cs *cs) > { > - enum wined3d_cs_op opcode = *(const enum wined3d_cs_op *)cs->data; > - > - wined3d_cs_op_handlers[opcode](cs, cs->data); > + enum wined3d_cs_op opcode; > + size_t start; > + BYTE *data; > + > + data = cs->data; > + start = cs->start; > + cs->start = cs->end; > + opcode = *(const enum wined3d_cs_op *)&data[start]; > + wined3d_cs_op_handlers[opcode](cs, &data[start]); > + if (!start) > + { > + if (cs->data != data) > + HeapFree(GetProcessHeap(), 0, data); > + else > + cs->start = cs->end = 0; > + } Is it intentional that you are not updating cs->start and cs->end in any other situation? This might lead to unnecessary memory allocations because start / end is not set back before the block is fully empty. Here an example what happens if wined3d_device_delete_opengl_contexts_cs is called with lots of resources (with this patch http://ix.io/dP5): fixme:d3d:wined3d_device_delete_opengl_contexts_cs -> unloading resources fixme:d3d:wined3d_cs_st_require_space start = 12 fixme:d3d:wined3d_cs_st_require_space start = 20 fixme:d3d:wined3d_cs_st_require_space start = 28 [...] fixme:d3d:wined3d_cs_st_require_space start = 4068 fixme:d3d:wined3d_cs_st_require_space start = 4076 fixme:d3d:wined3d_cs_st_require_space start = 4084 fixme:d3d:wined3d_cs_st_require_space allocated new block 0x579fdb70 fixme:d3d:wined3d_cs_st_require_space start = 0 fixme:d3d:wined3d_cs_st_require_space start = 0 fixme:d3d:wined3d_cs_st_require_space start = 0 [..] In this case, with the buffer basically almost empty, there shouldn't be any need to do memory allocations. > } > > static void wined3d_cs_st_push_constants(struct wined3d_cs *cs, enum wined3d_push_constants p, > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 54adf26..49fba06 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -3170,7 +3170,7 @@ struct wined3d_cs > struct wined3d_fb_state fb; > struct wined3d_state state; > > - size_t data_size; > + size_t data_size, start, end; > void *data; > }; > >

3 5

Re: [PATCH v4 1/5] compobj.dll16: Implement CoLoadLibrary16 and CoFreeLibrary16.
by Alexandre Julliard 17 Feb '17

17 Feb '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > +/* --- loaded dll list implementation */ > +struct open_dll > +{ > + HMODULE16 library; > + FARPROC16 DllCanUnloadNow; > + struct list entry; > +}; > + > +static struct list open_dll_list = LIST_INIT(open_dll_list); > + > +static HRESULT dll_list_add(LPCSTR library_name, struct open_dll **ret) > +{ > + struct open_dll *dll; > + HMODULE16 library; > + FARPROC16 DllCanUnloadNow; > + > + library = LoadLibrary16(library_name); > + if (!library) > + { > + ERR("couldn't load in-process dll %s\n", debugstr_a(library_name)); > + return E_ACCESSDENIED; /* FIXME: or should this be CO_E_DLLNOTFOUND? */ > + } > + > + DllCanUnloadNow = GetProcAddress16(library, "DllCanUnloadNow"); > + /* Note: failing to find DllCanUnloadNow is not a failure */ > + > + dll = HeapAlloc(GetProcessHeap(), 0, sizeof(struct open_dll)); > + dll->library = library; > + dll->DllCanUnloadNow = DllCanUnloadNow; > + list_add_tail(&open_dll_list, &dll->entry); > + *ret = dll; > + TRACE("added new loaded dll %d\n", dll->library); > + > + return S_OK; > +} I'm not sure we even need the list at all. It would be needed for CoFreeAllLibraries16, but it's not clear that this is a useful function. > +void WINAPI CoFreeLibrary16( > + HINSTANCE16 hInst) > +{ > + struct open_dll *dll; > + > + LIST_FOR_EACH_ENTRY(dll, &open_dll_list, struct open_dll, entry) > + { > + if(hInst == dll->library) > + dll_list_free(dll); > + } That's freeing all the loaded instances, I don't think that's what you want. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] programs/regedit: Sort each of top level branches separately
by Hugh McMaster 17 Feb '17

17 Feb '17

On Friday, 17 February 2017 9:42 AM, Nikolay Sivov wrote: > --- a/programs/regedit/treeview.c > +++ b/programs/regedit/treeview.c > @@ -477,12 +477,12 @@ BOOL RefreshTreeView(HWND hwndTV) > hItem = (HTREEITEM)SendMessageW(hwndTV, TVM_GETNEXTITEM, TVGN_CHILD, (LPARAM)hRoot); > while (hItem) { > RefreshTreeItem(hwndTV, hItem); > + SendMessageW(hwndTV, TVM_SORTCHILDREN, TRUE, (LPARAM)hItem); > hItem = (HTREEITEM)SendMessageW(hwndTV, TVM_GETNEXTITEM, TVGN_NEXT, (LPARAM)hItem); > } > > SendMessageW(hwndTV, WM_SETREDRAW, TRUE, 0); > InvalidateRect(hwndTV, NULL, FALSE); > - SendMessageW(hwndTV, TVM_SORTCHILDREN, TRUE, (LPARAM)hSelectedItem); > SetCursor(hcursorOld); This doesn't seem to work. None of the treeview nodes are sorted when you click Refresh or press F5, but immediate children were sorted before this patch. Can you please take another look? This is probably due to an incomplete TREEVIEW_SortChildren() function in comctl32. case TVM_SORTCHILDREN: return TREEVIEW_SortChildren(infoPtr, lParam); Note that we ignore the wParam, which MSDN says is a "Value that specifies whether the sorting is recursive. Set wParam to TRUE to sort all levels of child items below the parent item. Otherwise, only the parent's immediate children are sorted. " -- Hugh McMaster

2 1

Re: ntoskrnl.exe: add KeAcquireInStackQueuedSpinLock stub (try 2)
by Sebastian Lackner 17 Feb '17

17 Feb '17

On 09.02.2017 23:51, Austin English wrote: > CC: Sebastian Lackner <sebastian(a)fds-team.de> > > https://bugs.winehq.org/show_bug.cgi?id=41472 > > -- -Austin GPG: 14FB D7EA A041 937B > > > 0001-ntoskrnl.exe-add-KeAcquireInStackQueuedSpinLock-stub.patch > > > From ee6a34f4a0e558de27aa5d9f3c81a8ad45c24dbb Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Mon, 6 Feb 2017 17:11:15 -0600 > Subject: [PATCH] ntoskrnl.exe: add KeAcquireInStackQueuedSpinLock stub (try 2) > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/hal/hal.spec | 2 +- > dlls/ntoskrnl.exe/ntoskrnl.c | 13 +++++++++++++ > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 1 + > include/ddk/wdm.h | 10 ++++++++++ > tools/make_specfiles | 4 ++++ > 5 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/dlls/hal/hal.spec b/dlls/hal/hal.spec > index bd6bc35..f441ac5 100644 > --- a/dlls/hal/hal.spec > +++ b/dlls/hal/hal.spec > @@ -4,7 +4,7 @@ > @ stub HalClearSoftwareInterrupt > @ stub HalRequestSoftwareInterrupt > @ stub HalSystemVectorDispatchEntry > -@ stub KeAcquireInStackQueuedSpinLock > +@ stdcall -norelay KeAcquireInStackQueuedSpinLock(ptr ptr) ntoskrnl.exe.KeAcquireInStackQueuedSpinLock > @ stub KeAcquireInStackQueuedSpinLockRaiseToSynch > @ stub KeAcquireQueuedSpinLock > @ stub KeAcquireQueuedSpinLockRaiseToSynch > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index 06320d0..b8f6a25 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -3188,3 +3188,16 @@ VOID WINAPI KeClearEvent(PRKEVENT event) > { > FIXME("stub: %p\n", event); > } > + > +/*********************************************************************** > + * KeAcquireInStackQueuedSpinLock (NTOSKRNL.EXE.@) > + */ > +#ifdef DEFINE_FASTCALL2_ENTRYPOINT > +DEFINE_FASTCALL2_ENTRYPOINT( KeAcquireInStackQueuedSpinLock ) > +void WINAPI __regs_KeAcquireInStackQueuedSpinLock(KSPIN_LOCK *spinlock, KLOCK_QUEUE_HANDLE *handle) > +#else > +void WINAPI KeAcquireInStackQueuedSpinLock(KSPIN_LOCK *spinlock, KLOCK_QUEUE_HANDLE *handle) > +#endif > +{ > + FIXME( "stub: %p %p\n", spinlock, handle); > +} > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > index efa69fe..08644fb 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -41,6 +41,7 @@ > @ stub IoWritePartitionTable > @ stdcall -norelay IofCallDriver(ptr ptr) > @ stdcall -norelay IofCompleteRequest(ptr long) > +@ stdcall -norelay KeAcquireInStackQueuedSpinLock(ptr ptr) Based on the information I have found, the location where this function is implemented differs between 32-bit and 64-bit Windows versions. On 32-bit its only in HAL, on 64-bit its only in ntoskrnl. Unfortunately I'm not sure what would be the best way to solve this. We probably don't want to implement it twice, but what would be the preferred location? Some shared file, or is it fine to keep the ntoskrnl export on 32-bit? > @ stub KeAcquireInStackQueuedSpinLockAtDpcLevel > @ stub KeReleaseInStackQueuedSpinLockFromDpcLevel > @ stub KeSetTimeUpdateNotifyRoutine > diff --git a/include/ddk/wdm.h b/include/ddk/wdm.h > index 4c696f7..3e1a8a7 100644 > --- a/include/ddk/wdm.h > +++ b/include/ddk/wdm.h > @@ -1210,6 +1210,16 @@ typedef struct _CALLBACK_OBJECT > UCHAR reserved[3]; > } CALLBACK_OBJECT, *PCALLBACK_OBJECT; > > +typedef struct _KSPIN_LOCK_QUEUE { > + struct _KSPIN_LOCK_QUEUE volatile *Next; > + volatile PKSPIN_LOCK Lock; Does this really match your Windows header files? In my Win10 header files the volatile is at a different place in both lines above. > +} KSPIN_LOCK_QUEUE, *PKSPIN_LOCK_QUEUE; > + > +typedef struct _KLOCK_QUEUE_HANDLE { > + KSPIN_LOCK_QUEUE LockQueue; > + KIRQL OldIrql; > +} KLOCK_QUEUE_HANDLE, *PKLOCK_QUEUE_HANDLE; > + > typedef NTSTATUS (NTAPI EX_CALLBACK_FUNCTION)(void *CallbackContext, void *Argument1, void *Argument2); > typedef EX_CALLBACK_FUNCTION *PEX_CALLBACK_FUNCTION; > > diff --git a/tools/make_specfiles b/tools/make_specfiles > index 1e2400e..505bdf1 100755 > --- a/tools/make_specfiles > +++ b/tools/make_specfiles > @@ -338,6 +338,10 @@ my @dll_groups = > "bcrypt", > "ncrypt", > ], > + [ > + "ntoskrnl.exe", > + "hal", > + ] > ); > > my $update_flags = 0; > -- 2.10.2 >

2 1

Re: [PATCH] dpnet: IDirectPlay8ThreadPool is a singleton interface.
by Sebastian Lackner 17 Feb '17

17 Feb '17

On 17.02.2017 07:43, Alistair Leslie-Hughes wrote: > - ok(pool1 != pool2, "same pointer returned.\n"); > + todo_wine ok(pool1 != pool2, "same pointer returned.\n"); Well, this test shows that its not implemented as a singleton interface on Windows. Just because part of the state is global doesn't necessarily mean you don't need any interface specific data.

2 1

Re: wined3d: Call wined3d_cs_emit_unload_resource outside of command stream.
by Henri Verbeet 17 Feb '17

17 Feb '17

On 17 February 2017 at 03:47, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/wined3d/device.c | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > Why would you want to do that?

2 2

Re: wined3d: Remove duplicate assignment of NULL to map_ptr in wined3d_buffer_map.
by Henri Verbeet 17 Feb '17

17 Feb '17

On 17 February 2017 at 04:43, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > BTW: Is someone currently working on wined3d_buffer_map? To me it looks like > there are multiple issues related to location handling in there. > The code certainly has issues, at least in part that's because it mostly predates the current resource location management scheme. > * For mappings without !(flags & WINED3D_MAP_READONLY), shouldn't the code invalidate > the sysmem location, to force a download when it is required later? > If you're referring to the case I think you're referring to, no, because WINED3D_BUFFER_PIN_SYSMEM isn't set and the system memory location has been evicted. > * In the "Falling back to doublebuffered operation." case with > !(flags & WINED3D_MAP_READONLY) the buffer location is never invalidated, which > means no upload will happen. For testing purposes, this can be triggered by > replacing the if conditions and running d3d9 visual tests. Adding something like: > buffer->locations &= ~WINED3D_LOCATION_BUFFER; fixes it (using a function would > add the modified range twice). > That path should only be reachable for read-only maps, in which case there's nothing to upload. The general issue that the code is overly complicated and hard to reason about is certainly true though.

1 0

Re: [PATCH v2 5/5] crypt32: Fix wrong Base64 trailer WCHAR constants.
by Alexandre Julliard 16 Feb '17

16 Feb '17

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > The tests simply check that W and A give the same results. > That wouldn't always happen without this fix. > > v2: Fix buffer overflow. > Signed-off-by: Lauri Kenttä <lauri.kentta(a)gmail.com> It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M crypt32.dll -p crypt32_test.exe.so base64 && touch base64.ok base64.c:315: Test failed: base64 "V=" len 0: W and A differ base64.c:315: Test failed: base64 "VV=" len 0: W and A differ base64.c:315: Test failed: base64 "V==" len 0: W and A differ base64.c:315: Test failed: base64 "V=" len 2: W and A differ base64.c:315: Test failed: base64 "VV=" len 3: W and A differ base64.c:315: Test failed: base64 "V==" len 3: W and A differ Makefile:188: recipe for target 'base64.ok' failed make[1]: *** [base64.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ddraw/tests: Rewrite SrcColorKey32BlitTest.
by Marvin 16 Feb '17

16 Feb '17

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=28707 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w864 (32 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w1064 (32 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w864 (64 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w1064 (64 bit ddraw7) === ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw7.c:12644: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw7.c:12790: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw7.c:12807: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw7.c:12847: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw7.c:12878: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw7.c:12900: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw7.c:12980: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w8 (32 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w864 (32 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w1064 (32 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w864 (64 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w1064 (64 bit ddraw4) === ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw4.c:12971: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw4.c:13117: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw4.c:13134: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw4.c:13174: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw4.c:13205: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw4.c:13227: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw4.c:13307: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. === w8 (32 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w864 (32 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w1064 (32 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w864 (64 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w1064 (64 bit ddraw2) === ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw2.c:11580: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw2.c:11726: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw2.c:11743: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw2.c:11783: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw2.c:11814: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw2.c:11836: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw2.c:11916: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w8 (32 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w864 (32 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w1064 (32 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w864 (64 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. === w1064 (64 bit ddraw1) === ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=0. ddraw1.c:10249: Test failed: Destination data after blitting is ff010203 ff010203 cccccccc cccccccc, i=1. ddraw1.c:10395: Test failed: Got unexpected content 55555555 ff0000aa ffff0000 ff00ff00 ff001100 ff110000. ddraw1.c:10412: Test failed: Got unexpected content ff0000ff ff0000aa ffff0000 ff00ff00 ff001100 55555555. ddraw1.c:10451: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000. ddraw1.c:10482: Test failed: Got unexpected content ff0000ff ff0000aa 00001100 00001100 000000aa 000000aa. ddraw1.c:10504: Test failed: Got unexpected content 00ff0000 00ff0000 ffff0000 ff00ff00 000000aa 000000aa. ddraw1.c:10584: Test failed: Got unexpected content 00ff0000 00ff0000 00001100 00001100 ff001100 ff110000.

1 0

Re: [PATCH 2/3] comctl32/propsheet: Implement PSM_SETHEADERTITLE
by Alexandre Julliard 16 Feb '17

16 Feb '17

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > case PSM_SETHEADERTITLEW: > - PROPSHEET_SetHeaderTitleW(hwnd, (int)wParam, (LPCWSTR)lParam); > - return TRUE; > + PROPSHEET_SetHeaderTitleW(hwnd, wParam, (LPCWSTR)lParam); > + return FALSE; > > case PSM_SETHEADERTITLEA: > - PROPSHEET_SetHeaderTitleA(hwnd, (int)wParam, (LPCSTR)lParam); > - return TRUE; > + PROPSHEET_SetHeaderTitleA(hwnd, wParam, (LPCSTR)lParam); > + return FALSE; Not that it makes much difference, but is there a reason for changing these to returning FALSE? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH v2] winedevice: Use WINE_RB_FOR_EACH_ENTRY_DESTRUCTOR to free drivers in async_shutdown_drivers.
by Sebastian Lackner 16 Feb '17

16 Feb '17

On 15.02.2017 17:07, Jacek Caban wrote: > + wine_rb_clear( &wine_drivers, NULL, NULL ); This fixes the issue, but passing a non-NULL callback to clear() would crash because the rbtree is temporarily corrupted. In all other places clear() is called to clear the content, not as a replacement for init(). Wouldn't it make more sense to integrate the clearing directly into the macro somehow, if its only used for destructors? You could for example reset ->root immediately after initializating the cursor. Otherwise, if the macro is supposed to be a general purpose postorder iterator, it would make more sense to use a different name.

3 5

Re: [v5 1/2] ntdll: Implement FileIdInformation class support in NtQueryInformationFile.
by Sebastian Lackner 16 Feb '17

16 Feb '17

On 14.02.2017 19:21, Jonathan Doron wrote: > Signed-off-by: Jonathan Doron <jond(a)wizery.com> > --- > dlls/ntdll/file.c | 29 ++++++++++++++++++++++++- > dlls/ntdll/tests/file.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++ > include/winternl.h | 9 ++++++++ > 3 files changed, 93 insertions(+), 1 deletion(-) I have just sent a series (patch 130340 - 130343) based on your work which implements initial support for FileIdInformation. There are some tasks left, however I believe it is easier for all of us, when the basic stuff is already upstream, and we only have to discuss about the missing pieces. ;) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index a6c1098..182db56 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2377,7 +2377,7 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > 0, /* FileRenameInformationBypassAccessCheck */ > 0, /* FileLinkInformationBypassAccessCheck */ > 0, /* FileVolumeNameInformation */ > - 0, /* FileIdInformation */ > + sizeof(FILE_ID_INFORMATION), /* FileIdInformation */ > 0, /* FileIdExtdDirectoryInformation */ > 0, /* FileReplaceCompletionInformation */ > 0, /* FileHardLinkFullIdInformation */ > @@ -2619,6 +2619,33 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > } > } > break; > + case FileIdInformation: > + { > + if (fstat(fd, &st) == -1) > + { > + io->u.Status = FILE_GetNtStatus(); > + } > + else > + { > + FILE_ID_INFORMATION *info = ptr; > +#if defined(HAVE_FSTATFS) > + struct statfs volstats; > + if (fstatfs(fd, &volstats) == -1) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + > + memcpy(&info->VolumeSerialNumber, > + &volstats.f_fsid, > + min(sizeof(info->VolumeSerialNumber), sizeof(volstats.f_fsid))); > +#else > + memset(&info->VolumeSerialNumber, 0, sizeof(info->VolumeSerialNumber)); > +#endif It might be fine to implement the volume serial number like that, but I believe it is even more important that all functions return the same information. If its required for your application, please also update kernel32 and other places where it is returned. > + ((LARGE_INTEGER *)&info->FileId)->QuadPart = st.st_ino; > + } > + } > + break; > default: > FIXME("Unsupported class (%d)\n", class); > io->u.Status = STATUS_NOT_IMPLEMENTED; > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index 57d7df9..926b8f8 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -1444,6 +1444,61 @@ static void test_file_basic_information(void) > CloseHandle( h ); > } > > +static void test_file_id_information(void) > +{ > + IO_STATUS_BLOCK io; > + FILE_ID_INFORMATION fid1, fid2; > + HANDLE h = INVALID_HANDLE_VALUE; > + NTSTATUS res; > + char path[MAX_PATH], buffer[MAX_PATH]; > + > + GetTempPathA(MAX_PATH, path); > + GetTempFileNameA(path, "foo", 0, buffer); > + > + h = CreateFileA(buffer, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0); > + ok(h != INVALID_HANDLE_VALUE, "CreateFile error %d\n", GetLastError()); > + > + /* Query the temp file unique id */ > + memset(&fid1, 0, sizeof(fid1)); The memsets with same value hide that some bytes of FileId are uninitialized. > + res = pNtQueryInformationFile(h, &io, &fid1, sizeof(fid1), FileIdInformation); > + if (res == STATUS_NOT_IMPLEMENTED || res == STATUS_INVALID_INFO_CLASS) > + { > + CloseHandle(h); > + DeleteFileA(buffer); > + win_skip("FileIdInformation not supported\n"); > + return; > + } > + > + ok(res == STATUS_SUCCESS, "can't get fid1, res %x\n", res); > + > + CloseHandle(h); > + > + h = CreateFileA(buffer, GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); > + ok(h != INVALID_HANDLE_VALUE, "CreateFile error %d\n", GetLastError()); > + > + memset(&fid2, 0, sizeof(fid2)); > + res = pNtQueryInformationFile(h, &io, &fid2, sizeof(fid2), FileIdInformation); > + ok(res == STATUS_SUCCESS, "can't get fid2, res %x\n", res); > + > + /* Verify we got the same unique id for the file */ > + ok(memcmp(&fid1, &fid2, sizeof(fid1)) == 0, "file id is not unique\n"); > + > + CloseHandle(h); > + > + h = create_temp_file(0); > + ok(h != NULL, "error creating new file %d\n", GetLastError()); > + > + memset(&fid2, 0, sizeof(fid2)); > + res = pNtQueryInformationFile(h, &io, &fid2, sizeof(fid2), FileIdInformation); > + ok(res == STATUS_SUCCESS, "can't get new fid2, res %x\n", res); > + > + /* Verify we got the different unique id for the new file */ > + ok(memcmp(&fid1, &fid2, sizeof(fid1)) != 0, "file id is not unique\n"); > + Some of those patches can probably be added again if you want. For now I have only added a test to compare the result with GetFileInformationByHandle. > + CloseHandle(h); > + DeleteFileA(buffer); > +} > + > static void test_file_all_information(void) > { > IO_STATUS_BLOCK io; > @@ -4262,4 +4317,5 @@ START_TEST(file) > test_file_disposition_information(); > test_query_volume_information_file(); > test_query_attribute_information_file(); > + test_file_id_information(); > } > diff --git a/include/winternl.h b/include/winternl.h > index 891b6a7..2f2ea86 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -571,6 +571,15 @@ typedef struct _FILE_INTERNAL_INFORMATION { > LARGE_INTEGER IndexNumber; > } FILE_INTERNAL_INFORMATION, *PFILE_INTERNAL_INFORMATION; > > +typedef struct _FILE_ID_128 { > + UCHAR Identifier[16]; > +} FILE_ID_128, *PFILE_ID_128; > + > +typedef struct _FILE_ID_INFORMATION { > + ULONGLONG VolumeSerialNumber; > + FILE_ID_128 FileId; > +} FILE_ID_INFORMATION, *PFILE_ID_INFORMATION; > + > typedef struct _FILE_EA_INFORMATION { > ULONG EaSize; > } FILE_EA_INFORMATION, *PFILE_EA_INFORMATION; >

1 0

Re: [PATCH v2 8/9] ddraw/tests: Test ddraw7 CreateSurface with a null descriptor.
by Henri Verbeet 16 Feb '17

16 Feb '17

On 16 February 2017 at 04:46, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/ddraw/tests/ddraw7.c | 5 +++++ > 1 file changed, 5 insertions(+) > Actually, most of this is already covered by both CreateSurfaceBadCapsSizeTest() and create_surface_test() in dsurface.c. Could you cleanup and merge those instead?

1 0

Re: [PATCH v2 8/9] ddraw/tests: Test ddraw7 CreateSurface with a null descriptor.
by Marvin 16 Feb '17

16 Feb '17

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=28673 Your paranoid android. === w864 (32 bit ddraw7) === ddraw7.c:3767: Test failed: Lit quad with light has color 0x00000000. ddraw7.c:3767: Test failed: Lit quad with singular world matrix has color 0x00000000. ddraw7.c:3767: Test failed: Lit quad with transformation matrix has color 0x00000000.

1 0

wine-1.8.7-rc2 Available
by Michael Stefaniuc 15 Feb '17

15 Feb '17

Hello guys, wine-1.8.7-rc2 is now available, including the tag: https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Changes to rc1: - Removed commit "winex11.drv: Added ThreadDetach entry point and use it instead of DllMain." as it needs a dependency not suitable for Stable. - Added Turkish translations. Thanks to Can Taşan for dealing with the fallout of msgmerge'ing the tr.po from wine-2.0. bye michael

1 0

Re: [PATCH 3/7] ddraw: Fix IDirectDraw_CreateSurface's invalid descriptor error code.
by Henri Verbeet 15 Feb '17

15 Feb '17

On 15 February 2017 at 07:53, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > @@ -3000,7 +3000,7 @@ static HRESULT WINAPI ddraw1_CreateSurface(IDirectDraw *iface, > { > WARN("Application supplied invalid surface descriptor\n"); > wined3d_mutex_unlock(); > - return DDERR_INVALIDPARAMS; > + return E_INVALIDARG; Did you verify the test fails without this change? How is DDERR_INVALIDPARAMS defined?

3 2

Re: winedevice: Use WINE_RB_FOR_EACH_ENTRY_DESTRUCTOR to free drivers in async_shutdown_drivers.
by Sebastian Lackner 15 Feb '17

15 Feb '17

On 15.02.2017 16:47, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > programs/winedevice/device.c | 30 +++++++++++++++--------------- > 1 file changed, 15 insertions(+), 15 deletions(-) This isn't really a noop, the previous code also cleared tree->root.

2 1

Re: [PATCH 13/14] rbtree.h: Added WINE_RB_FOR_EACH_DESTRUCTOR and WINE_RB_FOR_EACH_ENTRY_DESTRUCTOR helpers for implementing tree destructors.
by Matteo Bruni 15 Feb '17

15 Feb '17

2017-02-13 21:12 GMT+01:00 Jacek Caban <jacek(a)codeweavers.com>: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > include/wine/rbtree.h | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) These sound like the _SAFE variants of our list implementation. Any reason not to use the same naming here?

2 3

Re: [PATCH 1/7] ddraw/tests: Test IDirectDraw4_CreateSurface without cooperative level.
by Henri Verbeet 15 Feb '17

15 Feb '17

On 15 February 2017 at 07:53, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/ddraw/tests/ddraw4.c | 6 ++++++ > 1 file changed, 6 insertions(+) > I think this belongs in test_coop_level_surf_create().

1 0

Re: [PATCH 2/8] wined3d: Honor buffer ranges for shader resource views.
by Matteo Bruni 15 Feb '17

15 Feb '17

2017-02-14 13:15 GMT+01:00 Józef Kucia <jkucia(a)codeweavers.com>: > > context_bind_texture(context, GL_TEXTURE_BUFFER, view->name); > - GL_EXTCALL(glTexBuffer(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object)); > + if (gl_info->supported[ARB_TEXTURE_BUFFER_RANGE]) > + { > + GL_EXTCALL(glTexBufferRange(GL_TEXTURE_BUFFER, view_format->glInternal, > + buffer->buffer_object, offset, size)); > + } > + else > + { > + if (!offset || size != buffer->resource.size) > + FIXME("OpenGL implementation does not support ARB_texture_buffer_range.\n"); > + GL_EXTCALL(glTexBuffer(GL_TEXTURE_BUFFER, view_format->glInternal, buffer->buffer_object)); > + } I think you want the FIXME if offset is non-zero.

2 1

Re: wine.inf: Add Dynamic DST/{First,Last}Entry registry keys
by Piotr Caban 15 Feb '17

15 Feb '17

On 02/14/17 22:54, Sebastian Lackner wrote: > Is it actually used by apps? If yes, I hope it doesn't cause problems > that we store them in "sparse" format (sometimes years are missing inbetween, > when they match the information in the parent registry key). It's used by mono. Without this patch it crashes in some timezone related functions. I've grepped mono source and the "Dynamic DST" keys are used in 3 places. None of them is correctly handling the missing entries (one returns error on missing entry, others define adjustment rules only for specified years). Thanks, Piotr

1 0

Re: [PATCH 6/7] ddraw: Fix IDirectDraw7_CreateSurface's invalid descriptor error code.
by Marvin 15 Feb '17

15 Feb '17

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=28636 Your paranoid android. === w864 (64 bit ddraw7) === The test timed out

1 0

Re: [PATCH] ddraw: Avoid break in __TRY blocks.
by Sebastian Lackner 15 Feb '17

15 Feb '17

On 14.02.2017 22:56, Stefan Dösinger wrote: > This fixes compilation on Visual Studio with native compiler exceptions. > > Signed-off-by: Stefan Dösinger <stefandoesinger(a)gmx.at> While you are just at it, please note that this code also contains a leak when the exception is triggered. Actually, it would probably be easier to test if the pointer is writeable in advance, and exit early without creating the surface at all. > --- > dlls/ddraw/ddraw.c | 36 ++++++++++++++++++++++-------------- > 1 file changed, 22 insertions(+), 14 deletions(-) > > diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c > index 254dae7..54f3817 100644 > --- a/dlls/ddraw/ddraw.c > +++ b/dlls/ddraw/ddraw.c > @@ -2836,11 +2836,13 @@ static HRESULT WINAPI ddraw7_CreateSurface(IDirectDraw7 *iface, DDSURFACEDESC2 * > if (FAILED(hr)) > { > *surface = NULL; > - break; > } > - *surface = &impl->IDirectDrawSurface7_iface; > - IDirectDraw7_AddRef(iface); > - impl->ifaceToRelease = (IUnknown *)iface; > + else > + { > + *surface = &impl->IDirectDrawSurface7_iface; > + IDirectDraw7_AddRef(iface); > + impl->ifaceToRelease = (IUnknown *)iface; > + } > } > __EXCEPT_PAGE_FAULT > { > @@ -2898,11 +2900,13 @@ static HRESULT WINAPI ddraw4_CreateSurface(IDirectDraw4 *iface, > if (FAILED(hr)) > { > *surface = NULL; > - break; > } > - *surface = &impl->IDirectDrawSurface4_iface; > - IDirectDraw4_AddRef(iface); > - impl->ifaceToRelease = (IUnknown *)iface; > + else > + { > + *surface = &impl->IDirectDrawSurface4_iface; > + IDirectDraw4_AddRef(iface); > + impl->ifaceToRelease = (IUnknown *)iface; > + } > } > __EXCEPT_PAGE_FAULT > { > @@ -2962,10 +2966,12 @@ static HRESULT WINAPI ddraw2_CreateSurface(IDirectDraw2 *iface, > if (FAILED(hr)) > { > *surface = NULL; > - break; > } > - *surface = &impl->IDirectDrawSurface_iface; > - impl->ifaceToRelease = NULL; > + else > + { > + *surface = &impl->IDirectDrawSurface_iface; > + impl->ifaceToRelease = NULL; > + } > } > __EXCEPT_PAGE_FAULT > { > @@ -3022,10 +3028,12 @@ static HRESULT WINAPI ddraw1_CreateSurface(IDirectDraw *iface, > if (FAILED(hr)) > { > *surface = NULL; > - break; > } > - *surface = &impl->IDirectDrawSurface_iface; > - impl->ifaceToRelease = NULL; > + else > + { > + *surface = &impl->IDirectDrawSurface_iface; > + impl->ifaceToRelease = NULL; > + } > } > __EXCEPT_PAGE_FAULT > { >

3 4

Re: [PATCH 2/3] dpnet: Add basic validation in IDirectPlay8Peer EnumHosts
by Marvin 15 Feb '17

15 Feb '17

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=28626 Your paranoid android. === wvistau64 (64 bit client) === client.c:645: Test failed: got 0x80004005

1 0

Re: [PATCH] Made ODBC function signatures 64-bit compliant
by Alistair Leslie-Hughes 15 Feb '17

15 Feb '17

On 15/02/17 05:55, Andreas Damm wrote: > From: Andreas Damm <andreas(a)insightsoftware.com> > > --- > dlls/odbc32/proxyodbc.c | 108 +++++++++++++++++++++++----------------------- > include/sql.h | 36 ++++++++-------- > include/sqlext.h | 22 +++++----- > 3 files changed, 83 insertions(+), 83 deletions(-) ~/wine$ patch -p1 < \[PATCH\]\ Made\ ODBC\ function\ signatures\ 64-bit\ compliant.txt This fails to apply against git. patching file dlls/odbc32/proxyodbc.c Hunk #11 succeeded at 1095 with fuzz 2. Hunk #14 succeeded at 1408 with fuzz 2. Hunk #15 succeeded at 1420 with fuzz 2. Hunk #16 succeeded at 1445 with fuzz 2. Hunk #19 succeeded at 1546 with fuzz 2. Hunk #29 succeeded at 2412 with fuzz 2. patching file include/sql.h Hunk #1 FAILED at 506. Hunk #7 FAILED at 669. 2 out of 11 hunks FAILED -- saving rejects to file include/sql.h.rej patching file include/sqlext.h Hunk #1 FAILED at 1455. Hunk #2 FAILED at 1472. Hunk #3 FAILED at 1515. Hunk #5 FAILED at 1578. Hunk #6 succeeded at 1629 with fuzz 1. 4 out of 6 hunks FAILED -- saving rejects to file include/sqlext.h.rej Best Regards Alistair Leslie-Hughes

3 2

Re: [3/4] Use CP 1200 (Unicode) for Win32/Win64 version info.
by Alexandre Julliard 14 Feb '17

14 Feb '17

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/version/tests/info.c | 2 -- > include/wine/wine_common_ver.rc | 10 +++++++++- > 2 files changed, 9 insertions(+), 3 deletions(-) This is breaking some tests: ../../../tools/runtest -q -P wine -T ../../.. -M mshtml.dll -p mshtml_test.exe.so activex && touch activex.ok activex.c:2426: Test failed: expected CreateInstance activex.c:2429: Test failed: expected QuickActivate activex.c:2432: Test failed: expected IPersistPropertyBag_Load activex.c:2433: Test failed: expected Invoke_READYSTATE activex.c:2434: Test failed: expected Invoke_SECURITYCTX activex.c:2435: Test failed: expected Invoke_SCRIPTCALL activex.c:2440: Test failed: expected DoVerb activex.c:2443: Test failed: expected InPlaceObject_GetWindow activex.c:2444: Test failed: expected SetObjectRects wine: Unhandled page fault on read access to 0x00000000 at address 0x7ecb5d28 (thread 0072), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] Made ODBC function signatures 64-bit compliant
by Alistair Leslie-Hughes 14 Feb '17

14 Feb '17

On 15/02/17 05:55, Andreas Damm wrote: > From: Andreas Damm <andreas(a)insightsoftware.com> > > --- > dlls/odbc32/proxyodbc.c | 108 +++++++++++++++++++++++----------------------- > include/sql.h | 36 ++++++++-------- > include/sqlext.h | 22 +++++----- > 3 files changed, 83 insertions(+), 83 deletions(-) ~/wine$ patch -p1 < \[PATCH\]\ Made\ ODBC\ function\ signatures\ 64-bit\ compliant.txt This fails to apply against git. patching file dlls/odbc32/proxyodbc.c Hunk #11 succeeded at 1095 with fuzz 2. Hunk #14 succeeded at 1408 with fuzz 2. Hunk #15 succeeded at 1420 with fuzz 2. Hunk #16 succeeded at 1445 with fuzz 2. Hunk #19 succeeded at 1546 with fuzz 2. Hunk #29 succeeded at 2412 with fuzz 2. patching file include/sql.h Hunk #1 FAILED at 506. Hunk #7 FAILED at 669. 2 out of 11 hunks FAILED -- saving rejects to file include/sql.h.rej patching file include/sqlext.h Hunk #1 FAILED at 1455. Hunk #2 FAILED at 1472. Hunk #3 FAILED at 1515. Hunk #5 FAILED at 1578. Hunk #6 succeeded at 1629 with fuzz 1. 4 out of 6 hunks FAILED -- saving rejects to file include/sqlext.h.rej Best Regards Alistair Leslie-Hughes

1 0

Re: [v3 PATCH] d2d1: Added support for ID2D1GdiInteropRenderTarget interface
by Jacek Caban 14 Feb '17

14 Feb '17

Hi Nikolay, It looks correct to me now. On 14.02.2017 16:19, Nikolay Sivov wrote: > --- a/dlls/d2d1/bitmap_render_target.c > +++ b/dlls/d2d1/bitmap_render_target.c > @@ -32,6 +32,8 @@ static inline struct d2d_bitmap_render_target *impl_from_ID2D1BitmapRenderTarget > static HRESULT STDMETHODCALLTYPE d2d_bitmap_render_target_QueryInterface(ID2D1BitmapRenderTarget *iface, > REFIID iid, void **out) > { > + struct d2d_bitmap_render_target *render_target = impl_from_ID2D1BitmapRenderTarget(iface); > + > TRACE("iface %p, iid %s, out %p.\n", iface, debugstr_guid(iid), out); > > if (IsEqualGUID(iid, &IID_ID2D1BitmapRenderTarget) > @@ -43,6 +45,8 @@ static HRESULT STDMETHODCALLTYPE d2d_bitmap_render_target_QueryInterface(ID2D1Bi > *out = iface; > return S_OK; > } > + else if (IsEqualGUID(iid, &IID_ID2D1GdiInteropRenderTarget)) > + return ID2D1RenderTarget_QueryInterface(render_target->dxgi_target, iid, out); You could just call QI on dxgi_target unconditionally here. It will handle failure for you as well. Also by having this logic in one place, if there are any more interfaces that you'd like to expose from dxgi_target in the future, only dxgi_target QI change would be needed. That's not very important at the moment and I don't really know relevant code, so feel free to ignore that comment :) Thanks, Jacek

2 1

Re: [4/4] version: Replace kernel32 translation info in non-US locales.
by Alexandre Julliard 14 Feb '17

14 Feb '17

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -1078,6 +1086,67 @@ BOOL WINAPI VerQueryValueW( LPCVOID pBlock, LPCWSTR lpSubBlock, > return VersionInfo32_QueryValue(info, lpSubBlock, lplpBuffer, puLen, NULL); > } > > +/* replace translation info as some apps requires localised info from kernel32 */ > +static void replace_translation_info( void *info, DWORD len ) > +{ > + static const WCHAR product_nameW[] = {'\\','S','t','r','i','n','g', > + 'F','i','l','e','I','n','f','o', > + '\\','0','4','0','9','0','4','B','0', > + '\\','P','r','o','d','u','c','t', > + 'N','a','m','e',0}; > + static const WCHAR original_filenameW[] = {'\\','S','t','r','i','n','g', > + 'F','i','l','e','I','n','f','o', > + '\\','0','4','0','9','0','4','B','0', > + '\\','O','r','i','g','i','n','a','l', > + 'F','i','l','e','n','a','m','e',0}; > + static const WCHAR wineW[] = {'W','i','n','e', 0}; > + static const WCHAR kernel32W[] = {'k','e','r','n','e','l','3','2','.','d','l','l',0}; That's very hackish, we need a more general solution. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 3/9] server: Allow creating async objects without associated queue.
by Alexandre Julliard 14 Feb '17

14 Feb '17

Jacek Caban <jacek(a)codeweavers.com> writes: > Creating async object also validates and resets passed event, which (at > least in some cases) should be done too early to queue the async. That's > what following patches do for read and write to match error handling > pattern. > > Also, it seems nice to pass ready to use async object instead of > async_data_t pointer to fd ops. Maybe, but then please clean this up some more. Instead of adding a bunch of optional arguments, please split the functionality into separate functions. For instance, if create_async() is not always queuing, then make queuing a separate step in all cases. Also if we pass the async object we shouldn't need to pass the async data or iosb. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v5 1/3] storage.dll16: Simplify operations in IStream16::Seek.
by Alexandre Julliard 14 Feb '17

14 Feb '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > + case SEEK_END: > + if (offset.QuadPart > This->stde.pps_size) > + return STG_E_INVALIDFUNCTION; > + > + This->offset.QuadPart = This->stde.pps_size-offset.QuadPart; I know the previous code was doing this too, but it doesn't look right. The offset should be added, not subtracted. > + /* offset must be ==0 (<0 is invalid, and >0 cannot be handled > + * right now. > + */ > + assert(This->offset.u.HighPart == 0); You should get rid of the assert while you are at it, that's not appropriate for parameters passed from the application. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] crypt32: Test CryptStringToBinary with weird base64.
by Alexandre Julliard 14 Feb '17

14 Feb '17

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > +static void decodeBase64WithLenFmt(LPCSTR str, int len, DWORD fmt, LPCSTR expected, int le, BOOL isBroken) > +{ > + BYTE buf[8] = {0}; > + DWORD bufLen = sizeof(buf), fmtUsed; > + BOOL ret; > + SetLastError(0); Something like 0xdeadbeef would be better. > + ret = pCryptStringToBinaryA(str, len, fmt, buf, &bufLen, NULL, &fmtUsed); > + buf[bufLen] = 0; This will overflow the buffer if the length hasn't been set. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/4 v2] gdiplus: Reimplement GdipCreateHBITMAPFromBitmap so it can work on locked bitmaps
by Vincent Povirk 14 Feb '17

14 Feb '17

+ GdipGetImageFlags(&bitmap->image, &flags); The result here is unused.

1 0

Re: [v4 1/4] ntdll: Proper handling of debug regs on x86-64.
by Sebastian Lackner 13 Feb '17

13 Feb '17

On 12.02.2017 23:41, Andrew Wesie wrote: > Based on existing code for i386. Code is shared when possible to avoid too > much duplication, even though this leads to more ifdefs. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/ntdll/ntdll_misc.h | 28 ++++++++++---------- > dlls/ntdll/signal_x86_64.c | 64 +++++++++++++++++++++++++++++++++++++++++++--- > dlls/ntdll/thread.c | 12 +++++++-- > 3 files changed, 85 insertions(+), 19 deletions(-) > > diff --git a/dlls/ntdll/ntdll_misc.h b/dlls/ntdll/ntdll_misc.h > index 5e4c39e..5c5cbd2 100644 > --- a/dlls/ntdll/ntdll_misc.h > +++ b/dlls/ntdll/ntdll_misc.h > @@ -215,25 +215,27 @@ struct debug_info > /* thread private data, stored in NtCurrentTeb()->SpareBytes1 */ > struct ntdll_thread_data > { > +#if defined(__i386__) || defined(__x86_64__) > + DWORD_PTR dr0; /* 1bc/2e8 Debug registers */ > + DWORD_PTR dr1; /* 1c0/2f0 */ > + DWORD_PTR dr2; /* 1c4/2f8 */ > + DWORD_PTR dr3; /* 1c8/300 */ > + DWORD_PTR dr6; /* 1cc/308 */ > + DWORD_PTR dr7; /* 1d0/310 */ > +#endif > #ifdef __i386__ > - DWORD dr0; /* 1bc Debug registers */ > - DWORD dr1; /* 1c0 */ > - DWORD dr2; /* 1c4 */ > - DWORD dr3; /* 1c8 */ > - DWORD dr6; /* 1cc */ > - DWORD dr7; /* 1d0 */ > DWORD fs; /* 1d4 TEB selector */ > DWORD gs; /* 1d8 libc selector; update winebuild if you move this! */ > void *vm86_ptr; /* 1dc data for vm86 mode */ > #else > - void *exit_frame; /* /2e8 exit frame pointer */ > + void *exit_frame; /* /318 exit frame pointer */ > #endif > - struct debug_info *debug_info; /* 1e0/2f0 info for debugstr functions */ > - int request_fd; /* 1e4/2f8 fd for sending server requests */ > - int reply_fd; /* 1e8/2fc fd for receiving server replies */ > - int wait_fd[2]; /* 1ec/300 fd for sleeping server requests */ > - BOOL wow64_redir; /* 1f4/308 Wow64 filesystem redirection flag */ > - pthread_t pthread_id; /* 1f8/310 pthread thread id */ > + struct debug_info *debug_info; /* 1e0/320 info for debugstr functions */ > + int request_fd; /* 1e4/328 fd for sending server requests */ > + int reply_fd; /* 1e8/32c fd for receiving server replies */ > + int wait_fd[2]; /* 1ec/330 fd for sleeping server requests */ > + BOOL wow64_redir; /* 1f4/338 Wow64 filesystem redirection flag */ > + pthread_t pthread_id; /* 1f8/340 pthread thread id */ > #ifdef __i386__ > WINE_VM86_TEB_INFO vm86; /* 1fc vm86 private data */ > void *exit_frame; /* 204 exit frame pointer */ Adding those fields should work, but it is a bit dangerous because we only have limited space. I would suggest adding asserts to ensure we never make this struct too big. Something like this should work: C_ASSERT( FIELD_OFFSET(TEB, SpareBytes1) + sizeof(struct ntdll_thread_data) <= FIELD_OFFSET(TEB, GdiTebBatch) + sizeof(((TEB *)0)->GdiTebBatch) ); Probably we should also use it for important i386 fields, to ensure they are not moved. #ifdef __i386__ C_ASSERT( FIELD_OFFSET(TEB, SpareBytes1) + FIELD_OFFSET(struct ntdll_thread_data, vm86) == FIELD_OFFSET(TEB, GdiTebBatch) ); C_ASSERT( FIELD_OFFSET(TEB, SpareBytes1) + FIELD_OFFSET(struct ntdll_thread_data, vm86) == 0x1fc ); C_ASSERT( FIELD_OFFSET(TEB, SpareBytes1) + FIELD_OFFSET(struct ntdll_thread_data, gs) == 0x1d8 ); #endif > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index f33fe4c..d2b040e 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -1649,7 +1649,9 @@ static inline BOOL is_inside_signal_stack( void *ptr ) > */ > static void save_context( CONTEXT *context, const ucontext_t *sigcontext ) > { > - context->ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER | CONTEXT_SEGMENTS; > + struct ntdll_thread_data * const regs = ntdll_get_thread_data(); > + > + context->ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER | CONTEXT_SEGMENTS | CONTEXT_DEBUG_REGISTERS; > context->Rax = RAX_sig(sigcontext); > context->Rcx = RCX_sig(sigcontext); > context->Rdx = RDX_sig(sigcontext); > @@ -1686,6 +1688,12 @@ static void save_context( CONTEXT *context, const ucontext_t *sigcontext ) > #else > __asm__("movw %%ss,%0" : "=m" (context->SegSs)); > #endif > + context->Dr0 = regs->dr0; > + context->Dr1 = regs->dr1; > + context->Dr2 = regs->dr2; > + context->Dr3 = regs->dr3; > + context->Dr6 = regs->dr6; > + context->Dr7 = regs->dr7; > if (FPU_sig(sigcontext)) > { > context->ContextFlags |= CONTEXT_FLOATING_POINT; > @@ -1702,6 +1710,14 @@ static void save_context( CONTEXT *context, const ucontext_t *sigcontext ) > */ > static void restore_context( const CONTEXT *context, ucontext_t *sigcontext ) > { > + struct ntdll_thread_data * const regs = ntdll_get_thread_data(); > + > + regs->dr0 = context->Dr0; > + regs->dr1 = context->Dr1; > + regs->dr2 = context->Dr2; > + regs->dr3 = context->Dr3; > + regs->dr6 = context->Dr6; > + regs->dr7 = context->Dr7; > RAX_sig(sigcontext) = context->Rax; > RCX_sig(sigcontext) = context->Rcx; > RDX_sig(sigcontext) = context->Rdx; > @@ -1861,6 +1877,16 @@ __ASM_GLOBAL_FUNC( set_full_cpu_context, > void set_cpu_context( const CONTEXT *context ) > { > DWORD flags = context->ContextFlags & ~CONTEXT_AMD64; > + > + if (flags & CONTEXT_DEBUG_REGISTERS) > + { > + ntdll_get_thread_data()->dr0 = context->Dr0; > + ntdll_get_thread_data()->dr1 = context->Dr1; > + ntdll_get_thread_data()->dr2 = context->Dr2; > + ntdll_get_thread_data()->dr3 = context->Dr3; > + ntdll_get_thread_data()->dr6 = context->Dr6; > + ntdll_get_thread_data()->dr7 = context->Dr7; > + } > if (flags & CONTEXT_FULL) > { > if (!(flags & CONTEXT_CONTROL)) > @@ -2559,7 +2585,7 @@ static void raise_segv_exception( EXCEPTION_RECORD *rec, CONTEXT *context ) > } > break; > } > - status = raise_exception( rec, context, TRUE ); > + status = NtRaiseException( rec, context, TRUE ); > if (status) raise_status( status, rec ); NtRaiseException will always return a status != 0, so there is no need for the check anymore. > done: > set_cpu_context( context ); > @@ -2567,13 +2593,43 @@ done: > > > /********************************************************************** > + * raise_trap_exception > + */ > +static void raise_trap_exception( EXCEPTION_RECORD *rec, CONTEXT *context ) > +{ > + NTSTATUS status; > + > + if (rec->ExceptionCode == EXCEPTION_SINGLE_STEP) > + { > + /* when single stepping can't tell whether this is a hw bp or a > + * single step interrupt. try to avoid as much overhead as possible > + * and only do a server call if there is any hw bp enabled. */ > + > + if( !(context->EFlags & 0x100) || (ntdll_get_thread_data()->dr7 & 0xff) ) > + { > + /* (possible) hardware breakpoint, fetch the debug registers */ > + DWORD saved_flags = context->ContextFlags; > + context->ContextFlags = CONTEXT_DEBUG_REGISTERS; > + NtGetContextThread(GetCurrentThread(), context); > + context->ContextFlags |= saved_flags; /* restore flags */ > + } > + > + context->EFlags &= ~0x100; /* clear single-step flag */ > + } > + > + status = NtRaiseException( rec, context, TRUE ); > + raise_status( status, rec ); > +} > + > + > +/********************************************************************** > * raise_generic_exception > * > * Generic raise function for exceptions that don't need special treatment. > */ > static void raise_generic_exception( EXCEPTION_RECORD *rec, CONTEXT *context ) > { > - NTSTATUS status = raise_exception( rec, context, TRUE ); > + NTSTATUS status = NtRaiseException( rec, context, TRUE ); > if (status) raise_status( status, rec ); > set_cpu_context( context ); Similar to above, this can be simplified because status is always != 0. > } > @@ -2684,7 +2740,7 @@ static void segv_handler( int signal, siginfo_t *siginfo, void *sigcontext ) > */ > static void trap_handler( int signal, siginfo_t *siginfo, void *sigcontext ) > { > - EXCEPTION_RECORD *rec = setup_exception( sigcontext, raise_generic_exception ); > + EXCEPTION_RECORD *rec = setup_exception( sigcontext, raise_trap_exception ); > > switch (siginfo->si_code) > { > diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c > index c9a5da6..934ada1 100644 > --- a/dlls/ntdll/thread.c > +++ b/dlls/ntdll/thread.c > @@ -744,10 +744,14 @@ NTSTATUS WINAPI NtSetContextThread( HANDLE handle, const CONTEXT *context ) > DWORD dummy, i; > BOOL self; > > -#ifdef __i386__ > +#if defined(__i386__) || defined(__x86_64__) > /* on i386 debug registers always require a server call */ > self = (handle == GetCurrentThread()); > +#ifdef __i386__ > if (self && (context->ContextFlags & (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_i386))) > +#elif defined(__x86_64__) > + if (self && (context->ContextFlags & (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_AMD64))) > +#endif > { > self = (ntdll_get_thread_data()->dr0 == context->Dr0 && > ntdll_get_thread_data()->dr1 == context->Dr1 && > @@ -903,9 +907,13 @@ NTSTATUS WINAPI NtGetContextThread( HANDLE handle, CONTEXT *context ) > copy_context( context, &ctx, ctx.ContextFlags & needed_flags ); > context->ContextFlags |= ctx.ContextFlags & needed_flags; > } > -#ifdef __i386__ > +#if defined(__i386__) || defined(__x86_64__) > /* update the cached version of the debug registers */ > +#ifdef __i386__ > if (context->ContextFlags & (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_i386)) > +#elif defined(__x86_64__) > + if (context->ContextFlags & (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_AMD64)) > +#endif > { > ntdll_get_thread_data()->dr0 = context->Dr0; > ntdll_get_thread_data()->dr1 = context->Dr1; > -- 2.7.4 >

2 2

Re: [v4 3/4] ntdll: Save rdi and rsi in raise_func_trampoline.
by Sebastian Lackner 13 Feb '17

13 Feb '17

On 12.02.2017 23:41, Andrew Wesie wrote: > On Windows, RDI and RSI are callee-saved registers, but on Linux > they are caller-saved registers. As such, raise_func_trampoline > needs to explicitly unwind them. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/ntdll/signal_x86_64.c | 12 +++++++++--- > dlls/ntdll/tests/exception.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 51 insertions(+), 3 deletions(-) > > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index d2b040e..2370cf4 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -2092,9 +2092,11 @@ NTSTATUS context_from_server( CONTEXT *to, const context_t *from ) > extern void raise_func_trampoline( EXCEPTION_RECORD *rec, CONTEXT *context, raise_func func ); > __ASM_GLOBAL_FUNC( raise_func_trampoline, > __ASM_CFI(".cfi_signal_frame\n\t") > - __ASM_CFI(".cfi_def_cfa %rbp,144\n\t") /* red zone + rip + rbp */ > - __ASM_CFI(".cfi_rel_offset %rip,8\n\t") > - __ASM_CFI(".cfi_rel_offset %rbp,0\n\t") > + __ASM_CFI(".cfi_def_cfa %rbp,160\n\t") /* red zone + rip + rbp + rdi + rsi */ > + __ASM_CFI(".cfi_rel_offset %rip,24\n\t") > + __ASM_CFI(".cfi_rel_offset %rbp,16\n\t") > + __ASM_CFI(".cfi_rel_offset %rdi,8\n\t") > + __ASM_CFI(".cfi_rel_offset %rsi,0\n\t") > "call *%rdx\n\t" > "int $3") > > @@ -2111,6 +2113,8 @@ static EXCEPTION_RECORD *setup_exception( ucontext_t *sigcontext, raise_func fun > { > CONTEXT context; > EXCEPTION_RECORD rec; > + ULONG64 rsi; > + ULONG64 rdi; > ULONG64 rbp; > ULONG64 rip; > ULONG64 red_zone[16]; > @@ -2180,6 +2184,8 @@ static EXCEPTION_RECORD *setup_exception( ucontext_t *sigcontext, raise_func fun > rsp_ptr = (ULONG64 *)RSP_sig(sigcontext) - 16; > *(--rsp_ptr) = RIP_sig(sigcontext); > *(--rsp_ptr) = RBP_sig(sigcontext); > + *(--rsp_ptr) = RDI_sig(sigcontext); > + *(--rsp_ptr) = RSI_sig(sigcontext); > > /* now modify the sigcontext to return to the raise function */ > RIP_sig(sigcontext) = (ULONG_PTR)raise_func_trampoline; > diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c > index 183cf18..15973ce 100644 > --- a/dlls/ntdll/tests/exception.c > +++ b/dlls/ntdll/tests/exception.c > @@ -2073,6 +2073,47 @@ static DWORD run_exception_test(void *handler, const void* context, > return result; > } > > +static DWORD WINAPI unwind_rdi_rsi_handler( EXCEPTION_RECORD *rec, ULONG64 frame, > + CONTEXT *context, DISPATCHER_CONTEXT *dispatcher ) > +{ > + if (rec->ExceptionCode != STATUS_BREAKPOINT) > + return ExceptionContinueSearch; > + > + RtlUnwind( (PVOID)context->Rsp, (PVOID)(context->Rip + 1), rec, NULL ); Doesn't this suffer from the same problem as before? We might not have unwinding information for the unwind_rdi_rsi_handler function if it is not supported by all x86_64 compilers. Actually, I believe the change itself would also be acceptable even without tests. > + return ExceptionContinueSearch; > +} > + > +static const BYTE unwind_rdi_test_code[] = { > + 0x57, /* push %rdi */ > + 0x48, 0xc7, 0xc7, 0x55, 0x55, 0x55, 0x55, /* mov $0x55555555, %rdi */ > + 0xcc, /* int3 */ > + 0x48, 0x89, 0xf8, /* mov %rdi, %rax */ > + 0x5f, /* pop %rdi */ > + 0xc3, /* ret */ > +}; > + > +static const BYTE unwind_rsi_test_code[] = { > + 0x56, /* push %rsi */ > + 0x48, 0xc7, 0xc6, 0x33, 0x33, 0x33, 0x33, /* mov $0x33333333, %rsi */ > + 0xcc, /* int3 */ > + 0x48, 0x89, 0xf0, /* mov %rsi, %rax */ > + 0x5e, /* pop %rsi */ > + 0xc3, /* ret */ > +}; > + > +static void test_unwind_rdi_rsi(void) > +{ > + DWORD result; > + > + result = run_exception_test(unwind_rdi_rsi_handler, NULL, unwind_rdi_test_code, > + sizeof(unwind_rdi_test_code), 0); > + ok( result == 0x55555555, "expected %x, got %x\n", 0x55555555, result ); > + > + result = run_exception_test(unwind_rdi_rsi_handler, NULL, unwind_rsi_test_code, > + sizeof(unwind_rsi_test_code), 0); > + ok( result == 0x33333333, "expected %x, got %x\n", 0x33333333, result ); > +} > + > #endif /* __x86_64__ */ > > #if defined(__i386__) || defined(__x86_64__) > @@ -2653,6 +2694,7 @@ START_TEST(exception) > test_virtual_unwind(); > test___C_specific_handler(); > test_restore_context(); > + test_unwind_rdi_rsi(); > > if (pRtlAddFunctionTable && pRtlDeleteFunctionTable && pRtlInstallFunctionTableCallback && pRtlLookupFunctionEntry) > test_dynamic_unwind(); > -- 2.7.4 >

2 1

Re: [PATCH 01/14] mshtml/tests: Added body event setters tests.
by Marvin 13 Feb '17

13 Feb '17

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=28575 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [v3 1/5] compobj.dll16: Implement CoLoadLibrary16 and CoFreeLibrary16.
by Alexandre Julliard 13 Feb '17

13 Feb '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > +static HRESULT dll_list_add(LPCSTR library_name, struct open_dll **ret) > +{ > + struct open_dll *dll; > + HMODULE16 library; > + FARPROC16 DllCanUnloadNow; > + > + LIST_FOR_EACH_ENTRY(dll, &open_dll_list, struct open_dll, entry) > + { > + if(!strcasecmp(library_name, dll->library_name)) > + { > + TRACE("found %s already loaded\n", debugstr_a(library_name)); > + InterlockedIncrement(&dll->refs); > + *ret = dll; > + return S_OK; > + } > + } I don't think that comparing file names is appropriate for 16-bit, only the module name matters. You should probably call LoadLibrary16 in all cases. > + > + library = LoadLibrary16(library_name); > + if (!library) > + { > + ERR("couldn't load in-process dll %s\n", debugstr_a(library_name)); > + return E_ACCESSDENIED; /* FIXME: or should this be CO_E_DLLNOTFOUND? */ > + } You'd need to check again if the dll already exists, like the 32-bit code does. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [v7 5/6] user32: Send WM_NCPAINT and WM_ERASEBKGND when window is shown and add tests
by Fabian Maurer 13 Feb '17

13 Feb '17

> msg.c:5233: Test failed: RedrawWindow:show_popup_extreme_location: > 12: the msg 0x001c was expected, but got msg 0x0085 instead Can't reproduce the error.

1 0

Re: [v7 5/6] user32: Send WM_NCPAINT and WM_ERASEBKGND when window is shown and add tests
by Marvin 13 Feb '17

13 Feb '17

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

1 0

Re: advapi32: add LookupSecurityDescriptorPartsA/W stubs (resend)
by Sebastian Lackner 13 Feb '17

13 Feb '17

On 13.02.2017 09:23, Austin English wrote: > Originally sent in November, with no comments: > https://source.winehq.org/patches/data/127657 > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41682 > > -- -Austin GPG: 14FB D7EA A041 937B > > > 0001-advapi32-add-LookupSecurityDescriptorPartsA-W-stubs.patch > > > From eebe82acd3fd4828a74b38c97f260ddfd2143b83 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Wed, 9 Nov 2016 21:43:18 -0600 > Subject: [PATCH] advapi32: add LookupSecurityDescriptorPartsA/W stubs > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/advapi32/advapi32.spec | 4 ++-- > dlls/advapi32/security.c | 24 ++++++++++++++++++++++++ > 2 files changed, 26 insertions(+), 2 deletions(-) > > diff --git a/dlls/advapi32/advapi32.spec b/dlls/advapi32/advapi32.spec > index 6c57c88..88d8634 100644 > --- a/dlls/advapi32/advapi32.spec > +++ b/dlls/advapi32/advapi32.spec > @@ -415,8 +415,8 @@ > @ stdcall LookupPrivilegeNameW(wstr ptr ptr ptr) > @ stdcall LookupPrivilegeValueA(ptr ptr ptr) > @ stdcall LookupPrivilegeValueW(ptr ptr ptr) > -# @ stub LookupSecurityDescriptorPartsA > -# @ stub LookupSecurityDescriptorPartsW > +@ stdcall LookupSecurityDescriptorPartsA(ptr ptr ptr ptr ptr ptr ptr) > +@ stdcall LookupSecurityDescriptorPartsW(ptr ptr ptr ptr ptr ptr ptr) > @ stdcall LsaAddAccountRights(ptr ptr ptr long) > @ stub LsaAddPrivilegesToAccount > # @ stub LsaClearAuditLog > diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c > index 7e41c0a..b094015 100644 > --- a/dlls/advapi32/security.c > +++ b/dlls/advapi32/security.c > @@ -6087,3 +6087,27 @@ BOOL WINAPI SaferSetLevelInformation(SAFER_LEVEL_HANDLE handle, SAFER_OBJECT_INF > FIXME("(%p %u %p %u) stub\n", handle, infotype, buffer, size); > return FALSE; > } > + > +/****************************************************************************** > + * LookupSecurityDescriptorPartsA [ADVAPI32.@] > + */ > +DWORD WINAPI LookupSecurityDescriptorPartsA(TRUSTEEA *owner, TRUSTEEA *group, ULONG *access_count, > + EXPLICIT_ACCESSA *access_list, ULONG *audit_count, > + EXPLICIT_ACCESSA *audit_list, SECURITY_DESCRIPTOR *descriptor) > +{ > + FIXME("stub:%p %p %p %p %p %p %p\n", owner, group, access_count, > + access_list, audit_count, audit_list, descriptor); > + return ERROR_SUCCESS; It would be better to return failure when the stub doesn't do anything useful. > +} > + > +/****************************************************************************** > + * LookupSecurityDescriptorPartsW [ADVAPI32.@] > + */ > +DWORD WINAPI LookupSecurityDescriptorPartsW(TRUSTEEW *owner, TRUSTEEW *group, ULONG *access_count, > + EXPLICIT_ACCESSW *access_list, ULONG *audit_count, > + EXPLICIT_ACCESSW *audit_list, SECURITY_DESCRIPTOR *descriptor) > +{ > + FIXME("stub:%p %p %p %p %p %p %p\n", owner, group, access_count, > + access_list, audit_count, audit_list, descriptor); > + return ERROR_SUCCESS; > +} > -- 2.10.2 > > >

1 0

Re: qcap: Fix Query IID_PPin Interface return not found
by Andrew Eikum 13 Feb '17

13 Feb '17

I wrote a quick test for this, and Windows doesn't behave this way. diff --git a/dlls/qcap/tests/qcap.c b/dlls/qcap/tests/qcap.c index d7fe288f4a..eed101cee3 100644 --- a/dlls/qcap/tests/qcap.c +++ b/dlls/qcap/tests/qcap.c @@ -1990,6 +1990,8 @@ static void test_COM_vfwcapture(void) todo_wine ok(hr == E_NOINTERFACE, "QueryInterface for IID_IAMVideoProcAmp failed: %08x\n", hr); hr = IBaseFilter_QueryInterface(bf, &IID_IOverlayNotify, (void**)&unk); ok(hr == E_NOINTERFACE, "QueryInterface for IID_IOverlayNotify failed: %08x\n", hr); + hr = IBaseFilter_QueryInterface(bf, &IID_IPin, (void**)&unk); + ok(hr == E_NOINTERFACE, "QueryInterface for IID_IPin failed: %08x\n", hr); while (IBaseFilter_Release(bf)); } On Thu, Feb 09, 2017 at 02:25:33PM +0800, 谢威 wrote: > ------------------ > ------------------ > > > > 武汉深之度科技有限公司 > Wuhan Deepin Technology Co., Ltd. > > 　　谢威　　 > > 手机：18038104349 > > > 武汉：武汉市光谷大道77号光谷金融港B18栋6楼 > 北京：北京市海淀区知春路锦秋国际大厦B座501室 > 上海：上海市长宁区愚园路1258号15A01室 > > > 官网：www.deepin.com　官博：深度操作系统 >

1 0

Re: [PATCH 01/12] mshtml/tests: Added body event setters tests.
by Marvin 13 Feb '17

13 Feb '17

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=28563 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH 02/12] mshtml: Use inner window's event target for body element.
by Jacek Caban 13 Feb '17

13 Feb '17

Hi, Please ignore the series for now, I will send a better version later. Jacek

1 0

Re: [PATCH 2/7] gdiplus: Initialize bitmap bits for reading in GdipBitmapLockBits when ImageFlagsReadOnly is specified
by Vincent Povirk 13 Feb '17

13 Feb '17

This is very strange behavior. I think you at least need a comment making it clear this is intentional, and some tests. Your test in 7/7 isn't sufficient because it doesn't make it clear that the bits are being converted. I think you should test that the bitmap format is different from the one you use to lock, and add another test with ImageLockModeUserInputBuf. On Wed, Feb 8, 2017 at 9:56 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdiplus/image.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > >

2 1

Re: [PATCH 2/2] mfreadwrite: Add MFCreateSourceReaderFromMediaSource stub
by Andrew Eikum 13 Feb '17

13 Feb '17

> +WINE_DEFAULT_DEBUG_CHANNEL(mfreadwrite); > There are a bunch of Media Foundation DLLs, I count roughly 12 on my Win7 VM. I think we should stick to just one debug channel in Wine. I suggest "mfplat" since we already have it. Andrew

1 0

Re: [v6 4/6] user32: Add WM_NCPAINT tests for windows crossing screen or maximized
by Alexandre Julliard 13 Feb '17

13 Feb '17

Fabian Maurer <dark.shadow4(a)web.de> writes: > @@ -4580,6 +4643,18 @@ static void test_showwindow(void) > DestroyWindow(hwnd); > flush_sequence(); > > + /* Test again, this time the NC_PAINT message */ > + hwnd = CreateWindowExA(0, "TestWindowClass", "Test popup", WS_POPUP | WS_MAXIMIZE, > + 100, 100, 200, 200, 0, 0, 0, NULL); > + ok (hwnd != 0, "Failed to create popup window\n"); > + SetWindowPos(hwnd, 0, 10, 10, 200, 200, SWP_NOZORDER | SWP_NOACTIVATE); > + flush_sequence(); > + ShowWindow(hwnd, SW_SHOWMAXIMIZED); > + ok_sequence(WmShowMaxPopupResizedSeq_todo, > + "ShowWindow(SW_SHOWMAXIMIZED):invisible maximized and resized popup TODO", TRUE); > + DestroyWindow(hwnd); > + flush_sequence(); This one is already succeeding here: ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so msg && touch msg.ok msg.c:4654: Test succeeded inside todo block: ShowWindow(SW_SHOWMAXIMIZED):invisible maximized and resized popup TODO: marked "todo_wine" but succeeds msg.c:13361: Tests skipped: Skipping DBCS WM_CHAR test in SBCS codepage 'ANSI Latin 1' msg.c:13677: Tests skipped: Unable to load Greek keyboard layout Makefile:482: recipe for target 'msg.ok' failed -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v2 PATCH 2/3] d2d1: Added support for ID2D1GdiInteropRenderTarget interface
by Jacek Caban 13 Feb '17

13 Feb '17

Hi Nikolay, On 12.02.2017 20:14, Nikolay Sivov wrote: > diff --git a/dlls/d2d1/bitmap_render_target.c b/dlls/d2d1/bitmap_render_target.c > index 67b0713376..3ac5c77d36 100644 > --- a/dlls/d2d1/bitmap_render_target.c > +++ b/dlls/d2d1/bitmap_render_target.c > @@ -32,6 +32,8 @@ static inline struct d2d_bitmap_render_target *impl_from_ID2D1BitmapRenderTarget > static HRESULT STDMETHODCALLTYPE d2d_bitmap_render_target_QueryInterface(ID2D1BitmapRenderTarget *iface, > REFIID iid, void **out) > { > + struct d2d_bitmap_render_target *render_target = impl_from_ID2D1BitmapRenderTarget(iface); > + > TRACE("iface %p, iid %s, out %p.\n", iface, debugstr_guid(iid), out); > > if (IsEqualGUID(iid, &IID_ID2D1BitmapRenderTarget) > @@ -43,6 +45,8 @@ static HRESULT STDMETHODCALLTYPE d2d_bitmap_render_target_QueryInterface(ID2D1Bi > *out = iface; > return S_OK; > } > + else if (IsEqualGUID(iid, &IID_ID2D1GdiInteropRenderTarget)) > + return ID2D1RenderTarget_QueryInterface(render_target->dxgi_target, iid, out); AFAICS this won't work. If you call QueryInterface(IID_ID2D1BitmapRenderTarget) on returned ID2D1GdiInteropRenderTarget, it will fail. There are a few solutions for that. The most generic is COM aggregation with separated 'inner' IUnknown for dxgi_target. Thanks, Jacek

2 1

Re: [PATCH 2/3] wined3d: Marge common code between texture3d_load_location() and surface_load_location().
by Henri Verbeet 13 Feb '17

13 Feb '17

On 13 February 2017 at 13:13, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/wined3d/surface.c | 60 ++------------------------------------ > dlls/wined3d/texture.c | 79 ++++++++++++++++++++++++++++++-------------------- > 2 files changed, 50 insertions(+), 89 deletions(-) > That should have read "Merge" instead of "Marge".

1 0

Re: [PATCH] include: Make break out of __TRY blocks work with compiler exceptions.
by Alexandre Julliard 13 Feb '17

13 Feb '17

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > ddraw.dll uses this. I am using compiler exceptions for my Visual Studio > build setup. A ddraw.dll compiled with this passes the test added by > commit d9f2b4627. I manually tested the functionality of __TRY-__FINALLY, > __EXCEPT_ALL and __EXCEPT(func). It would be better to avoid break, and ideally find a way to disallow it in the Wine macros. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v4 1/3] storage.dll16: Fix negation in IStream::Seek.
by Huw Davies 13 Feb '17

13 Feb '17

On Sun, Feb 12, 2017 at 12:03:20PM -0600, Zebediah Figura wrote: > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/storage.dll16/storage.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/dlls/storage.dll16/storage.c b/dlls/storage.dll16/storage.c > index 74aa7f9..7a5b367 100644 > --- a/dlls/storage.dll16/storage.c > +++ b/dlls/storage.dll16/storage.c > @@ -1196,9 +1196,8 @@ HRESULT CDECL IStream16_fnSeek(IStream16 *iface, LARGE_INTEGER offset, DWORD whe > break; > case SEEK_CUR: > if (offset.u.HighPart < 0) { > - /* FIXME: is this negation correct ? */ > - offset.u.HighPart = -offset.u.HighPart; > - offset.u.LowPart = (0xffffffff ^ offset.u.LowPart)+1; > + offset.u.HighPart = ~offset.u.HighPart + (offset.u.LowPart ? 0 : 1); > + offset.u.LowPart = -offset.u.LowPart; > > assert(offset.u.HighPart==0); > assert(This->offset.u.LowPart >= offset.u.LowPart); > -- Couldn't you just replace the whole SEEK_CUR branch with: This->offset.QuadPart += offset.QuadPart; Huw.

1 0

Re: [PATCH v2 1/3] storage.dll16: Fix negation in IStream::Seek.
by Henri Verbeet 12 Feb '17

12 Feb '17

On 11 February 2017 at 23:54, Zebediah Figura <z.figura12(a)gmail.com> wrote: > @@ -1196,9 +1196,8 @@ HRESULT CDECL IStream16_fnSeek(IStream16 *iface, LARGE_INTEGER offset, DWORD whe > break; > case SEEK_CUR: > if (offset.u.HighPart < 0) { > - /* FIXME: is this negation correct ? */ > - offset.u.HighPart = -offset.u.HighPart; > - offset.u.LowPart = (0xffffffff ^ offset.u.LowPart)+1; > + offset.u.HighPart = ~offset.u.HighPart; > + offset.u.LowPart = -offset.u.LowPart; > I don't think that's quite correct either. Consider e.g. 0xffffffff00000000, the negation of which would be 0x0000000100000000.

2 1

Re: [PATCH] include: Make break out of __TRY blocks work with compiler exceptions.
by Dmitry Timoshkov 12 Feb '17

12 Feb '17

Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > +#define __TRY __try { do > +#define __EXCEPT(func) while(0); } __except((func)(GetExceptionInformation())) { do > +#define __FINALLY(func) while(0); } __finally { (func)(!AbnormalTermination()); } > +#define __ENDTRY while(0); } > +#define __EXCEPT_PAGE_FAULT while(0); } __except(GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) { do > +#define __EXCEPT_ALL while(0); } __except(EXCEPTION_EXECUTE_HANDLER) { do Perhaps add another '{' after 'do' and and '}' before 'while(0)' ? -- Dmitry.

2 2

Re: kernel32: Avoid two potential buffer overflows of cStr in create_hardware_branch.
by Sebastian Lackner 12 Feb '17

12 Feb '17

On 08.10.2016 22:31, Gerald Pfeifer wrote: > + char cStr[sizeof(dent->d_name)+sizeof(procname_ide_media)], http://man7.org/linux/man-pages/man3/readdir.3.html says: """The standard also notes that the use of sizeof(d_name) is incorrect; use strlen(d_name) instead. (On some systems, this field is defined as char d_name[1]!)""" This means your solution will not work on all systems.

3 4

Re: [PATCH 1/2] RFC: Implement XInputEnable based on MSDN
by Bruno Jesus 12 Feb '17

12 Feb '17

On Sat, Feb 11, 2017 at 9:05 PM, Christoph Brill <egore911(a)gmail.com> wrote: > --- > dlls/xinput1_3/xinput1_3_main.c | 45 ++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 44 insertions(+), 1 deletion(-) Hi, thanks for the patch but currently Wine is aiming at a different direction of reimplementing the 3 joystick API's (winmm, dinput and xinput) using a single HID library so that the OS dependent parts stay in one place. I believe Wine is only months away of having all these working with current Aric Stewart work. Other people (including me) already have suggested at wine-devel/wine-patches more or less completed versions of xinput using SDL, dinput and event libraries before/during the HID model adoption. IMO the best thing that can be done for now is to ensure the winmm driver (in the progress of being commited [1]) works fine so help testing is very welcome. After that we will have a standard to implement the other 2 API's. [1] http://source.winehq.org/patches/data/129688 Best wishes, Bruno

1 0

Re: [PATCH] storage.dll16: Set OpenStorage/OpenStream output to NULL on failure.
by Nikolay Sivov 12 Feb '17

12 Feb '17

On 12.02.2017 2:40, Zebediah Figura wrote: > As per MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/aa380025(v=vs.85).… > This page covers Win32 variant, it doesn't necessary match how Win16 works, or Win32 too for that matter.

2 1

Re: [PATCH 1/3] storage.dll16: Fix negation in IStream::Seek.
by Alex Henrie 11 Feb '17

11 Feb '17

@@ -1196,9 +1196,8 @@ HRESULT CDECL IStream16_fnSeek(IStream16 *iface, LARGE_INTEGER offset, DWORD whe break; case SEEK_CUR: if (offset.u.HighPart < 0) { - /* FIXME: is this negation correct ? */ - offset.u.HighPart = -offset.u.HighPart; - offset.u.LowPart = (0xffffffff ^ offset.u.LowPart)+1; + offset.u.HighPart = ~offset.u.HighPart; + offset.u.LowPart = -offset.u.LowPart; assert(offset.u.HighPart==0); assert(This->offset.u.LowPart >= offset.u.LowPart); You're mixing tabs and spaces. -Alex

1 0

Re: [v4 2/3] ntdll: Implement FileIdInformation class support in NtQueryInformationFile (resend).
by Sebastian Lackner 10 Feb '17

10 Feb '17

On 07.02.2017 16:11, Jonathan Doron wrote: > Signed-off-by: Jonathan Doron <jond(a)wizery.com> > --- > configure.ac | 2 +- > dlls/ntdll/file.c | 28 ++++++++++++++++++++++- > dlls/ntdll/tests/file.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++ > include/winternl.h | 9 ++++++++ > 4 files changed, 97 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index c6d63b2..f66bf44 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2262,7 +2262,7 @@ fi > dnl **** FIXME: what about mixed cases, where we need two of them? *** > > dnl Check for statfs members > -AC_CHECK_MEMBERS([struct statfs.f_bfree, struct statfs.f_bavail, struct statfs.f_frsize, struct statfs.f_ffree, struct statfs.f_favail, struct statfs.f_namelen],,, > +AC_CHECK_MEMBERS([struct statfs.f_bfree, struct statfs.f_bavail, struct statfs.f_frsize, struct statfs.f_ffree, struct statfs.f_favail, struct statfs.f_namelen, struct statfs.f_fsid.__val],,, > [#include <sys/types.h> > #ifdef HAVE_SYS_PARAM_H > # include <sys/param.h> > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index a6c1098..c6ff371 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2377,7 +2377,7 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > 0, /* FileRenameInformationBypassAccessCheck */ > 0, /* FileLinkInformationBypassAccessCheck */ > 0, /* FileVolumeNameInformation */ > - 0, /* FileIdInformation */ > + sizeof(FILE_ID_INFORMATION), /* FileIdInformation */ > 0, /* FileIdExtdDirectoryInformation */ > 0, /* FileReplaceCompletionInformation */ > 0, /* FileHardLinkFullIdInformation */ > @@ -2619,6 +2619,32 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > } > } > break; > + case FileIdInformation: > + { > + FILE_ID_INFORMATION *info = ptr; > + memset(info, 0, sizeof(*info)); > + if (fstat(fd, &st) == -1) > + { > + io->u.Status = FILE_GetNtStatus(); > + } > + else > + { > +#if defined(linux) && defined(HAVE_FSTATFS) && defined(HAVE_STRUCT_STATFS_F_FSID___VAL) > + struct statfs volstats; > + if (fstatfs(fd, &volstats) == -1) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + > + memcpy(&info->VolumeSerialNumber, > + &volstats.f_fsid.__val, > + min(sizeof(info->VolumeSerialNumber), sizeof(volstats.f_fsid.__val))); I didn't think about this earlier, but if you are planning to use memcpy anyway, wouldn't it be easier to just copy f_fsid directly, instead of f_fsid.__val? When you do not make any assumptions about f_fsid it would work on all platforms. > +#endif > + ((LARGE_INTEGER *)&info->FileId)->QuadPart = st.st_ino; > + } > + } > + break; > default: > FIXME("Unsupported class (%d)\n", class); > io->u.Status = STATUS_NOT_IMPLEMENTED; > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index 57d7df9..00856ab 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -1444,6 +1444,65 @@ static void test_file_basic_information(void) > CloseHandle( h ); > } > > +static void test_file_id_information(void) > +{ > + IO_STATUS_BLOCK io; > + FILE_ID_INFORMATION fid1, fid2; > + HANDLE h = INVALID_HANDLE_VALUE; > + NTSTATUS res; > + char path[MAX_PATH], buffer[MAX_PATH]; > + > + /* Generate a temp file name */ Not all of these steps need an explanation, so you could remove some of the comments for things which are obvious. > + GetTempPathA(MAX_PATH, path); > + GetTempFileNameA(path, "foo", 0, buffer); > + > + /* Create the temp file */ > + h = CreateFileA(buffer, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0); > + ok(h != INVALID_HANDLE_VALUE, "CreateFile error %d\n", GetLastError()); > + > + /* Query the temp file unique id */ > + memset(&fid1, 0, sizeof(fid1)); > + res = pNtQueryInformationFile(h, &io, &fid1, sizeof fid1, FileIdInformation); Here you are mixing two styles for sizeof, one with "()" and one without. The same also applies to a couple of other places below. > + if ((res == STATUS_NOT_IMPLEMENTED) || (res == STATUS_INVALID_INFO_CLASS)) The extra "()" is not really necessary. > + { > + CloseHandle(h); > + DeleteFileA(buffer); > + win_skip("FileIdInformation not supported\n"); > + return; > + } > + > + ok(res == STATUS_SUCCESS, "can't get fid1, res %x\n", res); > + > + CloseHandle(h); > + > + /* Open the file again */ > + h = CreateFileA(buffer, GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); > + ok(h != INVALID_HANDLE_VALUE, "CreateFile error %d\n", GetLastError()); > + > + /* Query again the temp file unique id */ > + memset(&fid2, 0, sizeof(fid2)); > + res = pNtQueryInformationFile(h, &io, &fid2, sizeof fid2, FileIdInformation); > + ok(res == STATUS_SUCCESS, "can't get fid2, res %x\n", res); > + > + /* Verify we got the same unique id for the file */ > + ok(memcmp(&fid1, &fid2, sizeof fid1) == 0, "file id is not unique\n"); > + > + CloseHandle(h); > + > + h = create_temp_file(0); > + ok(h != NULL, "error creating new file %d\n", GetLastError()); > + > + memset(&fid2, 0, sizeof(fid2)); > + res = pNtQueryInformationFile(h, &io, &fid2, sizeof fid2, FileIdInformation); > + ok(res == STATUS_SUCCESS, "can't get new fid2, res %x\n", res); > + > + /* Verify we got the different unique id for the new file */ > + ok(memcmp(&fid1, &fid2, sizeof fid1) != 0, "file id is not unique\n"); > + > + CloseHandle(h); > + DeleteFileA(buffer); > +} > + > static void test_file_all_information(void) > { > IO_STATUS_BLOCK io; > @@ -4262,4 +4321,5 @@ START_TEST(file) > test_file_disposition_information(); > test_query_volume_information_file(); > test_query_attribute_information_file(); > + test_file_id_information(); > } > diff --git a/include/winternl.h b/include/winternl.h > index 891b6a7..2f2ea86 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -571,6 +571,15 @@ typedef struct _FILE_INTERNAL_INFORMATION { > LARGE_INTEGER IndexNumber; > } FILE_INTERNAL_INFORMATION, *PFILE_INTERNAL_INFORMATION; > > +typedef struct _FILE_ID_128 { > + UCHAR Identifier[16]; > +} FILE_ID_128, *PFILE_ID_128; > + > +typedef struct _FILE_ID_INFORMATION { > + ULONGLONG VolumeSerialNumber; > + FILE_ID_128 FileId; > +} FILE_ID_INFORMATION, *PFILE_ID_INFORMATION; > + > typedef struct _FILE_EA_INFORMATION { > ULONG EaSize; > } FILE_EA_INFORMATION, *PFILE_EA_INFORMATION; > -- 2.9.3 >

1 0

RE: [PATCH 8/9] server: Added server side mamed pipe read and write implementation and use it for message mode pipes.
by wylda＠volny.cz 10 Feb '17

10 Feb '17

Hi, mamed vs. named? W.

1 0

Re: ntdll: Fixed LdrUnloadDll may recursion unload same dll
by Sebastian Lackner 10 Feb '17

10 Feb '17

On 09.02.2017 10:39, 谢威 wrote: > From 3b5efb522f3ef46b009e6a159a605e087e8841a9 Mon Sep 17 00:00:00 2001 > From: Wei xie <xiewei(a)linuxdeepin.com> > Date: Thu, 19 Jan 2017 14:55:44 +0800 > Subject: [PATCH] ntdll: Fixed LdrUnloadDll may recursion unload same dll > > Signed-off-by: Wei xie <xiewei(a)linuxdeepin.com> > --- > dlls/ntdll/loader.c | 20 +++++++++++++++----- > 1 file changed, 15 insertions(+), 5 deletions(-) > > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 74feb97..8762917 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -64,7 +64,7 @@ WINE_DECLARE_DEBUG_CHANNEL(pid); > typedef DWORD (CALLBACK *DLLENTRYPROC)(HMODULE,DWORD,LPVOID); > > static BOOL process_detaching = FALSE; /* set on process detach to avoid deadlocks with thread detach */ > -static int free_lib_count; /* recursion depth of LdrUnloadDll calls */ > +static int free_lib_count = 0; /* recursion depth of LdrUnloadDll calls */ This isn't really necessary, all static variables are initialized to zero. > > static const char * const reason_names[] = > { > @@ -2859,7 +2859,7 @@ static void MODULE_FlushModrefs(void) > * > * The loader_section must be locked while calling this function. > */ > -static void MODULE_DecRefCount( WINE_MODREF *wm ) > +static void MODULE_DecRefCount( WINE_MODREF *wm , BOOL bDeps) > { > int i; > > @@ -2872,13 +2872,13 @@ static void MODULE_DecRefCount( WINE_MODREF *wm ) > --wm->ldr.LoadCount; > TRACE("(%s) ldr.LoadCount: %d\n", debugstr_w(wm->ldr.BaseDllName.Buffer), wm->ldr.LoadCount ); > > - if ( wm->ldr.LoadCount == 0 ) > + if ( wm->ldr.LoadCount == 0 && bDeps) > { > wm->ldr.Flags |= LDR_UNLOAD_IN_PROGRESS; > > for ( i = 0; i < wm->nDeps; i++ ) > if ( wm->deps[i] ) > - MODULE_DecRefCount( wm->deps[i] ); > + MODULE_DecRefCount( wm->deps[i] , TRUE ); > > wm->ldr.Flags &= ~LDR_UNLOAD_IN_PROGRESS; > } > @@ -2893,6 +2893,7 @@ NTSTATUS WINAPI LdrUnloadDll( HMODULE hModule ) > { > WINE_MODREF *wm; > NTSTATUS retv = STATUS_SUCCESS; > + static HMODULE first_recursion_module = 0; > > if (process_detaching) return retv; > > @@ -2900,13 +2901,19 @@ NTSTATUS WINAPI LdrUnloadDll( HMODULE hModule ) > > RtlEnterCriticalSection( &loader_section ); > > + if (0 == free_lib_count) > + first_recursion_module = hModule; > + > free_lib_count++; > if ((wm = get_modref( hModule )) != NULL) > { > TRACE("(%s) - START\n", debugstr_w(wm->ldr.BaseDllName.Buffer)); > > /* Recursively decrement reference counts */ > - MODULE_DecRefCount( wm ); > + if (0 != free_lib_count && first_recursion_module == hModule) > + MODULE_DecRefCount( wm , FALSE ); > + else > + MODULE_DecRefCount( wm , TRUE ); At the location above free_lib_count will always be != 0 - this means that your patch basically disables unloading of dependencies completely. Do you have a small testcase for the problem you are trying to fix? > > /* Call process detach notifications */ > if ( free_lib_count <= 1 ) > @@ -2922,6 +2929,9 @@ NTSTATUS WINAPI LdrUnloadDll( HMODULE hModule ) > > free_lib_count--; > > + if (0 == free_lib_count) > + first_recursion_module = 0; > + > RtlLeaveCriticalSection( &loader_section ); > > return retv; > -- 2.10.2 > > >

1 0

Re: [PATCH 06/16] ntdll: Added support for immediate success returns in server_read_file.
by Alexandre Julliard 10 Feb '17

10 Feb '17

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -588,10 +588,22 @@ static NTSTATUS server_read_file( HANDLE handle, HANDLE event, PIO_APC_ROUTINE a > if (wait_handle) > { > NtWaitForSingleObject( wait_handle, (options & FILE_SYNCHRONOUS_IO_ALERT), NULL ); > - status = io->u.Status; > NtClose( wait_handle ); > + return io->u.Status; > + } > + > + if (status == STATUS_SUCCESS || status == STATUS_BUFFER_OVERFLOW) > + { > + io->u.Status = status; > + io->Information = total; > + if (event) NtSetEvent( event, NULL ); > + if (apc) NtQueueApcThread( GetCurrentThread(), (PNTAPCFUNC)apc, > + (ULONG_PTR)apc_context, (ULONG_PTR)io, 0 ); > } > + else if (status != STATUS_PENDING && event) > + NtResetEvent( event, NULL ); > > + if (cvalue && status != STATUS_PENDING) NTDLL_AddCompletion( handle, cvalue, status, total ); I think it would be cleaner to do these on the server-side, the same way it's done for the asynchronous case. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/2] d2d1: Added support for ID2D1GdiInteropRenderTarget interface
by Henri Verbeet 10 Feb '17

10 Feb '17

On 10 February 2017 at 13:00, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT STDMETHODCALLTYPE d2d_gdi_interop_render_target_GetDC(ID2D1GdiInteropRenderTarget *iface, > + D2D1_DC_INITIALIZE_MODE mode, HDC *dc) > +{ > + struct d2d_d3d_render_target *render_target = impl_from_ID2D1GdiInteropRenderTarget(iface); > + IDXGISurface1 *surface; > + HRESULT hr; > + > + TRACE("iface %p, mode %d, dc %p.\n", iface, mode, dc); > + > + if (FAILED(hr = d2d_d3d_render_target_get_surface(render_target, &surface))) > + return hr; > + > + hr = IDXGISurface1_GetDC(surface, mode != D2D1_DC_INITIALIZE_MODE_COPY, dc); > + IDXGISurface1_Release(surface); > + > + return hr; > +} > + > +static HRESULT STDMETHODCALLTYPE d2d_gdi_interop_render_target_ReleaseDC(ID2D1GdiInteropRenderTarget *iface, > + const RECT *update) > +{ > + struct d2d_d3d_render_target *render_target = impl_from_ID2D1GdiInteropRenderTarget(iface); > + IDXGISurface1 *surface; > + HRESULT hr; > + > + TRACE("iface %p, update rect %s.\n", iface, wine_dbgstr_rect(update)); > + > + if (FAILED(hr = d2d_d3d_render_target_get_surface(render_target, &surface))) > + return hr; > + > + hr = IDXGISurface1_ReleaseDC(surface, update); This discards "const". > + IDXGISurface1_Release(surface); > + > + return hr; > +} > + Should this sync/flush in case of e.g. a WIC bitmap render target?

1 0

Re: [PATCH 1/7] gdiplus: Make GpBitmap->bitmapbits access thread safe
by Vincent Povirk 10 Feb '17

10 Feb '17

Copying the lock value in move_bitmap seems wrong to me, as it breaks any locks on the destination. Locking the source doesn't make sense because the caller is supposed to control the only reference to it. I'm not sure it makes sense in free_image_data either, as it leaves the image in an invalid state. Anything calling it should have a lock if this is important. I think it is possible to get unlock != true, when GdipImageRotateFlip calls GdipBitmapLockBits.

2 1

Re: [PATCH 2/7] gdiplus: Initialize bitmap bits for reading in GdipBitmapLockBits when ImageFlagsReadOnly is specified
by Dmitry Timoshkov 10 Feb '17

10 Feb '17

Piotr Caban <piotr(a)codeweavers.com> wrote: > /* Make sure we can convert to the requested format. */ > - if (flags & ImageLockModeRead) > + if ((flags & ImageLockModeRead) || (bitmap->image.flags & ImageFlagsReadOnly)) Is there a test for this behaviour? -- Dmitry.

2 3

Re: Participating in Outreachy
by Austin English 10 Feb '17

10 Feb '17

Thanks all! -- -Austin GPG: 14FB D7EA A041 937B On Feb 9, 2017 6:55 AM, "Aric Stewart" <aric(a)codeweavers.com> wrote: On 2/9/17 2:16 AM, Michael Stefaniuc wrote: > On 02/08/2017 11:07 PM, Jeremy White wrote: >> On 02/08/2017 03:45 PM, Marcus Meissner wrote: >>> On Wed, Feb 08, 2017 at 11:12:08AM -0700, Erich E. Hoover wrote: >>>> On Wed, Feb 8, 2017 at 11:00 AM, André Hentschel <nerv(a)dawncrow.de> wrote: >>>>> ... >>>>> The website says 6500$ or sponsored by another org: >>>>> https://wiki.gnome.org/Outreachy/Admin/InfoForOrgs#Action >>>> >>>> Clearly I should have read further ;) I don't know how our benevolent >>>> funding overlords feel about this, but it seems like a good idea to >>>> me. We did spend a lot of time at WineConf trying to figure out ways >>>> to get more people to participate, maybe this project can help. >>> >>> If the 6500 US$ figure is the minimum amount of money, then I would say no. >> >> Sorry, I was coy earlier; I was waiting on some feedback from Karen. >> >> To be clear, CodeWeavers will sponsor it and provide the $6,500. So if > Thank you very much! > >> we have someone to volunteer to coordinate, and a few people willing to >> mentor, we should be good. (I already have Stefan, so we have game >> related stuff covered). > I can mentor too and/or be a backup for Austin on the coordination part. > Though for the mentoring part the usual disclaimer applies: my Wine > technical knowledge is rather broad but very shallow. > > bye > michael > > I am willing and interested in mentoring. I have not been as active recently but still feel like I could help. Sign me up. -aric

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel