- wine-devel - winehq.org

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

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