March 2016 - Wine-Devel - list.winehq.org

Re: [v8 1/6] d3dx9: Implement preshader parsing.

by Matteo Bruni

2016-03-29 17:22 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > +enum pres_reg_tables > +{ > + PRES_REGTAB_IMMED, /* immediate double constants from CLIT */ I don't quite recall, I might be contradicting my own earlier comments here but at this point this comment doesn't seem to add much. General (and late) note, we usually tend to be more verbose with variable or type names and avoid too cryptic abbreviations. I don't think it's worth changing everything now though. > +struct d3dx_preshader > +{ > + struct d3dx_regstore regs; > + > + unsigned int ins_count; > + struct d3dx_pres_ins *ins; > + > + struct d3dx_const_tab inputs; > +}; > + > + > +struct d3dx_param_eval That double empty line seems unnecessary. > -HRESULT d3dx_create_param_eval(struct d3dx9_base_effect *base_effect, void *byte_code, unsigned int byte_code_size, > +enum pres_ops > +{ > + PRESHADER_OP_NOP, > + PRESHADER_OP_MOV, > + PRESHADER_OP_MAX_ENUM > +}; Maybe rename _MAX_ENUM to _UNKNOWN? At least for this patch series you don't really need that enum value though (see below). > +static HRESULT regstore_alloc_table(struct d3dx_regstore *rs, unsigned int table) > +{ > + unsigned int size; > + > + size = rs->table_sizes[table] * table_info[table].reg_component_count * table_info[table].component_size; > + if (size) > + { > + rs->tables[table] = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); > + rs->table_value_set[table] = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*rs->table_value_set[table]) * > + ((rs->table_sizes[table] + PRES_BITMASK_BLOCK_SIZE - 1) / PRES_BITMASK_BLOCK_SIZE)); Indentation. > +static void regstore_set_values(struct d3dx_regstore *rs, unsigned int table, void *data, > + unsigned int start_offset, unsigned int count) > +{ > + unsigned int block_idx, start, end, start_block, end_block; > + > + if (!count) > + return; > + > + memcpy((BYTE *)rs->tables[table] + start_offset * table_info[table].component_size, > + data, count * table_info[table].component_size); Indentation. > + for (i = 0; i < PRESHADER_OP_MAX_ENUM; ++i) > + if (ins_code == pres_op_info[i].opcode) > + break; > + if (i == PRESHADER_OP_MAX_ENUM) > + { > + FIXME("Unknown opcode %#x, raw %#x.\n", ins_code, ins_raw); > + return NULL; > + } I'd use ARRAY_SIZE(pres_op_info) instead of PRESHADER_OP_MAX_ENUM. > + cdesc = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*cdesc) * desc.Constants); > + inputs_param = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*inputs_param) * desc.Constants); AFAICS neither really needs HEAP_ZERO_MEMORY. You should also check those allocations and bail out if either one fails. > +static void update_table_sizes_consts(unsigned int *table_sizes, struct d3dx_const_tab *ctab) > +{ > + unsigned int i, table, max_register; > + > + for (i = 0; i < ctab->input_count; ++i) > + { > + max_register = ctab->inputs[i].RegisterIndex + ctab->inputs[i].RegisterCount; > + table = ctab->regset2table[ctab->inputs[i].RegisterSet]; > + if (table < PRES_REGTAB_COUNT) > + table_sizes[table] = max(table_sizes[table], max_register); > + } > +} > + > +static void update_table_size(unsigned int *table_sizes, unsigned int table, unsigned int offset) > +{ > + table_sizes[table] = max(table_sizes[table], get_reg_offset(table, offset) + 1); > +} Why not use it also in update_table_sizes_consts()? The "table < PRES_REGTAB_COUNT" check should then go into the update_table_size() helper. > + if (const_count > UINT_MAX / sizeof(double)) > + { > + WARN("Invalid immediate constants count %u.\n", const_count); > + return NULL; > + } > + if (p - ptr + const_count * (sizeof(double) / sizeof(unsigned int)) >= count) > + { > + WARN("Byte code buffer ends unexpectedly.\n"); > + return NULL; > + } The first check seems unnecessary, if the idea was to avoid integer overflows in the second check you can rewrite that one instead (e.g. by dividing by sizeof(unsigned int) both sides of the inequality). That second check can probably be improved by verifying that the constants fit into the CLIT comment instead (see below). BTW, the function return type is HRESULT, those returns generate warnings for me. > + pres->ins = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*pres->ins) * pres->ins_count); You should probably check this allocation too. > + for (i = 0; i < pres->ins_count; ++i) > + { > + unsigned int *ptr_next; > + > + ptr_next = parse_pres_ins(p, count, &pres->ins[i]); > + if (!ptr_next) > + return D3DXERR_INVALIDDATA; > + count -= ptr_next - p; > + p = ptr_next; > + } > + > + if (!count) > + { > + WARN("Byte code buffer ends unexpectedly.\n"); > + return D3DXERR_INVALIDDATA; > + } These kinds of size checks probably work but they are somewhat hard to follow. You could instead check the size of each comment section (making sure that it doesn't overflow the whole bytecode buffer) and then check that you don't go outside of each comment while parsing it. find_bytecode_comment() could do the first check before returning and, for example, also return the comment size so that the caller can use it to validate the relevant accesses. Hopefully what I mean is clear enough, otherwise as usual feel free to ask. > +err_out: > + FIXME("Error creating parameter evaluator.\n"); > + d3dx_free_param_eval(peval); > *peval_out = NULL; > - return E_NOTIMPL; > + return; > +} That return is now unnecessary.

March 31, 2016

Re: [PATCH 2/2] d3dx10: Add D3DX10UnsetAllDeviceObjects stub

by Matteo Bruni

2016-03-29 9:07 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Reference: https://bugs.winehq.org/show_bug.cgi?id=27035 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> Applying: d3dx10: Add D3DX10UnsetAllDeviceObjects stub .git/rebase-apply/patch:35: new blank line at EOF. + .git/rebase-apply/patch:52: new blank line at EOF. + warning: 2 lines add whitespace errors. Looks okay otherwise.

March 31, 2016

Re: [PATCH 5/5] wined3d: Alpha test emulation for core profile contexts.

by Matteo Bruni

2016-03-31 22:58 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 31 March 2016 at 19:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> + shader_addline(buffer, "if (alpha_test)\n"); >> + if (alpha_func != WINED3D_CMP_NEVER) >> + shader_addline(buffer, " if (!(%s[0].a %s alpha_ref))\n", >> + get_fragment_output(gl_info), comparison_operator[alpha_func - WINED3D_CMP_NEVER]); >> + shader_addline(buffer, " discard;\n"); > Is there really an advantage to having the "alpha_test" uniform > instead of just mapping disabled alpha test to WINED3D_CMP_ALWAYS? The advantage is to avoid creating two shader variants for alpha test enabled vs disabled and flipping between the two when the WINED3D_RS_ALPHATESTENABLE state is toggled. I only have some limited empiric evidence but it seems like changing the alpha test function is very rare in practice while toggling the alpha test enabled / disabled is relatively common. >> @@ -973,6 +981,7 @@ struct ps_compile_args { >> WORD texcoords_initialized; /* MAX_TEXTURES, 8 */ >> BOOL pointsprite; >> BOOL flatshading; >> + enum wined3d_cmp_func alpha_func; >> }; >> >> enum fog_src_type { >> @@ -2022,6 +2031,7 @@ struct ffp_frag_settings >> unsigned char pointsprite : 1; >> unsigned char flatshading : 1; >> unsigned char padding : 5; >> + enum wined3d_cmp_func alpha_func; > "alpha_func" only needs 4 bits (3 if you just mask the 4th bit), so > would still fit in the padding. That applies somewhat to struct > ps_compile_args as well, although we may care less there. Yes, it can be compressed. I'll have a look.

March 31, 2016

Re: [PATCH 5/5] wined3d: Alpha test emulation for core profile contexts.

by Henri Verbeet

On 31 March 2016 at 19:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + shader_addline(buffer, "if (alpha_test)\n"); > + if (alpha_func != WINED3D_CMP_NEVER) > + shader_addline(buffer, " if (!(%s[0].a %s alpha_ref))\n", > + get_fragment_output(gl_info), comparison_operator[alpha_func - WINED3D_CMP_NEVER]); > + shader_addline(buffer, " discard;\n"); Is there really an advantage to having the "alpha_test" uniform instead of just mapping disabled alpha test to WINED3D_CMP_ALWAYS? > @@ -973,6 +981,7 @@ struct ps_compile_args { > WORD texcoords_initialized; /* MAX_TEXTURES, 8 */ > BOOL pointsprite; > BOOL flatshading; > + enum wined3d_cmp_func alpha_func; > }; > > enum fog_src_type { > @@ -2022,6 +2031,7 @@ struct ffp_frag_settings > unsigned char pointsprite : 1; > unsigned char flatshading : 1; > unsigned char padding : 5; > + enum wined3d_cmp_func alpha_func; "alpha_func" only needs 4 bits (3 if you just mask the 4th bit), so would still fit in the padding. That applies somewhat to struct ps_compile_args as well, although we may care less there.

March 31, 2016

Re: [PATCH v2 1/5] ddraw/tests: Add a test for color varyings clamping.

by Marvin

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=21816 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

March 31, 2016

wine-1.8.2-rc1 Available

by Michael Stefaniuc

Hello guys, sorry for the delay in preparing the next Stable release. Too much stuff going on and I couldn't focus on Wine. I have pushed today an informal wine-1.8.2-rc1 to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ 1.8.2-rc1 is fairly complete(*) from my point of view. The plan is to give the interested developers about a week time to look at the proposed 1.8.2. On Wednesday next week I plan to hand over the "final" to Alexandre, with a probable release on Friday next week. Depending on the feedback / outcry I might do another release candidate before Wednesday. (*) I wanted to include: Bug 39092 - Regression introduced with xaudio2_8 too. It is a beast to cherry-pick due to the dependencies and dependencies of dependencies... 1.8.2-rc1 is already big enough: - I have included this time interesting commits I have found interesting, mostly based on the additional information in the patch submission. - 32 bugs fixed (of which 6 are regressions). - 86 patches (of which 7 are tests only). - With test file changes filtered out: 95 files changed, 1873 insertions(+), 770 deletions(-) - The biggest "offender" for those changes is Bug 25086 - Multiple games and applications need kernel32.GetLogicalProcessorInformationEx implementation - I have attached the filtered diffstat While I have added a (lightweight) tag to it, I didn't bother with the rest of the release stuff. I have included that info in this email though. ---------------------------------------------------------------- Bugs fixed in 1.8.2-rc1 (total 32) [12652] Tom Clancy's Rainbow Six: Vegas 2 fails to launch (number of quality levels for D3DMULTISAMPLE_NONMASKABLE multiple-sample type must not exceed 8) [13683] Ultima IX: Mouse pointer missing when reading books, under inventory [14617] Multiple Visual Basic 5/6 applications using ActiveX components depend on Standard OLE Types Typelib which is missing from 'olepro32.dll' [15473] Adobe After Effects 4 crashes on startup [25086] Multiple games and applications need kernel32.GetLogicalProcessorInformationEx implementation (CPU-Z 1.72, Splinter Cell: Blacklist, Adobe CC 2015, Kontakt 5) [30687] Powerpoint 2003/2007: embedded video play/pause on click no longer works [32827] Legrand XlPro 3 (MFC app) crashes on startup (failure to load registry-free COM servers via app hook, 'OleCreate' must ignore HRESULT of 'IOleObject::GetMiscStatus') [33787] IE8 crashes on new tab [33988] Star Wars: The Force Unleashed II - Crashes with a page fault [34174] MinGW installer 0.5-beta-20120426-1 fails to process log files (sharing violation on temp file used for piped output) [34318] Multiple games and applications need ntdll.dll.EtwRegisterTraceGuidsW (Process Hacker 2.x, Far Cry 4) [35187] Jade Empire Special Edition configuration tool always resetting video settings [36013] bleem! 1.4 (PlayStation emulator) fails on startup, complaining with 'Not enough memory to load program!' [37115] Calling ReadFile from WINBASEAPI (WinBase.h) with zero read length causes hang [37288] Not implemented feature System.Drawing.Pen.ResetTransform() [37536] Native MSVCP120.dll override requires implementation of msvcr120.dll._W_Gettnames (Desura client) [37556] CompareStringW should abort on the first nonmatching character to avoid invalid memory access. [38314] Mouse Wheel doesn't work for Jagged Alliance 2 version 1.13 (it uses MOUSEHOOKSTRUCTEX) [39591] Crimzon Clover: Page fault on launch [39838] Wreckfest Server: Crashes at startup, unimplemented function KERNEL32.dll.GetConsoleScreenBufferInfoEx & SetConsoleScreenBufferInfoEx [39866] XIIZeal (steam) immediately exits on start [39875] Starcraft can't see Direct Cable Connection games hosted on another computer [39878] Diablo II does not start on 64bit system with more than 2GB VRAM cards [39908] SuperTux 0.3.5a crashes on startup, needs msvcr120.dll.strtof [40021] IDEA v1.7 fails to start [40053] Romance of the Three Kingdoms 13 (三國志13) fails to start [40083] Heroes of the Storm Freezes/Crashes after its recent updates [40129] MSI Reading and Writing Behaves differently than Windows [40147] Assertion 'm->state == STATE_PASSIVE' failed at pulse/mainloop.c:827 on starting Skype 7.18.0.112 [40201] EccoPro only works on Wine 1.6.2 [40204] Steam client fails to start with UmePlus font installed, when running in dwrite mode [40222] IMalloc(Spy)::Free nullptr ---------------------------------------------------------------- Changes since 1.8.1: Alex Henrie (1): ntdll: Finish serial reads of size 0 immediately. Alexandre Julliard (3): make_unicode: Fix typo in Indic syllable table generation. server: Implement serial port read interval timeouts. advapi32: Fix null termination in RegQueryInfoKeyA. Alistair Leslie-Hughes (7): user32: Don't crash in DrawTextEx when tab length is zero. olepro32: Add typelib resource. include: Add GdipGetPenTransform, GdipSetPenTransform declarations. gdiplus/tests: Add Pen Transform tests. gdiplus: Implement GdipGetPenTransform. gdiplus: Implement GdipSetPenTransform. gdiplus: Implement GdipResetPenTransform. Andrew Eikum (5): oleaut32: Don't clear BSTR size. mciqtz: Implement MCI_RESUME. xaudio2: Handle openal source allocation failure. winepulse.drv: Check that the server connection actually succeeded. ntdll: Implement SystemLogicalProcessorInformationEx. André Hentschel (2): winemaker: Markup fixes in German translation. ntdll: Set TPIDRURW also on ARMv8-A. Anton Baskanov (1): quartz: Set the result to 1.0 in FilterGraph::GetRate. Aric Stewart (1): winejoystick.drv: Initialize unhandled dwPOV to JOY_POVCENTERED. Austin English (1): kernel32: Add GetConsoleScreenBufferInfoEx/SetConsoleScreenBufferInfoEx stubs. Bernhard Übelacker (2): include: Implement todo_wine_if for usage in wine tests. msvcr120: Implement strtof and _strtof_l. Charles Davis (3): winex11.drv: Actually query the swap method attribute. dwrite: Fix typos, and fix definition of Mac LangCodes for Welsh and up. configure: Check for __builtin_ms_va_list on all x86_64 platforms. Christopher Thielen (1): user32: A window may be notified with WM_CAPTURECHANGED about itself if SetCapture() is called twice. Dmitry Timoshkov (1): kernel32: CompareStringW should abort on the first nonmatching character to avoid an invalid memory access. Frédéric Delanoy (1): winemaker: Markup fixes in French translation. Hans Leidekker (2): msiexec: Fix manpage markup for repair and logging modifiers. msi: Fix the CHAR column type. Henri Verbeet (1): ntdll: Add special handling for int $0x2d exceptions. Hugh McMaster (1): reg: Remove stub output from the 'add' and 'delete' functions. Huw D. M. Davies (1): ole32: The type of the size of IMalloc'ed blocks is SIZE_T. Jacek Caban (4): ntdll: Pass SYNCHRONIZE flag in NtOpenFile and NtCreateFile calls. ntdll: Don't call NtOpenKeyEx directly from NtOpenKey. kernel32: Don't set unconditionally SECTION_QUERY flag in OpenFileMapping. ntdll: Moved RegisterTraceGuids[AW] implementation to ntdll. Jens Reyer (2): loader: Fix macro-not-defined error from man. winemaker: Fix macro-not-defined errors from man. Józef Kucia (3): wined3d: Validate render state in wined3d_device_set_render_state(). wined3d: Limit amount of video memory for older Windows versions. wined3d: Allow to query if surface format supports gamma correction. Kira Backes (1): user32: Add MOUSEHOOKSTRUCTEX for mouse wheel support. Marcus Meissner (1): manpages: Markup fixes. Matteo Bruni (2): wined3d: Limit the number of WINED3D_MULTISAMPLE_NON_MASKABLE quality levels reported. wined3d: Add WINED3DFMT_FLAG_RENDERTARGET to WINED3DFMT_B5G5R5X1_UNORM. Michael Müller (6): msvideo.dll16: Translate 16 bit address in lparam for MCIWNDM_SETTIMEFORMATA message. include: Add definitions for Win8 pseudo handles. server: Add support for Win8 pseudo handles. advapi32/tests: Add tests for Win8 pseudo handles. kernel32: Allow to pass NULL as old protection in VirtualProtect for Win9x compatibility. user32: Preserve beginning of extra data for MDI windows. Miklós Máté (2): winex11: Add 1280x960 resolution. wined3d: Warn only once about unsupported wrap state. Nikolay Sivov (12): ole2disp: Implement SafeArrayGetDim(). ole2disp: Implement SafeArrayGetElemsize(). ole2disp: Implement SafeArrayLock()/SafeArrayUnlock(). ole2disp: Implement SafeArrayAccessData()/SafeArrayUnaccessData(). include: Fix IsBad* prototypes. ctl3d32: Claim success in Ctl3dRegister(). ole32: Ignore GetMiscStatus() returned value in OleCreate(). dwrite: Handle font data initialization failure when building collections. ntdll/tests: Some tests for NtQuerySystemInformationEx(). ntdll: Add NtQuerySystemInformationEx() stub. kernel32: Forward GetLogicalProcessorInformationEx() to ntdll. ole32: Don't call spy on IMalloc::Free(NULL). Paul Gofman (1): d3dx9: Fix D3DXIntersectTri function. Piotr Caban (5): msxml3: Update xmlNode reference count when nodes are merged in node_insert_before. msxml3: Store information about ignorrable whitespace nodes in xmlNode._private variable. msxml3: Reimplement node_get_text helper so it uses information about ignorred white space nodes. msxml3: Add support for CDATA nodes in node_get_text. msvcr110: Add _W_Gettnames implementation. Sebastian Lackner (13): vcomp/tests: Reenable architecture dependent tests. vcomp: Implement 64-bit atomic instructions. ntdll: Implement RtlInterlockedPushListSListEx and fix calling convention of RtlInterlockedPushListSList. kernel32/tests: Clean up interlocked SList tests. kernel32: Forward InterlockedPushListSList[Ex] to ntdll. cmd: Fix sharing permissions of piped output files. vmm.vxd: Fix protection flags passed to VirtualAlloc. ntdll: Mimic Windows behaviour when calling debug service. ntdll: Implement handling of int $0x2d for x86_64. ntdll/tests: Add more tests for calling int $0x2d on x86 and x86_64. ntdll/tests: Add additional tests for instruction pointer in debug service tests. ntdll/tests: Add separate tests for exception handling of int $0x3. ntdll: Fix up instruction pointer in context for EXCEPTION_BREAKPOINT on x86_64. bye michael

March 31, 2016

Re: [PATCH 1/2] d3dx10: Add D3D10CreateEffectPoolFromMemory stub

by Józef Kucia

On Tue, Mar 29, 2016 at 9:07 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > dlls/d3d10/d3d10.spec | 2 +- > dlls/d3d10/d3d10_main.c | 9 +++++++++ > dlls/d3d10_1/d3d10_1.spec | 2 +- > include/d3d10effect.h | 2 ++ The subject prefix should be "d3d10:". > +HRESULT WINAPI D3D10CreateEffectPoolFromMemory(void *data, SIZE_T data_size, UINT fx_flags, > + ID3D10Device *device, ID3D10EffectPool **effectpool) > +{ Please use "effect_pool" instead of "effectpool", mainly for consistency (snake_case). > + FIXME("data %p, data_size %lu, fx_flags %#x, device %p, effectpool %p.\n", > + data, data_size, fx_flags, device, effectpool); The FIXME() message should end with "stub!" or "stub.". > + return E_NOTIMPL; > +} > + I think you can remove this additional empty line. > diff --git a/include/d3d10effect.h b/include/d3d10effect.h > index 1494894..5dafdae 100644 > --- a/include/d3d10effect.h > +++ b/include/d3d10effect.h > @@ -832,6 +832,8 @@ HRESULT WINAPI D3D10CompileEffectFromMemory(void *data, SIZE_T data_size, const > ID3D10Blob **effect, ID3D10Blob **errors); > HRESULT WINAPI D3D10CreateEffectFromMemory(void *data, SIZE_T data_size, UINT flags, > ID3D10Device *device, ID3D10EffectPool *effect_pool, ID3D10Effect **effect); > +HRESULT WINAPI D3D10CreateEffectPoolFromMemory(void *data, SIZE_T data_size, UINT fx_flags, > + ID3D10Device *device, ID3D10EffectPool **effectpool); It should be "effect_pool" instead of "effectpool".

March 31, 2016

Re: [PATCH (try2)] setupapi: Fix spec entries for handle parameters

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > On Thu, Mar 31, 2016 at 04:34:27AM +0200, Sebastian Lackner wrote: >> Is there any specific reason why you want to change that? Using "long" >> for handles is usually perfectly fine and it depends on the exact >> implementation details if its a pointer or just an index into a handle table. > > I thought that ptr and long were different widths on 64-bit, which > could lead to incorrect parameter dumping in relay logs. If that's not > the case, then ignore the patch. ptr and long are identical on both 32-bit and 64-bit. The distinction only matters for 16-bit. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2016

Re: [PATCH (try2)] setupapi: Fix spec entries for handle parameters

by Andrew Eikum

On Thu, Mar 31, 2016 at 04:34:27AM +0200, Sebastian Lackner wrote: > On 30.03.2016 17:00, Andrew Eikum wrote: > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > > --- > > > > try2: Turns out there's a whole bunch more of these. I think I got > > most/all of them. > > > > dlls/setupapi/setupapi.spec | 118 ++++++++++++++++++++++---------------------- > > 1 file changed, 59 insertions(+), 59 deletions(-) > > Is there any specific reason why you want to change that? Using "long" > for handles is usually perfectly fine and it depends on the exact > implementation details if its a pointer or just an index into a handle table. > I thought that ptr and long were different widths on 64-bit, which could lead to incorrect parameter dumping in relay logs. If that's not the case, then ignore the patch. Andrew

March 31, 2016

Re: [PATCH] msvcr120: Add scalbn

by Piotr Caban

On 03/31/16 08:45, Daniel Lehman wrote: @ cdecl scalbn(double long) MSVCRT__scalb It will not compile in case of i386 wine. MSVCRT__scalb is defined inside ifdef. Thanks, Piotr

March 31, 2016

Re: Need some advice on shell32

by Alexandre Julliard

Mathy Vanvoorden <mathy(a)vanvoorden.be> writes: > So by that reasoning it would be better then to in shell32 implement a > 'simpler' version: show dotted files when the option is activated, but > do not hide stuff like /dev, /proc and WINEPREFIX (since they are > native to Unix)? That's probably better, yes. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2016

Re: ntoskrnl.exe: Make IoAllocateIrp not crash on negative values. (try 2)

by Sebastian Lackner

On 29.03.2016 22:13, Bernhard Übelacker wrote: > https://bugs.winehq.org/show_bug.cgi?id=39734 > > This patch should avoid crash in acedrv11.sys. > IoAllocateIrp is called with a stack_size of -128. > Therefore ExAllocatePool gets a negative size value. > > Tested against Windows XP. > (See the test based on wine-staging "driver testing framework" attached to the bug.) > ( https://newtestbot.winehq.org/JobDetails.pl?Key=21722 testrun by Sebastian Lackner.) > > Try 1: https://www.winehq.org/pipermail/wine-patches/2016-March/148587.html > Review 1: https://www.winehq.org/pipermail/wine-devel/2016-March/112476.html > > Changes since try 1: > - Fix usage of wrong variable. > - Use a better name for variable. > - Simplify if statement. > > Signed-off-by: Bernhard Übelacker <bernhardu(a)vr-web.de> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) Thanks for the updated version. Could you maybe also add a couple of additional tests with charge_quota = TRUE? Since you are changing both versions, I'm fearing a bit that your changes could break other situations. If there are no unexpected test failures it looks good to me.

March 31, 2016

Re: [PATCH (try2)] setupapi: Fix spec entries for handle parameters

by Sebastian Lackner

On 30.03.2016 17:00, Andrew Eikum wrote: > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > --- > > try2: Turns out there's a whole bunch more of these. I think I got > most/all of them. > > dlls/setupapi/setupapi.spec | 118 ++++++++++++++++++++++---------------------- > 1 file changed, 59 insertions(+), 59 deletions(-) Is there any specific reason why you want to change that? Using "long" for handles is usually perfectly fine and it depends on the exact implementation details if its a pointer or just an index into a handle table.

March 31, 2016

Re: [PATCH 4/4] mshtml: Added IHTMLElement::outerText tests.

by Jacek Caban

On 03/30/16 19:25, Marvin wrote: > 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=21790 > > Your paranoid android. It seems that most IE version don't have limitation for usage with table elements, so there is no reason for us to have one. Please ignore the patch series, I will send better version tomorrow. Jacek

March 30, 2016

Re: [PATCH 4/4] mshtml: Added IHTMLElement::outerText tests.

by Marvin

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=21790 Your paranoid android. === wxppro (32 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === wvistau64 (32 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === w7u (32 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === w7pro64 (32 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === w8 (32 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === w864 (32 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === w1064 (32 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === wvistau64 (64 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === w7pro64 (64 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === w864 (64 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1 === w1064 (64 bit dom) === dom.c:6968: Test failed: put_outerText failed: 00000000 dom.c:6971: Test failed: expected len = 2, got 1

March 30, 2016

Re: Need some advice on shell32

by Mathy Vanvoorden

2016-03-30 4:50 GMT+02:00 Alexandre Julliard <julliard(a)winehq.org>: > The goal of the shell Unix folder is to show a view of the filesystem as > you would see it in a native Unix app, and it's using direct Unix calls > in order to do that. It allows showing symlinks, device files, etc. even > when we have to hide them in ntdll to avoid breaking apps. So I'm not > sure that replicating ntdll behavior's would be the right thing here. > So by that reasoning it would be better then to in shell32 implement a 'simpler' version: show dotted files when the option is activated, but do not hide stuff like /dev, /proc and WINEPREFIX (since they are native to Unix)?

March 30, 2016

Re: [PATCH] t2embed: Implement TTGetEmbeddingType()

by Nikolay Sivov

On 30.03.2016 13:05, Marvin wrote: > 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=21774 > > Your paranoid android. > > > === build (build) === > Make failed > > Probably didn't pick up configure changes, and new tests dir.

March 30, 2016

Re: [PATCH] t2embed: Implement TTGetEmbeddingType()

by Marvin

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=21774 Your paranoid android. === build (build) === Make failed

March 30, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Bernhard Übelacker

Hello Francois, Am 30.03.2016 um 09:46 schrieb Francois Gouget: > On Fri, 25 Mar 2016, Francois Gouget wrote: > > On Fri, 25 Mar 2016, Bernhard Übelacker wrote: > [...] >> one point that could be related is the usage of function local static >> variables. When all of these got the "static" removed, I do not get the >> failures anymore. However I could not prove this with testbot as an empty >> patch did also succeed. > > I have not found static directives that I could remove to fix the > dinput8 failures. Which test did it make a difference for? Could you > send a diff? > > All I could find to fix this is to add 'CFLAGS = -d -O0' in the test's > Makefile.in but that does seem like a nice workaround :-( I attached a diff to this mail or see https://testbot.winehq.org/JobDetails.pl?Key=21671 In my tests it started to fail in a vm when just one of these "statics" was left. Kind regards, Bernhard

March 30, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Francois Gouget

On Fri, 25 Mar 2016, Francois Gouget wrote: On Fri, 25 Mar 2016, Bernhard Übelacker wrote: [...] > one point that could be related is the usage of function local static > variables. When all of these got the "static" removed, I do not get the > failures anymore. However I could not prove this with testbot as an empty > patch did also succeed. I have not found static directives that I could remove to fix the dinput8 failures. Which test did it make a difference for? Could you send a diff? All I could find to fix this is to add 'CFLAGS = -d -O0' in the test's Makefile.in but that does seem like a nice workaround :-( -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

March 30, 2016

Re: Need some advice on shell32

by Alexandre Julliard

Mathy Vanvoorden <mathy(a)vanvoorden.be> writes: > 2016-03-29 17:49 GMT+02:00 Vincent Povirk <madewokherd(a)gmail.com>: > > I don't know why shell32 does this at all, rather than going > through > kernel32/ntdll like the rest of Wine. > > > My best guess is that shell32 existed before ntdll? > > So should I rewrite it to use ntdll then? > > Anyone else that can comment on this? The goal of the shell Unix folder is to show a view of the filesystem as you would see it in a native Unix app, and it's using direct Unix calls in order to do that. It allows showing symlinks, device files, etc. even when we have to hide them in ntdll to avoid breaking apps. So I'm not sure that replicating ntdll behavior's would be the right thing here. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2016

Re: ntoskrnl.exe: Make IoAllocateIrp not crash on negative values.

by Bernhard Übelacker

Hello Sebastian, Am 28.03.2016 um 08:02 schrieb Sebastian Lackner: > On 27.03.2016 20:27, Bernhard Übelacker wrote: >> https://bugs.winehq.org/show_bug.cgi?id=39734 >> >> Changes should avoid crash in acedrv11.sys. >> IoAllocateIrp is called with a stack_size of -128. >> >> Tested against Windows XP. >> (See the test based on wine-staging "driver testing framework".) > > For reference, here a testbot run which confirms that the change is correct (for XP/2003): > https://newtestbot.winehq.org/JobDetails.pl?Key=21722 > >> >> Signed-off-by: Bernhard Übelacker <bernhardu(a)vr-web.de> >> --- >> dlls/ntoskrnl.exe/ntoskrnl.c | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c >> index 36488a7..f2ccc61 100644 >> --- a/dlls/ntoskrnl.exe/ntoskrnl.c >> +++ b/dlls/ntoskrnl.exe/ntoskrnl.c >> @@ -592,15 +592,20 @@ PIRP WINAPI IoAllocateIrp( CCHAR stack_size, BOOLEAN charge_quota ) >> { >> SIZE_T size; >> PIRP irp; >> + CCHAR _stack_size = stack_size; >> >> TRACE( "%d, %d\n", stack_size, charge_quota ); >> >> - size = sizeof(IRP) + stack_size * sizeof(IO_STACK_LOCATION); >> + if (_stack_size <= 0 || (_stack_size > 1 && stack_size < 8)) >> + _stack_size = 8; > > I would suggest to use a different variable, its very easy to mix up "stack_size" > and "_stack_size". You even mixed it up yourself in the if() condition above. ;) > If you want, you can also simplify the condition to (stack_size < 8 && stack_size != 1). > >> + >> + size = sizeof(IRP) + _stack_size * sizeof(IO_STACK_LOCATION); >> irp = ExAllocatePool( NonPagedPool, size ); >> if (irp == NULL) >> return NULL; >> IoInitializeIrp( irp, size, stack_size ); >> - irp->AllocationFlags = IRP_ALLOCATED_FIXED_SIZE; >> + if (stack_size >= 1 && stack_size <= 8) >> + irp->AllocationFlags = IRP_ALLOCATED_FIXED_SIZE; >> if (charge_quota) >> irp->AllocationFlags |= IRP_LOOKASIDE_ALLOCATION; >> return irp; >> thanks for your review. I have sent an updated patch. Is the test attached to the bug worth to be included into wine-staging? Kind regards, Bernhard

March 29, 2016

Re: Need some advice on shell32

by Mathy Vanvoorden

2016-03-29 17:49 GMT+02:00 Vincent Povirk <madewokherd(a)gmail.com>: > I don't know why shell32 does this at all, rather than going through > kernel32/ntdll like the rest of Wine. > My best guess is that shell32 existed before ntdll? So should I rewrite it to use ntdll then? Anyone else that can comment on this? Mathy

March 29, 2016

Re: [PATCH] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v3).

by Henri Verbeet

On 29 March 2016 at 18:43, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > AddDestroyCallback would need to be implemened as seperate patches for > IDirect3DRMTexture*. Yeah, but it mostly comes down to adding a struct d3drm_object field to struct d3drm_texture, calling d3drm_object_add_destroy_callback() and d3drm_object_delete_destroy_callback() in the appropriate places, and some initialisation and cleanup code. Shouldn't be hard. > So the overall order of implementations/tests patches will be so: > > CreateObject implementation and test > InitFromImage implementation and test > CreateTexture implementation and test > IDirect3DRMObject function implementations for IDirect3DRMTexture*. > InitFromFile implementation and test > LoadTexture implementations > Yeah, that makes sense. The IDirect3DRMObject only need to be before InitFromFile(), so you could send them e.g. before the CreateObject() implementation as well, if you like.

March 29, 2016

Re: [PATCH] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v3).

by Aaryaman Vasishta

AddDestroyCallback would need to be implemened as seperate patches for IDirect3DRMTexture*. Using the BOOL avoids that, but I have a feeling these callbacks might be useful in games as well, so I'll implement these first before LoadTexture patches. So the overall order of implementations/tests patches will be so: CreateObject implementation and test InitFromImage implementation and test CreateTexture implementation and test IDirect3DRMObject function implementations for IDirect3DRMTexture*. InitFromFile implementation and test LoadTexture implementations If the order is not proper, do let me know. Thanks for the review! Cheers, Aaryaman On Tue, Mar 29, 2016 at 8:52 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 29 March 2016 at 17:01, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > Are there any existing examples within wine where a destroy callback was > > used in similar cases? > If you mean AddDestroyCallback() specifically, that's pretty specific > to d3drm and you'd be limited to test_Viewport() in the d3drm tests. > The concept of a callback that gets called on destruction is much more > generic of course, and in that case you should be able to find plenty. > E.g. surface_wined3d_object_destroyed() in d3d9. >

March 29, 2016

Re: Need some advice on shell32

by Vincent Povirk

I don't know why shell32 does this at all, rather than going through kernel32/ntdll like the rest of Wine.

March 29, 2016

Re: [PATCH] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v3).

by Henri Verbeet

On 29 March 2016 at 17:01, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > Are there any existing examples within wine where a destroy callback was > used in similar cases? If you mean AddDestroyCallback() specifically, that's pretty specific to d3drm and you'd be limited to test_Viewport() in the d3drm tests. The concept of a callback that gets called on destruction is much more generic of course, and in that case you should be able to find plenty. E.g. surface_wined3d_object_destroyed() in d3d9.

March 29, 2016

Re: [PATCH] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v3).

by Aaryaman Vasishta

On Tue, Mar 29, 2016 at 4:59 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 28 March 2016 at 20:02, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > v3: Add bitmap verification, use InitFromFile and other minor > improvements. > > > Implementing InitFromFile() should be a separate patch from > implementing LoadTexture(). > > > if (FAILED(hr = d3drm_texture_create(&object))) > > return hr; > > > > + if (FAILED(hr = > IDirect3DRMTexture_InitFromFile(&object->IDirect3DRMTexture_iface, > filename))) > > + { > > + d3drm_texture_destroy(object); > > + return hr; > > + } > > + > > + object->d3drm = iface; > > + IDirect3DRM_AddRef(iface); > It would be good to back this up with tests. It would seem more > natural to pass the IDirect3DRM interface to d3drm_texture_create(). > If that's how it's supposed to work, you can make that change in a > separate patch. > Right. > > > @@ -39,6 +40,9 @@ struct d3drm_texture > > IDirect3DRMTexture IDirect3DRMTexture_iface; > > IDirect3DRMTexture2 IDirect3DRMTexture2_iface; > > IDirect3DRMTexture3 IDirect3DRMTexture3_iface; > > + IDirect3DRM *d3drm; > > + D3DRMIMAGE *image; > > + BOOL internal_image_created; > You don't really need internal_image_created, you can probably just > add a destroy callback. > Are there any existing examples within wine where a destroy callback was used in similar cases? > This is very suspicious, since you always assign "object->d3drm" after > calling InitFromFile(). It's not backed up by tests either. > I think I had put that while debugging a segfault while the tests ran on wine. LoadTexture called InitFromFile first, which then AddRef'd IDirect3DRM. Since IDirect3DRM member wasn't initialized in the object by then, the if check is needed. Also since LoadTexture needs to AddRef only after IDirect3DRM after it's successfully loaded, I put the AddRef below d3drm_texture_load. I agree with all the other changes you mentioned. The leaks and signed local vars are definitely a problem. I'll fix them, divide the patches up and begin work on CreateObject first before submitting these again. Cheers, Aaryaman

March 29, 2016

Re: [v7 2/7] d3dx9: Implement preshader parsing.

by Matteo Bruni

2016-03-29 15:33 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > I removed all the return value checks from creating param evaluator to > let the program continue and not to fail effect creation, exactly as it > did without preshaders before. I have nothing to do with the return > value at the creation right now. At the same time, having such a > function with parsing and a lot of possible errors without return value > would seem very strange. Maybe we could keep the return value in case we > will need this in future? E. g. we may want to decide to fail shaders > creation on preshader parsing failure. Maybe we'll want to change that in the future but for now returning a value which isn't checked from an internal function doesn't seem very useful. I'd just drop the return value from d3dx_create_param_eval(), reintroducing that if and when necessary should be trivial. I'm fine with the other things you mentioned. Hopefully the various additional length checks won't make the code significantly more convoluted (but if you judge they do and resend without them it's okay too).

March 29, 2016

Re: [v7 2/7] d3dx9: Implement preshader parsing.

by Paul Gofman

On 03/29/2016 04:25 PM, Matteo Bruni wrote: > > I'm okay with printing the pointer or similar info but that kind of > trace is pretty ugly. You could trace the pointer when you allocate > the struct, or together with the struct state pointer / the state > parameter in the caller. I guess you can also leave the trace there, > if it says something like: > > TRACE("Created parameter evaluator %p.\n", *peval_out); This is almost exactly what I am suggesting in the next e-mail I've just sent. > BTW, notice that you are never checking the return value from > d3dx_create_param_eval(). You should either do that or remove the > return value from the function altogether. > I removed all the return value checks from creating param evaluator to let the program continue and not to fail effect creation, exactly as it did without preshaders before. I have nothing to do with the return value at the creation right now. At the same time, having such a function with parsing and a lot of possible errors without return value would seem very strange. Maybe we could keep the return value in case we will need this in future? E. g. we may want to decide to fail shaders creation on preshader parsing failure.

March 29, 2016

Re: [v7 2/7] d3dx9: Implement preshader parsing.

by Paul Gofman

On 03/29/2016 02:16 AM, Matteo Bruni wrote: > >> +static unsigned int *find_bytecode_comment(unsigned int *ptr, unsigned int fourcc) >> +{ >> + while ((*ptr & 0xffff) == 0xfffe) >> + { >> + if (*(ptr + 1) == fourcc) >> + return ptr + 2; >> + ptr += 1 + (*ptr >> 16); >> + } >> + return NULL; >> +} > This is probably paranoid but in theory a broken or malicious effect > could send you rummaging outside of the bytecode buffer so all the > offsets should be checked. I don't think it's critical in practice > i.e. I'll probably sleep just fine if you decide to ignore this > issue... I will pass through bytecode size parameter and add a size check. There is D3DXGetShaderConstantTable function used in another function taking the same bytecode reference and doing comment search in a similar way, and it does not have size parameter, so it will crash anyway on insane bytecode. The same is for d3d shader create functions. But those functions do not modify the memory at bytecode, and segfault on read access cannot be used alone to inject anything. At the same time parse_preshader writes to that pointer a 0xfffe0000 constant (restoring a memory a bit later) to make it suitable D3DXGetShaderConstantTable, so actually adding these checks does not seem much paranoid. > > > It depends on what is coming up next but maybe it would make sense to > add an enum for "PRES_REGTAB_IMMED + 1" (incidentally, > PRES_REGTAB_FIRST is never used in this patch series). PRES_REGTAB_FIRST was used in tables free function. I now removed _FIRST/_LAST, used 0/_COUNT instead, and introduced PRES_REGTAB_FIRST_SHADER to use it in parse_param_eval instead of 'PRES_REGTAB_IMMED + 1'. Please note that I introduced PRES_REGTAB_FIRST/_LAST in v3 patch series based on comments on v1, and should issue a possible endless loop warning :). I suggest that if there is still any concern regarding this enum maybe we could confirm its final form at this point? The current enum after my last edits looks like this: enum pres_reg_tables { PRES_REGTAB_IMMED, /* immediate double constants from CLIT */ PRES_REGTAB_CONST, PRES_REGTAB_OCONST, PRES_REGTAB_OBCONST, PRES_REGTAB_OICONST, PRES_REGTAB_TEMP, PRES_REGTAB_COUNT, PRES_REGTAB_FIRST_SHADER = PRES_REGTAB_CONST, }; > > + if (FAILED(regstore_alloc_table(&peval->pres.regs, i))) > + { > + hr = E_OUTOFMEMORY; > + goto err_out; > + } > + } > + > + if (TRACE_ON(d3dx)) > + dump_bytecode(byte_code, byte_code_size); > + > + *peval_out = peval; > + TRACE("retval %u, *peval_out %p.\n", D3D_OK, *peval_out); > Same with this. This one in particular doesn't seem worth keeping. Maybe we can leave this in place? I changed this to TRACE("Created param_eval %p.\n", *peval_out). I saw similar traces many times in d3d code and they are extremely helpful when we need to find a creation log for object we see used somewhere.

March 29, 2016

Re: [v7 2/7] d3dx9: Implement preshader parsing.

by Matteo Bruni

2016-03-29 1:39 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > I intentionally added this TRACE with output pointer as otherwise I > cannot find init trace related to particular preshader. E. g., if I have > some weirdness or error message when param_eval is used much later > (among a hundred of other param evals), I want to find the log records > where this preshader was created which has disassembly and binary blob. > Without this TRACE I have no sure way to match the used preshader with > its parsing trace. So unless you are strictly opposed to this TRACE I > would keep it to make future bug hunting easier. I'm okay with printing the pointer or similar info but that kind of trace is pretty ugly. You could trace the pointer when you allocate the struct, or together with the struct state pointer / the state parameter in the caller. I guess you can also leave the trace there, if it says something like: TRACE("Created parameter evaluator %p.\n", *peval_out); BTW, notice that you are never checking the return value from d3dx_create_param_eval(). You should either do that or remove the return value from the function altogether.

March 29, 2016

Re: Need some advice on shell32

by Mathy Vanvoorden

> I think that shell32 in shfldr_unixfs.c should check this setting > instead. Since it's skipping ntdll and using the Unix file APIs > directly, it should report the same thing to applications that ntdll > does, namely that dotfiles are not hidden files. > I have been looking at this just now and would like some more advice. In ntdll a number of things are done: * The registry key is only read once (I presume for performance reasons) * The DIR_is_hidden_file is called for every file * Folders like /dev, /proc, wine config, ... are always hidden It seems strange to me to reimplement all this logic and I figure it is desired to have the same behavior in both components so I would like to abstract it to a common base, however: * What is the best place to do this? To me somewhere in the libs seemed logical but I noticed that nowhere in there registry keys are being read so am I wrong thinking this is undesired behavior there? Is there a dll I could put this common code? * ntdll and shell32 use different functions to access registry keys, would it be a problem if the common code would only use the RegOpenKey functions? br, Mathy

March 29, 2016

Re: [PATCH] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v3).

by Henri Verbeet

On 28 March 2016 at 20:02, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > v3: Add bitmap verification, use InitFromFile and other minor improvements. > Implementing InitFromFile() should be a separate patch from implementing LoadTexture(). > if (FAILED(hr = d3drm_texture_create(&object))) > return hr; > > + if (FAILED(hr = IDirect3DRMTexture_InitFromFile(&object->IDirect3DRMTexture_iface, filename))) > + { > + d3drm_texture_destroy(object); > + return hr; > + } > + > + object->d3drm = iface; > + IDirect3DRM_AddRef(iface); It would be good to back this up with tests. It would seem more natural to pass the IDirect3DRM interface to d3drm_texture_create(). If that's how it's supposed to work, you can make that change in a separate patch. > @@ -39,6 +40,9 @@ struct d3drm_texture > IDirect3DRMTexture IDirect3DRMTexture_iface; > IDirect3DRMTexture2 IDirect3DRMTexture2_iface; > IDirect3DRMTexture3 IDirect3DRMTexture3_iface; > + IDirect3DRM *d3drm; > + D3DRMIMAGE *image; > + BOOL internal_image_created; You don't really need internal_image_created, you can probably just add a destroy callback. > +HRESULT d3drm_texture_load(struct d3drm_texture *texture, IDirect3DRM *d3drm, const char *path, > + BOOL load_upside_down) DECLSPEC_HIDDEN; > + > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, BOOL palette, BOOL upside_down) DECLSPEC_HIDDEN; These are internal helper functions now. > @@ -4109,36 +4111,94 @@ static void test_load_texture(void) > > hr = IDirect3DRM_LoadTexture(d3drm1, filename, &texture1); > ok(SUCCEEDED(hr), "Test %u: Failed to load texture, hr %#x.\n", i, hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + ok(ref2 > ref1, "Test %u: expected ref2 > ref1, got ref1 = %u, ref2 = %u.\n", i, ref1, ref2); > + > + hr = IDirect3DRMTexture_InitFromFile(texture1, filename); > + ok(hr == D3DRMERR_BADOBJECT, "Test %u: Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", i, hr); > + /* It's odd, but InitFromFile seems to AddRef IDirect3DRM even if it fails. */ So a test for the refcounts would be appropriate here. > +HRESULT d3drm_texture_load(struct d3drm_texture *texture, IDirect3DRM *d3drm, const char *path, BOOL load_upside_down) > +{ This is an internal helper function now and should be static. You never use "d3drm". > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, BOOL palette, BOOL upside_down) > +{ > + D3DRMPALETTEENTRY *colors; > + D3DRMIMAGE *image; > + BOOL black_used = FALSE; > + LONG w = info->bmiHeader.biWidth; > + LONG h = abs(info->bmiHeader.biHeight); > + int i, j, k; > + unsigned int idx, buffer1_idx; > + unsigned char *buffer1; > + int bpp = info->bmiHeader.biBitCount == 24 ? 32 : info->bmiHeader.biBitCount; > + int bpl = palette ? w : ((w + 3) & ~3) * bpp / 8; > + int num_colors = 0; There's not reason to use signed types for any of these. > + struct colors_24bpp > + { > + BYTE red; > + BYTE green; > + BYTE blue; > + } *color; > + color = (struct colors_24bpp *)buffer; > + > + if (bpl * h > UINT_MAX) > + { > + return NULL; > + } This doesn't work. If "bpl * h" would be larger than UINT_MAX it would overflow before the comparison. In fact, strictly speaking things become implementation defined above INT_MAX already, since you're using signed types for "bpl" and "h". What you'd typically do is something like "if (h > UINT_MAX / bpl)". Note that the calculation of "bpl" itself can overflow as well. So you'd need something like "if (align(w, 4) > UINT_MAX / (bpp / 8))" there as well. > + if (!(colors = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 256 * sizeof(*colors)))) > + { > + WARN("Not enough memory to allocate palette, returning NULL.\n"); > + return NULL; > + } > + > + > + if (!(image = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*image)))) > + { > + WARN("Not enough memory to allocate image struct, returning NULL.\n"); > + return NULL; > + } You probably don't need HEAP_ZERO_MEMORY for either of these. You certainly don't for "colors", and you should probably just initialise the few fields in "image" that you don't already. You also leak "colors" if the allocation for "image" fails. The indentation for the WARN is wrong. > + if (!(image->buffer1 = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, bpl * h))) > + { > + WARN("Not enough memory to allocate image buffer, returning NULL.\n"); > + return NULL; > + } You don't need HEAP_ZERO_MEMORY here if you're going to memset() it again below. You leak "colors" and "image" on failure. > + buffer1 = image->buffer1; > + memset(buffer1, 255, sizeof(unsigned char) * bpl * h); I think 0xff is clearer than 255. The "sizeof(unsigned char)" doesn't add much. > + if (!(image->palette = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, num_colors * sizeof(*image->palette)))) > + { > + WARN("Not enough memory to allocate image palette, returning NULL.\n"); > + return NULL; > + } Like above, you use HEAP_ZERO_MEMORY here, but immediately memcpy() over it. You leak on error. > + if (!(image->palette = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 256 * sizeof(*image->palette)))) > + { > + WARN("Not enough memory to allocate image palette, returning NULL.\n"); > + return NULL; > + } Leak on error. > static HRESULT WINAPI d3drm_texture1_InitFromFile(IDirect3DRMTexture *iface, const char *filename) > { > - FIXME("iface %p, filename %s stub!\n", iface, debugstr_a(filename)); > + struct d3drm_texture *object = impl_from_IDirect3DRMTexture(iface); I'd suggest "texture" instead of "object". > + if (object->d3drm) > + { > + /* InitFromFile seems to AddRef IDirect3DRM even if it fails. */ > + IDirect3DRM_AddRef(object->d3drm); > + } This is very suspicious, since you always assign "object->d3drm" after calling InitFromFile(). It's not backed up by tests either.

March 29, 2016

Re: [v2 PATCH 2/3] d2d1/tests: Basic test for ID2D1DCRenderTarget creation

by Nikolay Sivov

On 29.03.2016 12:15, Henri Verbeet wrote: > On 29 March 2016 at 01:21, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >> + static D2D1_PIXEL_FORMAT invalid_formats[] = >> + { >> + { DXGI_FORMAT_UNKNOWN, D2D1_ALPHA_MODE_PREMULTIPLIED }, >> + { DXGI_FORMAT_B8G8R8A8_UNORM, D2D1_ALPHA_MODE_UNKNOWN }, >> + { DXGI_FORMAT_R8G8B8A8_UNORM, D2D1_ALPHA_MODE_PREMULTIPLIED }, >> + }; > I should have noticed before, but this should be const. > > Thanks, I sent all 3 of them so testbot is not confused, only 2/3 was changed.

March 29, 2016

Re: [v2 PATCH 2/3] d2d1/tests: Basic test for ID2D1DCRenderTarget creation

by Henri Verbeet

On 29 March 2016 at 01:21, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + static D2D1_PIXEL_FORMAT invalid_formats[] = > + { > + { DXGI_FORMAT_UNKNOWN, D2D1_ALPHA_MODE_PREMULTIPLIED }, > + { DXGI_FORMAT_B8G8R8A8_UNORM, D2D1_ALPHA_MODE_UNKNOWN }, > + { DXGI_FORMAT_R8G8B8A8_UNORM, D2D1_ALPHA_MODE_PREMULTIPLIED }, > + }; I should have noticed before, but this should be const.

March 29, 2016

Re: [PATCH 2/5] ddraw/tests: Add a test for color varyings clamping.

by Henri Verbeet

On 28 March 2016 at 23:03, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + hr = IDirect3DDevice7_GetDirect3D(device, &d3d); > + ok(SUCCEEDED(hr), "Failed to get d3d interface, hr %#x.\n", hr); I suppose this is borrowed from test_shademode() where it's used to create the vertex buffers, but you're not using "d3d" anywhere here.

March 29, 2016

Re: [PATCH] msvcr120/tests: Add critical section test.

by Francois Gouget

On Tue, 22 Mar 2016, Piotr Caban wrote: > On 03/22/16 17:28, YongHao Hu wrote: > > How long is a test running acceptable? I want to know a appropriate > > standard. > There's no rule for that. In most cases 100ms wait is long enough to > make sure something works. Of course if the test is useful and it can't > be written to end quickly it can take much longer. I'm trying to avoid > tests that calls Sleep if possible. The TestBot and WineTest impose a 2 minute limit on individual tests (like msvcr120:msvcr120 or kernel32:process). Furthermore the TestBot imposes a 30 minute limit on the full test suite. At 585 tests (and growing all the time), this only allows an average of about 3 seconds per test. But of course some tests take much longer so the remainder must be much faster to bring the average down. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

March 29, 2016

Re: [v7 2/7] d3dx9: Implement preshader parsing.

by Paul Gofman

On 03/29/2016 02:16 AM, Matteo Bruni wrote: > >> + if (FAILED(regstore_alloc_table(&peval->pres.regs, i))) >> + { >> + hr = E_OUTOFMEMORY; >> + goto err_out; >> + } >> + } >> + >> + if (TRACE_ON(d3dx)) >> + dump_bytecode(byte_code, byte_code_size); >> + >> + *peval_out = peval; >> + TRACE("retval %u, *peval_out %p.\n", D3D_OK, *peval_out); > Same with this. This one in particular doesn't seem worth keeping. I intentionally added this TRACE with output pointer as otherwise I cannot find init trace related to particular preshader. E. g., if I have some weirdness or error message when param_eval is used much later (among a hundred of other param evals), I want to find the log records where this preshader was created which has disassembly and binary blob. Without this TRACE I have no sure way to match the used preshader with its parsing trace. So unless you are strictly opposed to this TRACE I would keep it to make future bug hunting easier. The TRACE on error return a few lines below is a leftover.

March 28, 2016

Re: [v7 2/7] d3dx9: Implement preshader parsing.

by Matteo Bruni

2016-03-28 9:20 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > Changes > - Changed opcode function to take double arguments and return double Good catch. > +static struct op_info pres_op_info[] = > +{ > + {0x000, "nop", 0, 0, NULL }, /* PRESHADER_OP_NOP */ > + {0x100, "mov", 1, 0, pres_mov}, /* PRESHADER_OP_MOV */ > +}; I think this can be const. > +struct d3dx_pres_ins > +{ > + enum pres_ops op; > + /* first input argument is scalar, > + scalar component is propagated */ > + BOOL scalar_op; > + unsigned int component_count; > + struct d3dx_pres_operand inputs[3]; The maximum number of input operands could use a #define. Not a huge deal though. > +static void regstore_free_tables(struct d3dx_regstore *rs) > +{ > + unsigned int i; > + > + for (i = PRES_REGTAB_FIRST; i <= PRES_REGTAB_LAST; ++i) > + { > + if (rs->tables[i]) > + HeapFree(GetProcessHeap(), 0, rs->tables[i]); > + if (rs->table_value_set[i]) > + HeapFree(GetProcessHeap(), 0, rs->table_value_set[i]); > + } > +} You don't need to check for non-NULL, HeapFree() handles NULL arguments just fine. > +static unsigned int *find_bytecode_comment(unsigned int *ptr, unsigned int fourcc) > +{ > + while ((*ptr & 0xffff) == 0xfffe) > + { > + if (*(ptr + 1) == fourcc) > + return ptr + 2; > + ptr += 1 + (*ptr >> 16); > + } > + return NULL; > +} This is probably paranoid but in theory a broken or malicious effect could send you rummaging outside of the bytecode buffer so all the offsets should be checked. I don't think it's critical in practice i.e. I'll probably sleep just fine if you decide to ignore this issue... > +static unsigned int *parse_pres_arg(unsigned int *ptr, struct d3dx_pres_operand *opr) > +{ > + static const enum pres_reg_tables reg_table[8] = > + { > + PRES_REGTAB_COUNT, PRES_REGTAB_IMMED, PRES_REGTAB_CONST, PRES_REGTAB_COUNT, > + PRES_REGTAB_OCONST, PRES_REGTAB_OBCONST, PRES_REGTAB_OICONST, PRES_REGTAB_REG Matter of taste, so feel free to ignore this, but PRES_REGTAB_REG sounds a bit vague to me. I'd go with something like PRES_REGTAB_TEMP. > + if (input_count != pres_op_info[i].input_count) > + { > + FIXME("Actual input args %u, expected %u, instruction %s.\n", input_count, > + pres_op_info[i].input_count, pres_op_info[i].mnem); > + return NULL; > + } > + for (i = 0; i < input_count; ++i) > + { > + ptr = parse_pres_arg(ptr, &ins->inputs[i]); > + if (!ptr) > + return NULL; > + } Another pretty paranoid potential check, here you could verify that input_count is < ARRAY_SIZE(ins->inputs). Of course that could only fail if we encounter some instruction with more than 3 components AND we update pres_op_info BUT we forget to update struct d3dx_pres_ins, but I don't think it would hurt to be safe... > + for (i = 0; i < pres->ins_count; ++i) > + { > + unsigned int table; > + > + for (j = 0; j < pres_op_info[pres->ins[i].op].input_count; ++j) > + { > + table = pres->ins[i].inputs[j].table; > + max_offset = get_reg_offset(table, pres->ins[i].inputs[j].offset + pres->ins[i].component_count - 1); > + pres->regs.table_sizes[table] = max(pres->regs.table_sizes[table], max_offset + 1); > + } > + table = pres->ins[i].output.table; > + max_offset = get_reg_offset(table, pres->ins[i].output.offset + pres->ins[i].component_count - 1); > + pres->regs.table_sizes[table] = max(pres->regs.table_sizes[table], max_offset + 1); > + } > + update_table_sizes_consts(pres->regs.table_sizes, &pres->inputs); It probably makes sense to add a small update_table_size() helper (or similar), the "same" 3 lines are repeated in the loop for the input operands, for the output operand and in update_table_sizes_consts(). > + for (i = PRES_REGTAB_IMMED + 1; i <= PRES_REGTAB_LAST; ++i) It depends on what is coming up next but maybe it would make sense to add an enum for "PRES_REGTAB_IMMED + 1" (incidentally, PRES_REGTAB_FIRST is never used in this patch series). > + { > + TRACE("table_sizes[%u] %u.\n", i, peval->pres.regs.table_sizes[i]); That trace looks a bit like a debugging leftover. > + if (FAILED(regstore_alloc_table(&peval->pres.regs, i))) > + { > + hr = E_OUTOFMEMORY; > + goto err_out; > + } > + } > + > + if (TRACE_ON(d3dx)) > + dump_bytecode(byte_code, byte_code_size); > + > + *peval_out = peval; > + TRACE("retval %u, *peval_out %p.\n", D3D_OK, *peval_out); Same with this. This one in particular doesn't seem worth keeping. > + return D3D_OK; > + > +err_out: > + FIXME("Error creating parameter evaluator.\n"); > + d3dx_free_param_eval(peval); > *peval_out = NULL; > - return E_NOTIMPL; > + TRACE("retval %u, *peval_out %p.\n", hr, *peval_out); > + return hr; > +} You could print the HRESULT in the FIXME (e.g. FIXME("Error creating parameter evaluator, returning %#x.\n", hr)). Tracing the value of *peval_out doesn't seem particularly worthwhile. > +static void d3dx_free_const_tab(struct d3dx_const_tab *ctab) > +{ > + if (ctab->inputs) > + HeapFree(GetProcessHeap(), 0, ctab->inputs); > + if (ctab->inputs_param) > + HeapFree(GetProcessHeap(), 0, ctab->inputs_param); > + if (ctab->ctab) > + ID3DXConstantTable_Release(ctab->ctab); > +} > + > +static void d3dx_free_preshader(struct d3dx_preshader *pres) > +{ > + if (pres->ins) > + HeapFree(GetProcessHeap(), 0, pres->ins); > + > + regstore_free_tables(&pres->regs); > + d3dx_free_const_tab(&pres->inputs); > } You can drop all those ifs (I think there are a few more of them in the middle of the patch I haven't specifically mentioned).

March 28, 2016

Re: [PATCH 2/5] ddraw/tests: Add a test for color varyings clamping.

by Marvin

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=21748 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

March 28, 2016

Re: [PATCH 2/3] d2d1/tests: Basic test for ID2D1DCRenderTarget creation

by Henri Verbeet

On 28 March 2016 at 22:18, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + hr = ID2D1Factory_CreateDCRenderTarget(factory, &desc, &rt); > + todo_wine > + ok(hr == D2DERR_UNSUPPORTED_PIXEL_FORMAT, "Failed to create target, hr %#x.\n", hr); ... > + hr = ID2D1DCRenderTarget_EndDraw(rt, NULL, NULL); > + ok(hr == D2DERR_WRONG_STATE, "EndDraw() failed, hr %#x.\n", hr); Those messages are a bit misleading. (For what it's worth, we usually use "Got unexpected hr %#x.\n" for those.)

March 28, 2016

Re: [PATCH] d2d1: Added a stub implementation for ID2D1DCRenderTarget

by Nikolay Sivov

Please ignore this one for now.

March 28, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

I sent a patch with InitFromFile implemented first. I'll keep it aside and implement CreateObject first if that's what you want. After you're okay with the CreateObject patches, you can sign-off on the LoadTexture patches later on. (after they're somehow integrated with the CreateObject patches below it). Cheers, Aaryaman On Mon, Mar 28, 2016 at 9:40 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 28 March 2016 at 17:56, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > InitFrom* tests would require CreateObject to work, for which I am > thinking > > of implementing as a seperate series of patches. For now I'm thinking of > > implementing InitFromFile for use by LoadTexture. Will that be okay? I > could > > add todo_wine tests for InitFromFile, and once CreateObject is > implemented, > > the todo's can be removed. > > > It might be ok. I'm not sure it's all that much easier than just > implementing CreateObject() first though. It would also mean the Wine > implementation is more or less untested until CreateObject() is > implemented. The main reason I can think of for implementing > InitFromFile() first is that it would allow you to send the code > you've already written a little bit sooner, but I don't think that's a > very convincing argument. >

March 28, 2016

Re: [PATCH 10/10] jscript: Find Function.arguments on the stack instead of storing it in FunctionInstance object.

by Marvin

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=21743 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

March 28, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Henri Verbeet

On 28 March 2016 at 17:56, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > InitFrom* tests would require CreateObject to work, for which I am thinking > of implementing as a seperate series of patches. For now I'm thinking of > implementing InitFromFile for use by LoadTexture. Will that be okay? I could > add todo_wine tests for InitFromFile, and once CreateObject is implemented, > the todo's can be removed. > It might be ok. I'm not sure it's all that much easier than just implementing CreateObject() first though. It would also mean the Wine implementation is more or less untested until CreateObject() is implemented. The main reason I can think of for implementing InitFromFile() first is that it would allow you to send the code you've already written a little bit sooner, but I don't think that's a very convincing argument.

March 28, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

On Mon, Mar 28, 2016 at 5:34 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 27 March 2016 at 20:23, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > The max resolution I tried which passed the tests was greater than 65535, > > hmm. Am I missing something? > > > What were the dimensions you tried that succeeded exactly? 13k x 13k @ > 24bpp would mean an allocation of about 640 MiB, which is a > considerable part of the 2 GiB address space you get (by default) as a > 32-bit process. It's perhaps not quite large enough that it's > guaranteed to fail, but I don't think it's all that surprising if > there no contiguous allocation of that size available. > I used a trial-and-error approach to find upto which resolution I could load a texture (around 12K x 12K which worked), which, as it seems, is not the correct way. That value is dependent on the hardware capabilities and fragmentation state which isn't generic enough to be considered as a hard limit on the bitmap size. Thanks for explaining about UINT_MAX for the buffer allocation! I'll include this as a check before loading the bitmap. Cheers, Aaryaman

March 28, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

InitFrom* tests would require CreateObject to work, for which I am thinking of implementing as a seperate series of patches. For now I'm thinking of implementing InitFromFile for use by LoadTexture. Will that be okay? I could add todo_wine tests for InitFromFile, and once CreateObject is implemented, the todo's can be removed. Cheers, Aaryaman On Mon, Mar 28, 2016 at 5:34 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 27 March 2016 at 20:23, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > The max resolution I tried which passed the tests was greater than 65535, > > hmm. Am I missing something? > > > What were the dimensions you tried that succeeded exactly? 13k x 13k @ > 24bpp would mean an allocation of about 640 MiB, which is a > considerable part of the 2 GiB address space you get (by default) as a > 32-bit process. It's perhaps not quite large enough that it's > guaranteed to fail, but I don't think it's all that surprising if > there no contiguous allocation of that size available. > > It's not so clear if d3drm is concerned with hardware limitations at > all. The more immediate/obvious issue there is is that if you're > storing the image size in a 32-bit unsigned integer, the maximum size > a square texture can have is 0xffff x 0xffff, since 0x10000 squared is > 0x100000000. That's for a 8 bpp format, for 32 bpp it goes down to > 0x7fff x 0x7fff. On the other hand, a non-square 32 bpp texture could > e.g. be 0x3fffffff x 0x1. I.e., your immediate concern is that you > don't overflow UINT_MAX when calculating the allocation size for the > image, and there's a good chance the rest will follow naturally from > that. > > Not being able to instantiate textures with CoCreateInstance() makes > sense, but it's good to verify. Not being able to instantiate > IDirect3DRM objects is more surprising, particularly since the > documentation explicitly mentions it as something that's supposed to > work. It may make a difference to use IID_IDirect3DRM2 or > IID_IDirect3DRM3 instead of IID_IDirect3DRM, I wouldn't put it past > d3drm to be picky like that. It might also be worth a try to call > DllGetClassObject() directly, to get a better idea of what works and > what doesn't. At this point all that is mostly just curiosity though. > > The main conclusion so far is that I think we'll want to implement > file loading in InitFromFile(). While I think using > d3drm_texture_create() in LoadTexture() makes sense, implementing > CreateObject() should help for writing tests for InitFromFile(). > InitFromImage() looks like it should be fairly trivial to implement, > maybe it makes sense to implement that before InitFromFile(). >

March 28, 2016

RE: regedit: Display REG_DWORD_BIG_ENDIAN values

by Hugh McMaster

On Monday, March 28 2016, 21:05 UTC+11, Nikolay Sivov wrote: >On 28.03.2016 12:52, Hugh McMaster wrote: >> Signed-off-by: Hugh McMaster >> --- >> programs/regedit/listview.c | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/programs/regedit/listview.c b/programs/regedit/listview.c >> index c0119ff..5b1bd80 100644 >> --- a/programs/regedit/listview.c >> +++ b/programs/regedit/listview.c >> @@ -174,6 +174,19 @@ static void AddEntryToList(HWND hwndLV, LPWSTR Name, DWORD dwValType, >> ListView_SetItemTextW(hwndLV, index, 2, buf); >> } >> break; >> + case REG_DWORD_BIG_ENDIAN: { >> + DWORD i, value = 0; >> + BYTE *data = ValBuf; >> + WCHAR buf[64]; >> + WCHAR fmt[] = {'0','x','%','0','8','x',' ','(','%','u',')',0}; >> + for (i = 0; i < dwCount; i++) { >> + value <<= 8; >> + value |= data[i]; >> + } >> + sprintfW(buf, fmt, value, value); >> + ListView_SetItemTextW(hwndLV, index, 2, buf); >> + } >> + break; >> case REG_BINARY: { >> unsigned int i; >> LPBYTE pData = ValBuf; >> >dwCount is always 1 in this case, dwCount is 4 for REG_DWORD and REG_DWORD_BIG_ENDIAN. >so it could be simplified to the point of swapping 'value' and >falling through to REG_DWORD case. I didn't check tests, but >you sure you need to modify what RegQueryValueExW() returns? On Windows, regedit displays the REG_DWORD type in little endian order and the REG_DWORD_BIG_ENDIAN type in big endian order. But both "reg query" and RegQueryValueEx() return any type of DWORD in little endian order. While it is true that there is common code in REG_DWORD and the BIG_ENDIAN case, I'm not sure there is a clean way to handle the endianness without checking for and handling the value type a second time.

March 28, 2016

Re: [GSoC] Mailinglist discussions

by Ivan Akulinchev

> Anyway, I assume the patch submission requirement (mentioned on > https://wiki.winehq.org/Summer_Of_Code) is still valid, right? It looks like the page is outdated, because it refers to GSoC 2015. > I suggest the applicants who haven't submitted patches to Wine yet > to work on it sooner rather than later. Does it mean I need to submit a patch until 22 April? Are the patches to Wine Staging considered?

March 28, 2016

Re: msvcirt: Avoid superfluous comparison in some compilers

by Iván Matellanes

On 27/03/16 23:30, Henri Verbeet wrote: > On 27 March 2016 at 13:57, Iván Matellanes <matellanesivan(a)gmail.com> wrote: >> - if (dir < SEEKDIR_beg || dir > SEEKDIR_end || !(mode & (OPENMODE_in|OPENMODE_out))) >> + if ((dir != SEEKDIR_beg && dir != SEEKDIR_cur && dir != SEEKDIR_end) || !(mode & (OPENMODE_in|OPENMODE_out))) > I'm not sure you're really making it better by adding another > comparison. One alternative you may want to consider is just > "(unsigned int)dir > SEEKDIR_end". Yes, a cast should do the trick, I will resend. Thanks. Iván

March 28, 2016

Re: regedit: Display REG_DWORD_BIG_ENDIAN values

by Nikolay Sivov

On 28.03.2016 12:52, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/listview.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/programs/regedit/listview.c b/programs/regedit/listview.c > index c0119ff..5b1bd80 100644 > --- a/programs/regedit/listview.c > +++ b/programs/regedit/listview.c > @@ -174,6 +174,19 @@ static void AddEntryToList(HWND hwndLV, LPWSTR Name, DWORD dwValType, > ListView_SetItemTextW(hwndLV, index, 2, buf); > } > break; > + case REG_DWORD_BIG_ENDIAN: { > + DWORD i, value = 0; > + BYTE *data = ValBuf; > + WCHAR buf[64]; > + WCHAR fmt[] = {'0','x','%','0','8','x',' ','(','%','u',')',0}; > + for (i = 0; i < dwCount; i++) { > + value <<= 8; > + value |= data[i]; > + } > + sprintfW(buf, fmt, value, value); > + ListView_SetItemTextW(hwndLV, index, 2, buf); > + } > + break; > case REG_BINARY: { > unsigned int i; > LPBYTE pData = ValBuf; > dwCount is always 1 in this case, so it could be simplified to the point of swapping 'value' and falling through to REG_DWORD case. I didn't check tests, but you sure you need to modify what RegQueryValueExW() returns?

March 28, 2016

Re: ntoskrnl.exe: Make IoAllocateIrp not crash on negative values.

by Sebastian Lackner

On 27.03.2016 20:27, Bernhard Übelacker wrote: > https://bugs.winehq.org/show_bug.cgi?id=39734 > > Changes should avoid crash in acedrv11.sys. > IoAllocateIrp is called with a stack_size of -128. > > Tested against Windows XP. > (See the test based on wine-staging "driver testing framework".) For reference, here a testbot run which confirms that the change is correct (for XP/2003): https://newtestbot.winehq.org/JobDetails.pl?Key=21722 > > Signed-off-by: Bernhard Übelacker <bernhardu(a)vr-web.de> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index 36488a7..f2ccc61 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -592,15 +592,20 @@ PIRP WINAPI IoAllocateIrp( CCHAR stack_size, BOOLEAN charge_quota ) > { > SIZE_T size; > PIRP irp; > + CCHAR _stack_size = stack_size; > > TRACE( "%d, %d\n", stack_size, charge_quota ); > > - size = sizeof(IRP) + stack_size * sizeof(IO_STACK_LOCATION); > + if (_stack_size <= 0 || (_stack_size > 1 && stack_size < 8)) > + _stack_size = 8; I would suggest to use a different variable, its very easy to mix up "stack_size" and "_stack_size". You even mixed it up yourself in the if() condition above. ;) If you want, you can also simplify the condition to (stack_size < 8 && stack_size != 1). > + > + size = sizeof(IRP) + _stack_size * sizeof(IO_STACK_LOCATION); > irp = ExAllocatePool( NonPagedPool, size ); > if (irp == NULL) > return NULL; > IoInitializeIrp( irp, size, stack_size ); > - irp->AllocationFlags = IRP_ALLOCATED_FIXED_SIZE; > + if (stack_size >= 1 && stack_size <= 8) > + irp->AllocationFlags = IRP_ALLOCATED_FIXED_SIZE; > if (charge_quota) > irp->AllocationFlags |= IRP_LOOKASIDE_ALLOCATION; > return irp; >

March 28, 2016

Re: Assorted spelling fixes.

by Marvin

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=21718 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 === w1064 (64 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

March 28, 2016

Re: Assorted spelling fixes.

by Marvin

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=21717 Your paranoid android. === w864 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4317: Test failed: cw is 0xf60, expected 0x7f. device.c:4326: Test failed: Callback cw is 0xf60, expected 0x7f.

March 28, 2016

Re: Assorted spelling fixes.

by Marvin

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=21714 Your paranoid android. === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w7pro64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === w1064 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042D889 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A === w7pro64 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A === w1064 (64 bit moniker) === moniker: unhandled exception c0000005 at 0000000000426C3A

March 28, 2016

Re: Assorted spelling fixes.

by Marvin

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=21712 Your paranoid android. === w864 (32 bit security) === security.c:3964: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0xa != 0x0) === w1064 (32 bit security) === security.c:3964: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:4005: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:4009: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:4005: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:4009: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

March 28, 2016

Re: Assorted spelling fixes.

by Marvin

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=21705 Your paranoid android. === w1064 (32 bit uri) === uri.c:7615: Test failed: Expected google.com.uk but got L"com.uk" on uri_tests[71].str_props[3]. uri.c:7615: Test failed: Expected google.uk.1 but got L"uk.1" on uri_tests[73].str_props[3]. uri.c:7613: Test failed: GetPropertyBSTR returned 0x00000000, expected 0x00000001. On uri_tests[76].str_props[3]. uri.c:7615: Test failed: Expected but got L".uk" on uri_tests[76].str_props[3]. uri.c:7615: Test failed: Expected google.com.[] but got L"com.[]" on uri_tests[77].str_props[3]. uri.c:7800: Test failed: Error: Expected google.com.uk but got L"com.uk" on uri_tests[71]. uri.c:7800: Test failed: Error: Expected google.uk.1 but got L"uk.1" on uri_tests[73]. uri.c:7798: Test failed: Error: GetDomain returned 0x00000000, expected 0x00000001 on uri_tests[76]. uri.c:7800: Test failed: Error: Expected but got L".uk" on uri_tests[76]. uri.c:7800: Test failed: Error: Expected google.com.[] but got L"com.[]" on uri_tests[77]. uri.c:8080: Test failed: Error: Expected a length of 13 but got 6 on uri_tests[71].str_props[3]. uri.c:8080: Test failed: Error: Expected a length of 11 but got 4 on uri_tests[73].str_props[3]. uri.c:8078: Test failed: Error: GetPropertyLength returned 0x00000000, expected 0x00000001 on uri_tests[76].str_props[3]. uri.c:8080: Test failed: Error: Expected a length of 0 but got 3 on uri_tests[76].str_props[3]. uri.c:8080: Test failed: Error: Expected a length of 13 but got 6 on uri_tests[77].str_props[3]. uri.c:8147: Test failed: Error: Received flag for property 3 when not expected on uri_tests[76]. uri.c:8197: Test failed: Error: Wasn't expecting to have property 3 on uri_tests[76]. uri.c:10487: Test failed: Error: Expected google.com.uk but got L"com.uk" instead on uri_parse_tests[42]. uri.c:10490: Test failed: Error: Expected 13, but got 6 instead on uri_parse_tests[42]. === w1064 (64 bit uri) === uri.c:7615: Test failed: Expected google.com.uk but got L"com.uk" on uri_tests[71].str_props[3]. uri.c:7615: Test failed: Expected google.uk.1 but got L"uk.1" on uri_tests[73].str_props[3]. uri.c:7613: Test failed: GetPropertyBSTR returned 0x00000000, expected 0x00000001. On uri_tests[76].str_props[3]. uri.c:7615: Test failed: Expected but got L".uk" on uri_tests[76].str_props[3]. uri.c:7615: Test failed: Expected google.com.[] but got L"com.[]" on uri_tests[77].str_props[3]. uri.c:7800: Test failed: Error: Expected google.com.uk but got L"com.uk" on uri_tests[71]. uri.c:7800: Test failed: Error: Expected google.uk.1 but got L"uk.1" on uri_tests[73]. uri.c:7798: Test failed: Error: GetDomain returned 0x00000000, expected 0x00000001 on uri_tests[76]. uri.c:7800: Test failed: Error: Expected but got L".uk" on uri_tests[76]. uri.c:7800: Test failed: Error: Expected google.com.[] but got L"com.[]" on uri_tests[77]. uri.c:8080: Test failed: Error: Expected a length of 13 but got 6 on uri_tests[71].str_props[3]. uri.c:8080: Test failed: Error: Expected a length of 11 but got 4 on uri_tests[73].str_props[3]. uri.c:8078: Test failed: Error: GetPropertyLength returned 0x00000000, expected 0x00000001 on uri_tests[76].str_props[3]. uri.c:8080: Test failed: Error: Expected a length of 0 but got 3 on uri_tests[76].str_props[3]. uri.c:8080: Test failed: Error: Expected a length of 13 but got 6 on uri_tests[77].str_props[3]. uri.c:8147: Test failed: Error: Received flag for property 3 when not expected on uri_tests[76]. uri.c:8197: Test failed: Error: Wasn't expecting to have property 3 on uri_tests[76]. uri.c:10487: Test failed: Error: Expected google.com.uk but got L"com.uk" instead on uri_parse_tests[42]. uri.c:10490: Test failed: Error: Expected 13, but got 6 instead on uri_parse_tests[42].

March 28, 2016

Re: Assorted spelling fixes.

by Marvin

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=21704 Your paranoid android. === wvistau64 (32 bit action) === The test timed out

March 28, 2016

Re: Assorted spelling fixes.

by Marvin

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=21702 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

March 28, 2016

Re: [GSoC] Support of pluggable theming engines

by Ivan Akulinchev

>> One thing depends on another. When I worked on my own UxTheme >> implementation, I found that comctl32 likes to send 0 instead of >> properly arguments. It angered me. > > Do you mean the way comctl32 uses uxtheme API currently is wrong? > How did you find out it's not using it right way, with proper > arguments? I didn't write it uses UxTheme API wrong. Let's say it doesn't use all features. Thus I can't unfold to the full. For example, uxtheme provides a great function named DrawThemeText. My first implementation used Pango because it's the native text engine for all GTK- applications. Unfortunately I had to refuse this idea because only a couple of controls used it. Thus the result was very ugly. But the problem is not limited to the text layout engine. Even if you want to draw some text yourself, you should probably get the right color and the right font from GetThemeColor and GetThemeFont respectively first. At the worst way ask what GetSysColor thinks. But sometimes comctl32 believes the plain black color should please everyone. This is crazy, guys! Back to the words about using the improper arguments. There is a theme class named LISTBOX. It defines 4 different parts depends on the scrollbar position. This parts have ids from 1 to 4. If you look at the file comctl32/theme_listbox.c you see it always sends the undocumented value 0. Take a look at the theme class EDIT. One part exists for the background (EP_BACKGROUND) and 4 parts were generously provided by Microsoft for the borders around. Let's open the comctl32/theme_edit.c source file. Firstly it uses only EP_EDITTEXT (probably created for the text inside). Secondly it doesn't ask UxTheme to draw the background. Even if you draw the background as a part of EP_EDITTEXT (as I did), it will be overlapped. This makes problems for such themes as Ambiance (the default Ubuntu theme). There is also a cool theme class named LISTVIEW. It provides a lot of parts for such things as list items (LVP_LISTITEM) which even support 6 states (normal, hot, selected, etc.) Guess how many parts comctl32 uses? Right, only one (the undocumented 0 again). Although a lot of GTK themes like to use gradients for list items. Even the Windows Aero theme does it. Therefore I don't believe Windows does it in the same way (just according to the things I see on the screen). P.S. I noticed there was a typo in my previous mails. Of course I wanted to write "flickering" instead of "flipping" saying about the double buffering advantages. It looks like you understood me right, just to be sure.

March 28, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Henri Verbeet

On 27 March 2016 at 20:23, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > The max resolution I tried which passed the tests was greater than 65535, > hmm. Am I missing something? > What were the dimensions you tried that succeeded exactly? 13k x 13k @ 24bpp would mean an allocation of about 640 MiB, which is a considerable part of the 2 GiB address space you get (by default) as a 32-bit process. It's perhaps not quite large enough that it's guaranteed to fail, but I don't think it's all that surprising if there no contiguous allocation of that size available. It's not so clear if d3drm is concerned with hardware limitations at all. The more immediate/obvious issue there is is that if you're storing the image size in a 32-bit unsigned integer, the maximum size a square texture can have is 0xffff x 0xffff, since 0x10000 squared is 0x100000000. That's for a 8 bpp format, for 32 bpp it goes down to 0x7fff x 0x7fff. On the other hand, a non-square 32 bpp texture could e.g. be 0x3fffffff x 0x1. I.e., your immediate concern is that you don't overflow UINT_MAX when calculating the allocation size for the image, and there's a good chance the rest will follow naturally from that. Not being able to instantiate textures with CoCreateInstance() makes sense, but it's good to verify. Not being able to instantiate IDirect3DRM objects is more surprising, particularly since the documentation explicitly mentions it as something that's supposed to work. It may make a difference to use IID_IDirect3DRM2 or IID_IDirect3DRM3 instead of IID_IDirect3DRM, I wouldn't put it past d3drm to be picky like that. It might also be worth a try to call DllGetClassObject() directly, to get a better idea of what works and what doesn't. At this point all that is mostly just curiosity though. The main conclusion so far is that I think we'll want to implement file loading in InitFromFile(). While I think using d3drm_texture_create() in LoadTexture() makes sense, implementing CreateObject() should help for writing tests for InitFromFile(). InitFromImage() looks like it should be fairly trivial to implement, maybe it makes sense to implement that before InitFromFile().

March 28, 2016

Re: [v6 1/7] d3dx9: Introduce preshaders in effect.

by Paul Gofman

I will resend tomorrow morning with these changes and the old+these changes list. I can surely fix object creation (presumably just free memory on copy over duplicate object at the first place). But maybe we should also skip object data creation for object_id 0 at all? In any case it would be probably easier to deal with it after finishing off the current patchset, I already have a few other things for d3dx effects on top of it and it is becoming difficult to manage :) On Mon, 28 Mar 2016 at 02:07, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2016-03-28 0:54 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > > Yes, sorry, this is the case. It looks like I already changed it later in > > preliminary shared parameters (pool) implementation, but did not get > back to > > the right patch in the sequence where it is also a problem. > > Should I resend the patches with just these changes or wait for your > > comments on the remaining part? > > You can resend, I haven't managed to seriously review the other > patches in this iteration anyway :/ I'll try to take some time to > review them tomorrow either way. > Only noticed a nitpick, in patch 2/7 there is an if with no brackets > followed by its else with them. You should add brackets to the if too. > > > PS I think there might be also a similar problem for object creation in > > effect parsing when there are multiple object_id 0 in effect (which is > > accompanied by a warning that object is already created which is seen > quite > > often), data copying code does not free existing pointer. > > Right. I'll write a patch for that, if you don't get there first. >

March 27, 2016

Re: [v6 1/7] d3dx9: Introduce preshaders in effect.

by Matteo Bruni

2016-03-28 0:54 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Yes, sorry, this is the case. It looks like I already changed it later in > preliminary shared parameters (pool) implementation, but did not get back to > the right patch in the sequence where it is also a problem. > Should I resend the patches with just these changes or wait for your > comments on the remaining part? You can resend, I haven't managed to seriously review the other patches in this iteration anyway :/ I'll try to take some time to review them tomorrow either way. Only noticed a nitpick, in patch 2/7 there is an if with no brackets followed by its else with them. You should add brackets to the if too. > PS I think there might be also a similar problem for object creation in > effect parsing when there are multiple object_id 0 in effect (which is > accompanied by a warning that object is already created which is seen quite > often), data copying code does not free existing pointer. Right. I'll write a patch for that, if you don't get there first.

March 27, 2016

Re: [v6 1/7] d3dx9: Introduce preshaders in effect.

by Paul Gofman

Yes, sorry, this is the case. It looks like I already changed it later in preliminary shared parameters (pool) implementation, but did not get back to the right patch in the sequence where it is also a problem. Should I resend the patches with just these changes or wait for your comments on the remaining part? PS I think there might be also a similar problem for object creation in effect parsing when there are multiple object_id 0 in effect (which is accompanied by a warning that object is already created which is seen quite often), data copying code does not free existing pointer. On Mon, 28 Mar 2016 at 00:19, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2016-03-23 18:02 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > > Sorry, I thought about this only now: > > > @@ -5569,7 +5579,15 @@ static HRESULT d3dx9_parse_resource(struct > d3dx9_base_effect *base, const char * > > param->referenced_param = get_parameter_by_name(base, NULL, > object->data); > > if (param->referenced_param) > > { > > - TRACE("Mapping to parameter %p.\n", > param->referenced_param); > > + struct d3dx_parameter *refpar = param->referenced_param; > > + > > + TRACE("Mapping to parameter %p, having object id > %u.\n", refpar, refpar->object_id); > > + if (refpar->type == D3DXPT_VERTEXSHADER || refpar->type > == D3DXPT_PIXELSHADER) > > + { > > + struct d3dx_object *refobj = > &base->objects[refpar->object_id]; > > + > > + d3dx_create_param_eval(base, refobj->data, > refobj->size, refpar->type, &refpar->param_eval); > > + } > > If a parameter is referenced multiple times in an effect this probably > allocates the param_eval structure more than once, leaking all but the > last copy (well, it depends on the implementation of > d3dx_create_param_eval(), but it should be the case here). > > I haven't tested that directly but I have tested that two references > to the vs_arr array seem to lead to a similar issue WRT the array > elements (i.e. the vertex shaders). >

March 27, 2016

Re: msvcirt: Avoid superfluous comparison in some compilers

by Henri Verbeet

On 27 March 2016 at 13:57, Iván Matellanes <matellanesivan(a)gmail.com> wrote: > - if (dir < SEEKDIR_beg || dir > SEEKDIR_end || !(mode & (OPENMODE_in|OPENMODE_out))) > + if ((dir != SEEKDIR_beg && dir != SEEKDIR_cur && dir != SEEKDIR_end) || !(mode & (OPENMODE_in|OPENMODE_out))) I'm not sure you're really making it better by adding another comparison. One alternative you may want to consider is just "(unsigned int)dir > SEEKDIR_end".

March 27, 2016

Re: [GSoC] Mailinglist discussions

by Matteo Bruni

2016-03-26 15:47 GMT+01:00 André Hentschel <nerv(a)dawncrow.de>: > Hi, > > This year it's not possible to communicate with the GSoC Students over the GSoC-Project site. > I guess the reason is to force communication with the community. > Thus I suggest to move the discussions to wine-devel and prefix them with [GSoC] > > Thx It seems more likely to me it has to do with the new GSoC website being "new" and generally lacking. Anyway, I assume the patch submission requirement (mentioned on https://wiki.winehq.org/Summer_Of_Code) is still valid, right? I suggest the applicants who haven't submitted patches to Wine yet to work on it sooner rather than later.

March 27, 2016

Re: [v6 1/7] d3dx9: Introduce preshaders in effect.

by Matteo Bruni

2016-03-23 18:02 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: Sorry, I thought about this only now: > @@ -5569,7 +5579,15 @@ static HRESULT d3dx9_parse_resource(struct d3dx9_base_effect *base, const char * > param->referenced_param = get_parameter_by_name(base, NULL, object->data); > if (param->referenced_param) > { > - TRACE("Mapping to parameter %p.\n", param->referenced_param); > + struct d3dx_parameter *refpar = param->referenced_param; > + > + TRACE("Mapping to parameter %p, having object id %u.\n", refpar, refpar->object_id); > + if (refpar->type == D3DXPT_VERTEXSHADER || refpar->type == D3DXPT_PIXELSHADER) > + { > + struct d3dx_object *refobj = &base->objects[refpar->object_id]; > + > + d3dx_create_param_eval(base, refobj->data, refobj->size, refpar->type, &refpar->param_eval); > + } If a parameter is referenced multiple times in an effect this probably allocates the param_eval structure more than once, leaking all but the last copy (well, it depends on the implementation of d3dx_create_param_eval(), but it should be the case here). I haven't tested that directly but I have tested that two references to the vs_arr array seem to lead to a similar issue WRT the array elements (i.e. the vertex shaders).

March 27, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

The max resolution I tried which passed the tests was greater than 65535, hmm. Am I missing something? On Sun, Mar 27, 2016 at 9:20 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-03-27 um 14:17 schrieb Aaryaman Vasishta: > > What should be the max. resolution for the texture? I'm getting > > D3DRMERR_BADALLOC if the resolution is >= 13K x 13K @ 24bpp on my > > win8.1 machine with 16GB RAM. Maybe the max resolution might depend > > on the system? I think setting a max resolution of 4K should be > > fine, I guess. > Probably the max d3d texture size? > > Someone sent tests a long time ago that showed that the max ddraw > surface size is 65535 for sysmem (and presumably HW if the HW limit is > beyond this in d3d8+). > > At some point you'll hit the 2G address space limit. There's also a > chance that even if enough address space is free it is fragmented too > much to support your texture. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJW+AEqAAoJEN0/YqbEcdMwu7EP/3cWlguPiED/CkHNyK2CiWZm > CazSETN6zor6pwRN32yaofQZ1nv3LMt2TlQ4EfYQVvXoZj1kCj9yoxPOwGLN4cgl > /hzMGPXPGc8A65z3gbgZot2D/CcRl4Bmxx54XwZr7ycGHFCMnG+iS0KJdHc1DUMS > HkQ2Nb0CSUwf4ZV4Xxyx0OP3UEE7usqN1J9jxuLmRt1tMyfXfdsXWD+VWBl/A8RF > pRSvXWqWoMmPb5J+0FBbdrwDQdhJT/+NVm8t46C6c+AMt+KTl1SSO41DGix2Loav > NzELZuFGF7pnwhiFvuf04UfvFF8MHWAal9O7c7fXqwD0MXKt9kYokzqL+p8LIiOj > wuRXF/A9atvg9PfPcuFslWctN0hUIc3vIDsvS9a6vBjB9oApavjb9R7y1g5rpLY6 > nku+LHLKTbWtt81JzgOCxNB8vTfaEwKjefoy4PRq+YFPsNmtCL11P9dnaUe7LCsl > ZXqDzUVcMRwjfsEg879k67gTdt+fsjdPpJQrm6VnoQTJxQRC6KTySwcNBLHqxWOJ > Ch8oaBzk9ByKtL9AwTrt0/YuSKv5IRVrv+tyb6xmXo5YJHYRl6HQ5hHaUPIBPTeh > E4OYoGSkPtqP4hDtDh4tBucDNwxhd0VkZFgMMAc2DI9izxWmasI5+85HGkHkINlp > aSyJHCbU0fqp9Meg1w8A > =FCyH > -----END PGP SIGNATURE----- >

March 27, 2016

Re: d3d8: Unlock already unlocked surface does not fail

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-03-27 um 13:05 schrieb David Adam: > Signed-off-by: David Adam <david.adam.cnrs(a)gmail.com> > --- > dlls/d3d8/surface.c | 9 ++++----- > dlls/d3d8/tests/visual.c | 14 ++++++++++++++ > 2 files changed, 18 insertions(+), 5 deletions(-) > > diff --git a/dlls/d3d8/surface.c b/dlls/d3d8/surface.c > index 565f642..376bc6f 100644 > --- a/dlls/d3d8/surface.c > +++ b/dlls/d3d8/surface.c > @@ -271,11 +271,10 @@ static HRESULT WINAPI d3d8_surface_UnlockRect(IDirect3DSurface8 *iface) > hr = wined3d_resource_unmap(wined3d_texture_get_resource(surface->wined3d_texture), surface->sub_resource_idx); > wined3d_mutex_unlock(); > > - switch(hr) > - { > - case WINEDDERR_NOTLOCKED: return D3DERR_INVALIDCALL; > - default: return hr; > - } > + if (hr == WINEDDERR_NOTLOCKED) > + return D3D_OK; I suspect that similarly to lock validation the behavior of double unlocks depends on the resource type (surface vs texture). > @@ -178,6 +178,8 @@ static D3DCOLOR get_surface_color(IDirect3DSurface8 *surface, UINT x, UINT y) > > hr = IDirect3DSurface8_UnlockRect(surface); > ok(SUCCEEDED(hr), "Failed to unlock surface, hr=%#x.\n", hr); > + hr = IDirect3DSurface8_UnlockRect(surface); > + ok(SUCCEEDED(hr), "Failed to double unlock surface, hr=%#x.\n", hr); We have test_surface_double_unlock() in device.c and test_lockrect_invalid(). The test fits there better than sprinkled all around visual.c. (I have a preference for merging test_surface_double_unlock into test_lockrect_invalid, but I haven't looked closely how well that'll work) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW+AcxAAoJEN0/YqbEcdMwSYMP/ifDlI7N/z6QcEL6lRo9WsDr C+WfvTA6R4SRY+Wc/rWihX821b1mApv+kk9CSnZDSV96tpXKikjQdsMM5pB91oDW PDXxNkuoGpo1AR6gS5rve3fWc3vgRXSy7XzPLXAOlL6PF/lxbDcD/jixj8PjI6NZ Oel1ukbYuAr8dINKS8oB4tTZg59Pq/devXepJNlxxzfg11lgnoiF2kBYAlKZp+qC e59bWeZMixzB7ChzSUpAxlpjd+yipdtnVLKrq2codNYZn2Z+tV959MAZO+YYB35I BtHoSFNF16omLJ6qu9ZDZISOesep4YAlHyicERkZKR6kikaGI1/ezkxZtzD9zREn EDK5L+Trhar+XW/WgEYwJtIk9PAkJgLU53W5hgoq9TeDguMEtszvFj2GTStGEVnd M+dNN/4DQNg1aqCj1yRoom7N7WCVExWxdw9PlgqOFW68EjlNxZM2uO8S5pTNKx95 cBfxLYCI+agYj/aw3xOL3/yzNe4tI/pp+thsDlTqQZaXXTb3/S+ilChGEED9pQOz rHRQCP8yTsV9YtjWa2F+a/uSYP/LkZ9qFMkVzV9/nRw9GxpD0s2F7RdZVqhdW+VY eXW/YSDN+Mm8YF7MkWCKCeodDHL/VVqlDiEx8e+XQ96uELoiV2WP/GiVCwtjVMmb 9fib0jMQDGufm0Txe57H =pNWk -----END PGP SIGNATURE-----

March 27, 2016

Re: [1/3] user32/tests: Test loading monochrome icons.

by Thomas Faber

On 2016-03-27 16:41, Marvin wrote: > === w8 (32 bit cursoricon) === > cursoricon.c:2571: Test failed: LoadImage() failed with 0. > cursoricon.c:2571: Test failed: LoadImage() failed with 0. Hmm Win8 doesn't seem to like icons using BITMAPCOREINFO, I'll have to play with that a bit. Open for any comments on the series in the mean time. Thanks! -Thomas

March 27, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-03-27 um 14:17 schrieb Aaryaman Vasishta: > What should be the max. resolution for the texture? I'm getting > D3DRMERR_BADALLOC if the resolution is >= 13K x 13K @ 24bpp on my > win8.1 machine with 16GB RAM. Maybe the max resolution might depend > on the system? I think setting a max resolution of 4K should be > fine, I guess. Probably the max d3d texture size? Someone sent tests a long time ago that showed that the max ddraw surface size is 65535 for sysmem (and presumably HW if the HW limit is beyond this in d3d8+). At some point you'll hit the 2G address space limit. There's also a chance that even if enough address space is free it is fragmented too much to support your texture. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW+AEqAAoJEN0/YqbEcdMwu7EP/3cWlguPiED/CkHNyK2CiWZm CazSETN6zor6pwRN32yaofQZ1nv3LMt2TlQ4EfYQVvXoZj1kCj9yoxPOwGLN4cgl /hzMGPXPGc8A65z3gbgZot2D/CcRl4Bmxx54XwZr7ycGHFCMnG+iS0KJdHc1DUMS HkQ2Nb0CSUwf4ZV4Xxyx0OP3UEE7usqN1J9jxuLmRt1tMyfXfdsXWD+VWBl/A8RF pRSvXWqWoMmPb5J+0FBbdrwDQdhJT/+NVm8t46C6c+AMt+KTl1SSO41DGix2Loav NzELZuFGF7pnwhiFvuf04UfvFF8MHWAal9O7c7fXqwD0MXKt9kYokzqL+p8LIiOj wuRXF/A9atvg9PfPcuFslWctN0hUIc3vIDsvS9a6vBjB9oApavjb9R7y1g5rpLY6 nku+LHLKTbWtt81JzgOCxNB8vTfaEwKjefoy4PRq+YFPsNmtCL11P9dnaUe7LCsl ZXqDzUVcMRwjfsEg879k67gTdt+fsjdPpJQrm6VnoQTJxQRC6KTySwcNBLHqxWOJ Ch8oaBzk9ByKtL9AwTrt0/YuSKv5IRVrv+tyb6xmXo5YJHYRl6HQ5hHaUPIBPTeh E4OYoGSkPtqP4hDtDh4tBucDNwxhd0VkZFgMMAc2DI9izxWmasI5+85HGkHkINlp aSyJHCbU0fqp9Meg1w8A =FCyH -----END PGP SIGNATURE-----

March 27, 2016

Re: [GSoC] Support of pluggable theming engines

by Ruslan Kabatsayev

I'd like to point out that DESKTOP_SESSION=KDE isn't a robust way to detect oxygen-gtk. I use it in XFCE, for example, too. If not checking the theme name, it'd be better to refrain from refusing to use gtk3 on KDE, as the user may have set up a simpler to emulate GTK theme. On Sat, Mar 26, 2016 at 10:34 PM, Ivan Akulinchev <ivan.akulinchev(a)gmail.com> wrote: > I wrote a brief roadmap: > > 1. Improve uxtheme handles. Currently they are just void pointers to > the internal structures. All other libraries do it using a handle > table [1, 2, 3]. > 2. Move all MSSTYLES-related code to winemsstyles.drv. At this step > such uxtheme functions as DrawThemeBackground will be stubbed. > 3. Add support for uxtheme drivers. At the startup the registry key > HKCU\Software\Wine\Drivers\Theme will be read. This is a comma- > separated list such as "gtk3,qt5,mac,msstyles". In the loop all > drivers will be tried until the working one found. Note the > suggested order. If winegtk3.drv see the DESKTOP_SESSION > environment variable is set to KDE, it should return FALSE from the > entry point, so wineqt5.drv will be tried. This is a bug founded by > Ruslan Kabatsayev last year [4]. If nothing found, the last one > (winemsstyles.drv) should be used. > 4. Work on the activation context. This is a complex step I need to > describe separately... > 5. Implement Buffered Paint API [5]. > 6. Add double buffering support to comctl32 (I hate flipping!!!) > 7. Add support for animated transitions like Windows Vista does. > 8. Fix other problems in comctl32 that I hate... > 9. Move the existing code from uxthemegtk [6] to winegtk3.drv. > 10. Improve winegt3.drv until the deadline ;-) > > [1] https://github.com/wine-mirror/wine/blob/master/dlls/gdi32/gdiobj.c > [2] https://github.com/wine-mirror/wine/blob/master/dlls/winhttp/handle.c > [3] https://github.com/wine-mirror/wine/blob/master/server/handle.c > [4] https://www.winehq.org/pipermail/wine-devel/2015-July/108232.html > [5] > https://msdn.microsoft.com/en-us/library/windows/desktop/bb773257%28v=vs.85… > [6] https://github.com/akulinchev/uxthemegtk > >

March 27, 2016

Re: [3/3] user32: Correctly determine bit count for BITMAPCOREINFO in is_dib_monochrome.

by Marvin

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=21689 Your paranoid android. === w8 (32 bit cursoricon) === cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0. === w864 (32 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0. === w1064 (32 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0. === w864 (64 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0. === w1064 (64 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0.

March 27, 2016

Re: [2/3] user32: Handle BITMAPCOREINFO when loading icons.

by Marvin

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=21688 Your paranoid android. === w8 (32 bit cursoricon) === cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0. === w864 (32 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0. === w1064 (32 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0. === w864 (64 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0. === w1064 (64 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2570: Test failed: LoadImage() failed with 0. cursoricon.c:2570: Test failed: LoadImage() failed with 0.

March 27, 2016

Re: [1/3] user32/tests: Test loading monochrome icons.

by Marvin

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=21687 Your paranoid android. === w8 (32 bit cursoricon) === cursoricon.c:2571: Test failed: LoadImage() failed with 0. cursoricon.c:2571: Test failed: LoadImage() failed with 0. === w864 (32 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2571: Test failed: LoadImage() failed with 0. cursoricon.c:2571: Test failed: LoadImage() failed with 0. === w1064 (32 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 00000000: (00000000, 00000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2571: Test failed: LoadImage() failed with 0. cursoricon.c:2571: Test failed: LoadImage() failed with 0. === w864 (64 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2571: Test failed: LoadImage() failed with 0. cursoricon.c:2571: Test failed: LoadImage() failed with 0. === w1064 (64 bit cursoricon) === cursoricon.c:1403: Test failed: Create cursor failed. cursoricon.c:1408: Test failed: GetIconInfo() failed. cursoricon.c:1410: Test failed: Last error: 1402 cursoricon.c:1425: Test failed: DestroyCursor() failed. cursoricon.c:1427: Test failed: Last error: 1402 cursoricon.c:1560: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1567: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1568: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0x0). cursoricon.c:1569: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 1). cursoricon.c:1575: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1587: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1593: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1602: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1604: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1605: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1608: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1627: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1633: Test failed: Create cursor failed (error = -559038737). cursoricon.c:1639: Test failed: Unexpected number of steps in cursor (0 != 1) cursoricon.c:1646: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1648: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1649: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbeef). cursoricon.c:1652: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != ~0). cursoricon.c:1669: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:1681: Test failed: Create cursor failed (error = deadbeef). cursoricon.c:1687: Test failed: Unexpected number of steps in cursor (0 != 3) cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 0. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xc0de). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 1. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xcafe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1698: Test failed: GetCursorFrameInfo() failed for cursor 0000000000000000: (0000000000000000, 0000000000000000). cursoricon.c:1439: Test failed: GetIconInfo() failed cursoricon.c:1700: Test failed: GetCursorFrameInfo() returned wrong cursor data for frame 2. cursoricon.c:1701: Test failed: GetCursorFrameInfo() unexpected param 4 value (0xdead != 0xbabe). cursoricon.c:1704: Test failed: GetCursorFrameInfo() unexpected param 5 value (57005 != 3). cursoricon.c:1712: Test failed: DestroyCursor() failed (error = 1402). cursoricon.c:2571: Test failed: LoadImage() failed with 0. cursoricon.c:2571: Test failed: LoadImage() failed with 0.

March 27, 2016

Re: [GSoC] Support of pluggable theming engines

by Ivan Akulinchev

> I mean window class manifest data is already parsed in > ntdll/actctx.c and FindActCtxSectionStringW() already returns > versioned class names. Good news. I have less work to do. > I mean where in user controls such transition effects are supposed > to be used? Take a look at the default button in Vista and 7. It changes here and there between PBS_DEFAULTED and PBS_DEFAULTED_ANIMATING (the last one not described in MSDN, sorry). If you hover the mouse, the state will be changed smoothly as well. So the push button is the candidate number one. But other controls have animations too, perhaps you didn't recognize it due to a very small transition time. Speaking about GTK, animated widgets can await you everywhere. For example, in Adwaita (the default theme from GNOME3) tabs have the same behavior as buttons in Windows Vista. For this reason all controls should support animated transitions.

March 27, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

What should be the max. resolution for the texture? I'm getting D3DRMERR_BADALLOC if the resolution is >= 13K x 13K @ 24bpp on my win8.1 machine with 16GB RAM. Maybe the max resolution might depend on the system? I think setting a max resolution of 4K should be fine, I guess. Cheers, Aaryaman On Sat, Mar 26, 2016 at 11:54 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > Err, it's "Direct3DRM Object", instead of "Direct3DRMObject", which I > wrote by mistake. > > On Sat, Mar 26, 2016 at 11:42 PM, Aaryaman Vasishta < > jem456.vasishta(a)gmail.com> wrote: > >> Some notes: >> >> I played around with IDirect3DRM::CreateObject a bit, and it also returns >> REGDB_E_CLASSNOTREG if the proper CLSID is not set. Another interesting >> note is that passing the same CLSID that worked for CreateObject to >> CoCreateInstance makes it fail. The SDK setup does in fact add the CLSID's >> to the registry - it seems that the setup reads d3drm.inf, creates a couple >> .reg files and runs that to create the registry entries. The only registry >> entry related to d3drm which the setup adds is "Direct3DRMObject" whose >> value is {4516EC41-8F20-11d0-9B6D-0000C0781BC3}, which matches that of >> CLSID_CDirect3DRM. >> I installed this SDK on my XP VM, yet the tests fail, hmm. >> >> I played around with different CLSCTX values as well - no luck so far. >> >> Cheers, >> Aaryaman >> >> >> On Sat, Mar 26, 2016 at 8:09 PM, Aaryaman Vasishta < >> jem456.vasishta(a)gmail.com> wrote: >> >>> "regsvr32.exe d3drm.dll" returns an error saying DllRegisterServer was >>> not found. >>> >>> I compiled the test below and ran it on an XP VM (which had the dx7 SDK >>> installed) just to be sure that my native win8.1 box wasn't the issue: >>> >>> CoInitialize(NULL); >>>> hr = CoCreateInstance(&CLSID_CDirect3DRM, NULL, CLSCTX_INPROC_HANDLER, >>>> &IID_IDirect3DRM, &d3drm); >>>> ok(hr == D3DRM_OK, "Got %#x for IID_IDirect3DRM\n", hr); >>>> hr = CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, >>>> CLSCTX_INPROC_HANDLER, &IID_IDirect3DRMTexture3, &texture3); >>>> ok(hr == D3DRM_OK, "Got %#x for IID_IDirect3DRMTexture3\n", hr); >>>> >>> >>> Got the following results: >>> >>> d3drm.c:4309: Test failed: Got 0x80040154 for IID_IDirect3DRM >>>> d3drm.c:4311: Test failed: Got 0x80040154 for IID_IDirect3DRMTexture3 >>>> >>> >>> >>> On Sat, Mar 26, 2016 at 7:55 PM, Stefan Dösinger < >>> stefandoesinger(a)gmail.com> wrote: >>> >>>> >>>> >> CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, >>>> CLSCTX_INPROC_SERVER, >>>> >> &IID_IDirect3DRMTexture3, &texture3) returns REGDB_E_CLASSNOTREG. Am >>>> I >>>> >> missing something? >>>> >> >>>> > Does it work for IDirect3DRM? It may not be supposed to work, although >>>> > it's also possible d3drm.dll is just not properly registered. >>>> If you copied d3drm.dll from XP you'll most likely have to register it >>>> with regsvr32. >>>> >>> >>> >> >

March 27, 2016

Re: [GSoC] Support of pluggable theming engines

by Nikolay Sivov

On 27.03.2016 14:17, Ivan Akulinchev wrote: > >> Class redirection context support is already there, user32 does not >> honor it, that's the problem. > > Sorry, can't find it. Could you please provide a link? I mean window class manifest data is already parsed in ntdll/actctx.c and FindActCtxSectionStringW() already returns versioned class names. > >>> 6. Add double buffering support to comctl32 (I hate flipping!!!) >> >> Some controls have double buffering mode, when working without >> theme. You mean here only the case when theme is active? > > I don't know which case I mean, but such complex controls as toolbars > flip on the window resize. For toolbar in particular double buffering is supposed to be enabled with TBSTYLE_EX_DOUBLEBUFFER style, so it's probably up to application to activate it (could be that active theme always triggers double buffering too). > >>> 7. Add support for animated transitions like Windows Vista does. >> >> What is affected by this exactly? > > Sorry, didn't understand the question. If mean how I'm going to do it: > > 1. Implement BeginBufferedAnimation and EndBufferedAnimation. > 2. Call GetThemeTransitionDuration when the state changes. > 3. Use BeginBufferedAnimation and EndBufferedAnimation, see the > example from MSDN. Even if the transition duration is set to 0, you > get double buffering for free. I mean where in user controls such transition effects are supposed to be used?

March 27, 2016

Re: [GSoC] Support of pluggable theming engines

by Ivan Akulinchev

>> 2. Move all MSSTYLES-related code to winemsstyles.drv. At this step >> such uxtheme functions as DrawThemeBackground will be stubbed. > > I don't think this step is needed, MSSTYLES stuff could stay in > uxtheme, acting similar to null driver from user32. Of course I thought about it, but for a long time ago. Then it was better to keep all MSSTYLES-related stub separately. Now I see some reasons to keep it inside. You're right, thanks. > Just curious, did you explore the ways to implement qt5 variant (let > alone mac)? I didn't plan to implement this in the context of GSoC, but yes. If you mean something like MOC (Qt preprocessor), it's not necessary until you want to inherit some QObject class. It looks a little bit tricky, but it's the documented way. The only thing you need is a modern C++ compiler and Qt headers installed on the build system. The mac driver has no unsolvable problems too. > Class redirection context support is already there, user32 does not > honor it, that's the problem. Sorry, can't find it. Could you please provide a link? >> 6. Add double buffering support to comctl32 (I hate flipping!!!) > > Some controls have double buffering mode, when working without > theme. You mean here only the case when theme is active? I don't know which case I mean, but such complex controls as toolbars flip on the window resize. >> 7. Add support for animated transitions like Windows Vista does. > > What is affected by this exactly? Sorry, didn't understand the question. If mean how I'm going to do it: 1. Implement BeginBufferedAnimation and EndBufferedAnimation. 2. Call GetThemeTransitionDuration when the state changes. 3. Use BeginBufferedAnimation and EndBufferedAnimation, see the example from MSDN. Even if the transition duration is set to 0, you get double buffering for free. >> 8. Fix other problems in comctl32 that I hate... > > Sure, but could you give a draft list for that? I'll write you later (you already asked me in another mail above).

March 27, 2016

Re: d3d8: Unlock already unlocked surface does not fail

by Marvin

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=21685 Your paranoid android. === w8 (32 bit visual) === visual.c:4173: Test failed: Failed to double unlock readback surface, hr 0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. === w864 (32 bit visual) === visual.c:4173: Test failed: Failed to double unlock readback surface, hr 0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. === w1064 (32 bit visual) === visual.c:4173: Test failed: Failed to double unlock readback surface, hr 0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c. visual.c:182: Test failed: Failed to double unlock surface, hr=0x8876086c.

March 27, 2016

Re: [GSoC] Support of pluggable theming engines

by Nikolay Sivov

On 26.03.2016 20:52, Ivan Akulinchev wrote: >> Having properly implemented user controls is far more important than >> having partially working gtk3 disguise. > > One thing depends on another. When I worked on my own UxTheme > implementation, I found that comctl32 likes to send 0 instead of > properly arguments. It angered me. Do you mean the way comctl32 uses uxtheme API currently is wrong? How did you find out it's not using it right way, with proper arguments? > > So if I want to get a perfect GTK3-theming, I have to fix comctl32 too. > >

March 27, 2016

Re: [GSoC] Support of pluggable theming engines

by Nikolay Sivov

On 26.03.2016 22:34, Ivan Akulinchev wrote: > I wrote a brief roadmap: > > 1. Improve uxtheme handles. Currently they are just void pointers to > the internal structures. All other libraries do it using a handle > table [1, 2, 3]. Right. > 2. Move all MSSTYLES-related code to winemsstyles.drv. At this step > such uxtheme functions as DrawThemeBackground will be stubbed. I don't think this step is needed, MSSTYLES stuff could stay in uxtheme, acting similar to null driver from user32. > 3. Add support for uxtheme drivers. At the startup the registry key > HKCU\Software\Wine\Drivers\Theme will be read. This is a comma- > separated list such as "gtk3,qt5,mac,msstyles". In the loop all > drivers will be tried until the working one found. Note the > suggested order. If winegtk3.drv see the DESKTOP_SESSION > environment variable is set to KDE, it should return FALSE from the > entry point, so wineqt5.drv will be tried. This is a bug founded by > Ruslan Kabatsayev last year [4]. If nothing found, the last one > (winemsstyles.drv) should be used. Just curious, did you explore the ways to implement qt5 variant (let alone mac)? > 4. Work on the activation context. This is a complex step I need to > describe separately... Class redirection context support is already there, user32 does not honor it, that's the problem. > 6. Add double buffering support to comctl32 (I hate flipping!!!) Some controls have double buffering mode, when working without theme. You mean here only the case when theme is active? > 7. Add support for animated transitions like Windows Vista does. What is affected by this exactly? > 8. Fix other problems in comctl32 that I hate... Sure, but could you give a draft list for that?

March 27, 2016

Re: [PATCH] winex11: Don't put a default icon on modal dialogs.

by Alex Henrie

2016-03-24 20:52 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> 2016-03-24 10:02 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: >>> I don't think you want to prefer the small one. If there's no big one at >>> all, maybe, but otherwise it's not going to give good results. >> >> If I don't change this line, my test program fails: Wine displays the >> big icon in the title bar when Windows displays the small icon there. > > That's the window manager doing it, right? I don't think we should stop > providing good icon data in order to trick the window manager into > displaying the small icon. We should provide all the information we > have, and let the window manager display it as it sees fit. Okay, that makes sense. Wine provides both a big icon and a small icon to the window manager, so either this is a bug in xfwm4 or it's xfwm4's intended behavior. I think I'll close the bug report as WONTFIX. Eventually, Wine will have a Wayland driver and there we'll always be drawing the window decorations ourselves anyway. -Alex

March 26, 2016

Re: [GSoC] Support of pluggable theming engines

by Ivan Akulinchev

I wrote a brief roadmap: 1. Improve uxtheme handles. Currently they are just void pointers to the internal structures. All other libraries do it using a handle table [1, 2, 3]. 2. Move all MSSTYLES-related code to winemsstyles.drv. At this step such uxtheme functions as DrawThemeBackground will be stubbed. 3. Add support for uxtheme drivers. At the startup the registry key HKCU\Software\Wine\Drivers\Theme will be read. This is a comma- separated list such as "gtk3,qt5,mac,msstyles". In the loop all drivers will be tried until the working one found. Note the suggested order. If winegtk3.drv see the DESKTOP_SESSION environment variable is set to KDE, it should return FALSE from the entry point, so wineqt5.drv will be tried. This is a bug founded by Ruslan Kabatsayev last year [4]. If nothing found, the last one (winemsstyles.drv) should be used. 4. Work on the activation context. This is a complex step I need to describe separately... 5. Implement Buffered Paint API [5]. 6. Add double buffering support to comctl32 (I hate flipping!!!) 7. Add support for animated transitions like Windows Vista does. 8. Fix other problems in comctl32 that I hate... 9. Move the existing code from uxthemegtk [6] to winegtk3.drv. 10. Improve winegt3.drv until the deadline ;-) [1] https://github.com/wine-mirror/wine/blob/master/dlls/gdi32/gdiobj.c [2] https://github.com/wine-mirror/wine/blob/master/dlls/winhttp/handle.c [3] https://github.com/wine-mirror/wine/blob/master/server/handle.c [4] https://www.winehq.org/pipermail/wine-devel/2015-July/108232.html [5] https://msdn.microsoft.com/en-us/library/windows/desktop/bb773257%28v=vs.85… [6] https://github.com/akulinchev/uxthemegtk

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

Err, it's "Direct3DRM Object", instead of "Direct3DRMObject", which I wrote by mistake. On Sat, Mar 26, 2016 at 11:42 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > Some notes: > > I played around with IDirect3DRM::CreateObject a bit, and it also returns > REGDB_E_CLASSNOTREG if the proper CLSID is not set. Another interesting > note is that passing the same CLSID that worked for CreateObject to > CoCreateInstance makes it fail. The SDK setup does in fact add the CLSID's > to the registry - it seems that the setup reads d3drm.inf, creates a couple > .reg files and runs that to create the registry entries. The only registry > entry related to d3drm which the setup adds is "Direct3DRMObject" whose > value is {4516EC41-8F20-11d0-9B6D-0000C0781BC3}, which matches that of > CLSID_CDirect3DRM. > I installed this SDK on my XP VM, yet the tests fail, hmm. > > I played around with different CLSCTX values as well - no luck so far. > > Cheers, > Aaryaman > > > On Sat, Mar 26, 2016 at 8:09 PM, Aaryaman Vasishta < > jem456.vasishta(a)gmail.com> wrote: > >> "regsvr32.exe d3drm.dll" returns an error saying DllRegisterServer was >> not found. >> >> I compiled the test below and ran it on an XP VM (which had the dx7 SDK >> installed) just to be sure that my native win8.1 box wasn't the issue: >> >> CoInitialize(NULL); >>> hr = CoCreateInstance(&CLSID_CDirect3DRM, NULL, CLSCTX_INPROC_HANDLER, >>> &IID_IDirect3DRM, &d3drm); >>> ok(hr == D3DRM_OK, "Got %#x for IID_IDirect3DRM\n", hr); >>> hr = CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, >>> CLSCTX_INPROC_HANDLER, &IID_IDirect3DRMTexture3, &texture3); >>> ok(hr == D3DRM_OK, "Got %#x for IID_IDirect3DRMTexture3\n", hr); >>> >> >> Got the following results: >> >> d3drm.c:4309: Test failed: Got 0x80040154 for IID_IDirect3DRM >>> d3drm.c:4311: Test failed: Got 0x80040154 for IID_IDirect3DRMTexture3 >>> >> >> >> On Sat, Mar 26, 2016 at 7:55 PM, Stefan Dösinger < >> stefandoesinger(a)gmail.com> wrote: >> >>> >>> >> CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, >>> CLSCTX_INPROC_SERVER, >>> >> &IID_IDirect3DRMTexture3, &texture3) returns REGDB_E_CLASSNOTREG. Am I >>> >> missing something? >>> >> >>> > Does it work for IDirect3DRM? It may not be supposed to work, although >>> > it's also possible d3drm.dll is just not properly registered. >>> If you copied d3drm.dll from XP you'll most likely have to register it >>> with regsvr32. >>> >> >> >

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

Some notes: I played around with IDirect3DRM::CreateObject a bit, and it also returns REGDB_E_CLASSNOTREG if the proper CLSID is not set. Another interesting note is that passing the same CLSID that worked for CreateObject to CoCreateInstance makes it fail. The SDK setup does in fact add the CLSID's to the registry - it seems that the setup reads d3drm.inf, creates a couple .reg files and runs that to create the registry entries. The only registry entry related to d3drm which the setup adds is "Direct3DRMObject" whose value is {4516EC41-8F20-11d0-9B6D-0000C0781BC3}, which matches that of CLSID_CDirect3DRM. I installed this SDK on my XP VM, yet the tests fail, hmm. I played around with different CLSCTX values as well - no luck so far. Cheers, Aaryaman On Sat, Mar 26, 2016 at 8:09 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > "regsvr32.exe d3drm.dll" returns an error saying DllRegisterServer was not > found. > > I compiled the test below and ran it on an XP VM (which had the dx7 SDK > installed) just to be sure that my native win8.1 box wasn't the issue: > > CoInitialize(NULL); >> hr = CoCreateInstance(&CLSID_CDirect3DRM, NULL, CLSCTX_INPROC_HANDLER, >> &IID_IDirect3DRM, &d3drm); >> ok(hr == D3DRM_OK, "Got %#x for IID_IDirect3DRM\n", hr); >> hr = CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, >> CLSCTX_INPROC_HANDLER, &IID_IDirect3DRMTexture3, &texture3); >> ok(hr == D3DRM_OK, "Got %#x for IID_IDirect3DRMTexture3\n", hr); >> > > Got the following results: > > d3drm.c:4309: Test failed: Got 0x80040154 for IID_IDirect3DRM >> d3drm.c:4311: Test failed: Got 0x80040154 for IID_IDirect3DRMTexture3 >> > > > On Sat, Mar 26, 2016 at 7:55 PM, Stefan Dösinger < > stefandoesinger(a)gmail.com> wrote: > >> >> >> CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, CLSCTX_INPROC_SERVER, >> >> &IID_IDirect3DRMTexture3, &texture3) returns REGDB_E_CLASSNOTREG. Am I >> >> missing something? >> >> >> > Does it work for IDirect3DRM? It may not be supposed to work, although >> > it's also possible d3drm.dll is just not properly registered. >> If you copied d3drm.dll from XP you'll most likely have to register it >> with regsvr32. >> > >

March 26, 2016

Re: [GSoC] Support of pluggable theming engines

by Ivan Akulinchev

> Having properly implemented user controls is far more important than > having partially working gtk3 disguise. One thing depends on another. When I worked on my own UxTheme implementation, I found that comctl32 likes to send 0 instead of properly arguments. It angered me. So if I want to get a perfect GTK3-theming, I have to fix comctl32 too.

March 26, 2016

Re: [GSoC] Support of pluggable theming engines

by Nikolay Sivov

On 26.03.2016 20:24, Ivan Akulinchev wrote: > Hi André! > > Well, I didn't do exact calculations. But as I wrote, the theming > support in comctl32.dll done wrong. As far I know, the authors are aware > of this, but have no time or wish to fix it (just see their tests marked > as todo_wine, all this tests done right). > >> Is it currently needed for the gtk3 code in wine-staging? > > Yep. Try to run winecfg, select any theme, launch any application. Find > a themed button, push it and hold. See what's happend? There was a patch > for fixing it [1], another one [can't find a link], but all this patches > were not accepted, because the common problem lies above. > > Now open notepad, click Help -> About, see what's happend? The whole > dialog is not themed! I already tryed to locate this problem. > shell32.dll called user32.dll, which created a dialog. But user32 has > it's own controls and wasn't aware comctl32.dll has another. That's > because the theming support in comctl32.dll done in the wrong way. > > The whole theming support in comctl32 is a big hack. So I can write some > hacks for hacks, but why? What should do the next guy, who decides to > add some hacks for hacks for hacks? :-) It's a dead way... If you're talking about comctl32 v6 separation, that's true, it's not working right now. Getting it right could be a gsoc project on its own, and the way to approach it has to be discussed beforehand. Theming support is minor issue though comparing to missing new features for Button for example, and likely for the rest of former user32 controls too. Having properly implemented user controls is far more important than having partially working gtk3 disguise, I agree with you, making it work without hacks is a preferred way. > > [1] https://www.winehq.org/pipermail/wine-patches/2015-August/141599.html > > 26.03.16 15:47, André Hentschel wrote: >> Hi Ivan, all, >> >> You say in your proposal that you want to start with rewriting 30% of comctl32. >> Why so much? >> Is it currently needed for the gtk3 code in wine-staging? >> > >

March 26, 2016

Re: [GSoC] Support of pluggable theming engines

by Ivan Akulinchev

Hi André! Well, I didn't do exact calculations. But as I wrote, the theming support in comctl32.dll done wrong. As far I know, the authors are aware of this, but have no time or wish to fix it (just see their tests marked as todo_wine, all this tests done right). > Is it currently needed for the gtk3 code in wine-staging? Yep. Try to run winecfg, select any theme, launch any application. Find a themed button, push it and hold. See what's happend? There was a patch for fixing it [1], another one [can't find a link], but all this patches were not accepted, because the common problem lies above. Now open notepad, click Help -> About, see what's happend? The whole dialog is not themed! I already tryed to locate this problem. shell32.dll called user32.dll, which created a dialog. But user32 has it's own controls and wasn't aware comctl32.dll has another. That's because the theming support in comctl32.dll done in the wrong way. The whole theming support in comctl32 is a big hack. So I can write some hacks for hacks, but why? What should do the next guy, who decides to add some hacks for hacks for hacks? :-) It's a dead way... [1] https://www.winehq.org/pipermail/wine-patches/2015-August/141599.html 26.03.16 15:47, André Hentschel wrote: > Hi Ivan, all, > > You say in your proposal that you want to start with rewriting 30% of comctl32. > Why so much? > Is it currently needed for the gtk3 code in wine-staging? >

March 26, 2016

Re: [GSOC] Implement rendering for Direct3D Retained Mode

by Aaryaman Vasishta

A note about my commitments over the summer: I have an internship which ends on June 3rd. That'll overlap with the coding period for 10-11 days, which I will try to offset as much as I can by working on weekends during the month of may. I also have a final project review somewhere in June, but that'll probably just take half a day or so. My final exams should get over by mid-may. Other than that, I have no other commitments during the summer and I'll be working full-time for this project. Cheers, Aaryaman On Sat, Mar 26, 2016 at 8:31 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > Hi, > > I have applied to GSoC this year, and I'm intending to continue my work on > d3drm over this summer. Please review the proposal and provide > feedback/comments, it would be very appreciated :) > > Cheers, > Aaryaman >

March 26, 2016

[GSOC] Implement rendering for Direct3D Retained Mode

by Aaryaman Vasishta

Hi, I have applied to GSoC this year, and I'm intending to continue my work on d3drm over this summer. Please review the proposal and provide feedback/comments, it would be very appreciated :) Cheers, Aaryaman

March 26, 2016

[GSoC] Mailinglist discussions

by André Hentschel

Hi, This year it's not possible to communicate with the GSoC Students over the GSoC-Project site. I guess the reason is to force communication with the community. Thus I suggest to move the discussions to wine-devel and prefix them with [GSoC] Thx

March 26, 2016

[GSoC] Support of pluggable theming engines

by André Hentschel

Hi Ivan, all, You say in your proposal that you want to start with rewriting 30% of comctl32. Why so much? Is it currently needed for the gtk3 code in wine-staging?

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

"regsvr32.exe d3drm.dll" returns an error saying DllRegisterServer was not found. I compiled the test below and ran it on an XP VM (which had the dx7 SDK installed) just to be sure that my native win8.1 box wasn't the issue: CoInitialize(NULL); > hr = CoCreateInstance(&CLSID_CDirect3DRM, NULL, CLSCTX_INPROC_HANDLER, > &IID_IDirect3DRM, &d3drm); > ok(hr == D3DRM_OK, "Got %#x for IID_IDirect3DRM\n", hr); > hr = CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, > CLSCTX_INPROC_HANDLER, &IID_IDirect3DRMTexture3, &texture3); > ok(hr == D3DRM_OK, "Got %#x for IID_IDirect3DRMTexture3\n", hr); > Got the following results: d3drm.c:4309: Test failed: Got 0x80040154 for IID_IDirect3DRM > d3drm.c:4311: Test failed: Got 0x80040154 for IID_IDirect3DRMTexture3 > On Sat, Mar 26, 2016 at 7:55 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > > >> CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, CLSCTX_INPROC_SERVER, > >> &IID_IDirect3DRMTexture3, &texture3) returns REGDB_E_CLASSNOTREG. Am I > >> missing something? > >> > > Does it work for IDirect3DRM? It may not be supposed to work, although > > it's also possible d3drm.dll is just not properly registered. > If you copied d3drm.dll from XP you'll most likely have to register it > with regsvr32. >

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Stefan Dösinger

>> CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, CLSCTX_INPROC_SERVER, >> &IID_IDirect3DRMTexture3, &texture3) returns REGDB_E_CLASSNOTREG. Am I >> missing something? >> > Does it work for IDirect3DRM? It may not be supposed to work, although > it's also possible d3drm.dll is just not properly registered. If you copied d3drm.dll from XP you'll most likely have to register it with regsvr32.

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Henri Verbeet

On 26 March 2016 at 12:48, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > By CoCreateObject(), did you mean CoCreateInstance()? I couldn't find > CoCreateObject in the documentation or MSDN. > Right, CoCreateInstance(). > CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, CLSCTX_INPROC_SERVER, > &IID_IDirect3DRMTexture3, &texture3) returns REGDB_E_CLASSNOTREG. Am I > missing something? > Does it work for IDirect3DRM? It may not be supposed to work, although it's also possible d3drm.dll is just not properly registered.

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

By CoCreateObject(), did you mean CoCreateInstance()? I couldn't find CoCreateObject in the documentation or MSDN. CoCreateInstance(&CLSID_CDirect3DRMTexture, NULL, CLSCTX_INPROC_SERVER, &IID_IDirect3DRMTexture3, &texture3) returns REGDB_E_CLASSNOTREG. Am I missing something? On Sat, Mar 26, 2016 at 4:38 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 26 March 2016 at 10:19, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > What can probably be done is, making InitFromFile call > d3drm_create_image, > > checking if D3DRMIMAGE struct isn't set already, and LoadTexture will > call > > InitFromFIle (on a fresh new object every time LoadTexture is called), > > whereas CreateTexture will merely HeapAlloc the object and assign the > image > > supplied by the application. > > > CreateTexture() should probably call InitFromImage(), or some > equivalent, although it's odd that that only exists since > IDirect3DRMTexture2. It would also be interesting to know if > CoCreateObject() works, mainly because you can't pass the IDirect3DRM > interface to the texture in that case. >

March 26, 2016

Re: [PATCH 1/3] msvcrt: Call C structured exception translator in x86_64 __CxxFrameHandler

by Piotr Caban

Please ignore this patches for now, they are too buggy. It was working quite well in my tests but crashes with most real applications. Looks like local unwinding is implemented incorrectly. Thanks, Piotr

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Henri Verbeet

On 26 March 2016 at 10:19, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > What can probably be done is, making InitFromFile call d3drm_create_image, > checking if D3DRMIMAGE struct isn't set already, and LoadTexture will call > InitFromFIle (on a fresh new object every time LoadTexture is called), > whereas CreateTexture will merely HeapAlloc the object and assign the image > supplied by the application. > CreateTexture() should probably call InitFromImage(), or some equivalent, although it's odd that that only exists since IDirect3DRMTexture2. It would also be interesting to know if CoCreateObject() works, mainly because you can't pass the IDirect3DRM interface to the texture in that case.

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

What can probably be done is, making InitFromFile call d3drm_create_image, checking if D3DRMIMAGE struct isn't set already, and LoadTexture will call InitFromFIle (on a fresh new object every time LoadTexture is called), whereas CreateTexture will merely HeapAlloc the object and assign the image supplied by the application. On Sat, Mar 26, 2016 at 2:46 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > For now I used CreateTexture (as the documentation suggested) another way > is CreateTextureFromSurface, but that didn't work either (after passing it > an off-screen plain surface). > > I called IDirect3DRM3_CreateObject(d3drm3, &CLSID_CDirect3DRMTexture, > NULL, &IID_IDirect3DRMTexture3, &texture3), which works, then calling > InitFromFile on texture3 also returns successfully. It seems that if the > image struct is not set within the object, only then InitFromFile works (as > InitFromFile didn't work when called on a texture created from LoadTexture > or CreateTexture, both of which initialize the image struct member). > > On Sat, Mar 26, 2016 at 3:03 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > >> On 25 March 2016 at 22:20, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> >> wrote: >> > I wrote a quick test, and it seems that InitFromFile always returns >> > D3DRMERR_BADOBJECT, even after passing it an IDirect3DRMTexture created >> via >> > CreateTexture. >> How are you creating the texture? The interesting cases are probably >> CoCreateInstance() and IDirect3DRM_CreateObject(). >> > >

March 26, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

For now I used CreateTexture (as the documentation suggested) another way is CreateTextureFromSurface, but that didn't work either (after passing it an off-screen plain surface). I called IDirect3DRM3_CreateObject(d3drm3, &CLSID_CDirect3DRMTexture, NULL, &IID_IDirect3DRMTexture3, &texture3), which works, then calling InitFromFile on texture3 also returns successfully. It seems that if the image struct is not set within the object, only then InitFromFile works (as InitFromFile didn't work when called on a texture created from LoadTexture or CreateTexture, both of which initialize the image struct member). On Sat, Mar 26, 2016 at 3:03 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 25 March 2016 at 22:20, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > I wrote a quick test, and it seems that InitFromFile always returns > > D3DRMERR_BADOBJECT, even after passing it an IDirect3DRMTexture created > via > > CreateTexture. > How are you creating the texture? The interesting cases are probably > CoCreateInstance() and IDirect3DRM_CreateObject(). >

March 26, 2016

Re: [PATCH 5/5] d3d9/tests: Add a test for color varyings clamping.

by Marvin

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=21679 Your paranoid android. === w8 (32 bit visual) === visual.c:21659: Test failed: Got unexpected color 0x00808080, case 1. === w864 (32 bit visual) === visual.c:21659: Test failed: Got unexpected color 0x00808080, case 1. === w1064 (32 bit visual) === visual.c:21659: Test failed: Got unexpected color 0x00808080, case 1. === w864 (64 bit visual) === visual.c:21659: Test failed: Got unexpected color 0x00808080, case 1. === w1064 (64 bit visual) === visual.c:21659: Test failed: Got unexpected color 0x00808080, case 1.

March 25, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Henri Verbeet

On 25 March 2016 at 22:20, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > I wrote a quick test, and it seems that InitFromFile always returns > D3DRMERR_BADOBJECT, even after passing it an IDirect3DRMTexture created via > CreateTexture. How are you creating the texture? The interesting cases are probably CoCreateInstance() and IDirect3DRM_CreateObject().

March 25, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

On Fri, Mar 25, 2016 at 1:12 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > Sure, but it's useful to have some idea what those functions are > supposed to do. Right now, I think it looks like you should be able to > implement LoadTexture() by creating a texture and then calling > InitFromFile() on it. And related to above, InitFromFile() should then > probably check that the texture hasn't been initialised before. > I wrote a quick test, and it seems that InitFromFile always returns D3DRMERR_BADOBJECT, even after passing it an IDirect3DRMTexture created via CreateTexture. It even fails on version 3 (my suspicion was that maybe version 1 and 2 were deprecated and version 3 works, but that doesn't seem the case). I ran them on my windows machine, but I can send a diff to the testbot if you want. CreateTexture will also only work when it's fed with a complete and valid image struct. Passing NULL to buffer1 made it fail again. I can confirm that CreateTexture only keeps a pointer copy to the application-created image struct, instead of deep copying the contents of it in seperate memory. The docs have also been pretty vague about the type of file that InitFromFile wants, describing the filename parameter as "A string that specifies the file from which the texture initialization information is drawn". I suspect that it might be some proprietary format specifying the contents of an image struct, along with the buffer arrays. But I could be wrong. For now I'll include all your other suggestions and leave this for further discussion, while I submit the improved patch. Thanks for the review and clarifications! Cheers, Aaryaman

March 25, 2016

Re: Need some advice on shell32

by Mathy Vanvoorden

2016-03-25 16:15 GMT+01:00 Vincent Povirk <madewokherd(a)gmail.com>: > You didn't copy the list. Was that intentional? > Sorry, it was not, I recently switched to gmail and didn't notice the mailinglist fell off the CC list. > Related: While doing the research I came across some people trying to find > > out if the user is showing hidden files and there are some references to > > checking > Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden, > > would it not make sense to store the setting there in the same way > instead > > of the wine config? I'm not sure what the policy on this is. > > I'd consider "Are dotfiles hidden files?" and "Should shell views > display hidden files?" two distinct questions that should have > distinct settings. > I agree, they are.

March 25, 2016

Re: Allowing child HWND to be shared across multiple processes

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I don't have an answer to your question, but I want to make sure you get some reply. This mailing list is the correct place to ask, and the lack of replies most likely means that nobody else knows what could be wrong in your case. Did you already try to run this application on Wine? If you did, and it doesn't work (I assume that otherwise you wouldn't have sent a mail), can you describe what goes wrong? (e.g. "GetDC on the remote HWND fails", or function XYZ crashes). You observed correctly that only top level windows in Wine have a matching X11 window. Child windows are managed purely in Wine. The reason for this are some message handling differences between Windows and X11. Generally cross-process HWND access should work on X11 (but afaik not on OSX, but that knowledge is about 7 years old). There are plenty of applications that do this kind of thing. Though it is certainly possible that child windows are a case that's rarely used. (Though I think Google chrome draws tabs in separate processes, and I'd assume they're child windows...) Cheers, Stefan Am 2016-03-22 um 19:18 schrieb Brandon Adkins: > > Hi guys. > > If this is the wrong forum for this question, please direct me to > the correct one. > > I am working on porting a Windows application over to Linux, and my > hope is to use Wine to make that go as quickly as possible. In my > research, I have found one possible hangup, and hopefully you guys > can answer it in a few minutes, vs the week or so of work for me to > test it out myself. > > Long story short, I have an application which creates child HWNDs. > The application also launches separate processes. When WM_PAINT > messages come in for those child HWNDs, it passes the HWND to one > of the other processes, and that other process is the one that > actually draws on it. > > This works great on Windows. But I have found out that Wine only > makes XWindows for top level HWNDs. So my question is: Can an > application in wine perform operations (like drawing, BitBlting) > onto a child HWND owned by another process? > > Any tips or guidance you can give will be greatly appreciated. > > Best regards! > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW9WMPAAoJEN0/YqbEcdMwz38QAJhG0VVenZ7V15njKS2aDRW0 yG6Ba5HBSksirHrN45xl0QS3GxeoAhsXvUBc2USDZH4UjLr6fFR2R1sN7ZNIGe2T FXIFEtayiyD5SJuJqr7Rjy9Riauoi33rCNklI16p180zNA/5CKWHHfDKF662P8L4 Qa7Md/IYIPuWhelntXz0wVj0wtBDbx5K7qTpAjRWvv6KZ4VRggC9JJM3k0srD3cD NcCmTT9KbzzvURdA1JXftUJAdi09nXM3Et0eCeOmdKL+GYHbAFC/+oARggSoOHmT GVfSPNNlNRZfnu0vtQu6VaQOVUlRmmPD/HVVVD3015OE8DXbUjfsFxqLQXLnBzq3 98cfuEbkMs69oWEdT4nzNJi6Uu92roU0g1t1WswNK7AEhbpw7LIPvpKTrRhCu4Rn Fykjj+l4S8rZPNg2n770ge0Pkf7AFFAZtYmk6vFz55J2Peb2v+a68fA36LrgXeBZ r05RWlLqMSM5A0c+WVm/MojvpxvFwPk0tW4kZ2s7jSaxzMp2oIwm5QNO+Y89i/zV /AEP0sSHB/XM5DfgK9NZ9xa3noLinjnPrxkb27kiEOedb40QBQCiF1Iyn29xUKqk Qa2EGkUvnOhbxee9kaTm4FnCDJwaoWW9vF6a970xcEvQ30x1ZKgbK6Y75WJEDV3l iPaWI05/lzpBu3FR9M39 =sCxd -----END PGP SIGNATURE-----

March 25, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Francois Gouget

On Fri, 25 Mar 2016, Bernhard Übelacker wrote: [...] > one point that could be related is the usage of function local static > variables. When all of these got the "static" removed, I do not get the > failures anymore. However I could not prove this with testbot as an empty > patch did also succeed. The TestBot's build machine is still on Debian 7 (though it should be upgraded at some point). That would explain the difference. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

March 25, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Bernhard Übelacker

Hello, Am 23.03.2016 um 14:05 schrieb Francois Gouget: > On Wed, 23 Mar 2016, Francois Gouget wrote: > [...] >> * I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which >> was not failing according to the test.winehq.org results. But all I >> got is failures: >> - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: >> https://testbot.winehq.org/JobDetails.pl?Key=21611 >> - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: >> https://testbot.winehq.org/JobDetails.pl?Key=21610 >> - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here >> https://testbot.winehq.org/JobDetails.pl?Key=21609 >> My MinGW compiler is more recent than the one WineHQ was using before >> the upgrade however. So I think this points to a compiler-related >> issue. > > Recompiling the crosstest with -O0 gets rid of the failures: > - bd332f53 -O0 dinput8:dinput test > https://testbot.winehq.org/JobDetails.pl?Key=21616 > > So it does look like a compiler issue. > one point that could be related is the usage of function local static variables. When all of these got the "static" removed, I do not get the failures anymore. However I could not prove this with testbot as an empty patch did also succeed. Kind regards, Bernhard https://testbot.winehq.org/JobDetails.pl?Key=21671 https://testbot.winehq.org/JobDetails.pl?Key=21672 My local versions: - package gcc-mingw-w64-i686 4.9.1-19+14.3 - Debian Jessie 8.3.

March 25, 2016

Re: [PATCH] winex11: Don't put a default icon on modal dialogs.

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > 2016-03-24 10:02 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: >> I don't think you want to prefer the small one. If there's no big one at >> all, maybe, but otherwise it's not going to give good results. > > If I don't change this line, my test program fails: Wine displays the > big icon in the title bar when Windows displays the small icon there. That's the window manager doing it, right? I don't think we should stop providing good icon data in order to trick the window manager into displaying the small icon. We should provide all the information we have, and let the window manager display it as it sees fit. -- Alexandre Julliard julliard(a)winehq.org

March 25, 2016

Re: Need some advice on shell32

by Vincent Povirk

> I have traced this back to the fact that the ShowDotFiles option is only > checked in the NT functions in ntdll, but notepad (and notepad++) use the > comdlg32 open dialog which does not use those NT functions but the shell32 > ones. > > It seems to me that the comdlg32 open dialog should check if ShowDotFiles is > active and if so, to pass the SHCONTF_INCLUDEHIDDEN flag to the shell32 > objects. But I might (probably?) be wrong. I think that shell32 in shfldr_unixfs.c should check this setting instead. Since it's skipping ntdll and using the Unix file APIs directly, it should report the same thing to applications that ntdll does, namely that dotfiles are not hidden files.

March 25, 2016

Need some advice on shell32

by Mathy Vanvoorden

Hello, In an effort to get myself acquainted with the code I searched for some bugs I might be able to solve in Bugzilla. I found this one: https://bugs.winehq.org/show_bug.cgi?id=32079 Basically it says that an open file dialog in for example notepad or notepad++ doesn't show hidden files when the "Show hidden files" option is set in winecfg. I have traced this back to the fact that the ShowDotFiles option is only checked in the NT functions in ntdll, but notepad (and notepad++) use the comdlg32 open dialog which does not use those NT functions but the shell32 ones. It seems to me that the comdlg32 open dialog should check if ShowDotFiles is active and if so, to pass the SHCONTF_INCLUDEHIDDEN flag to the shell32 objects. But I might (probably?) be wrong. Can someone verify that this is the way to go before I start writing a patch? -- Met vriendelijke groeten, Best regards, Mathy Vanvoorden

March 24, 2016

Re: [PATCH] riched20: Implement ITextRange::ScrollIntoView.

by Adam Buchbinder

On Wed, Mar 23, 2016 at 5:00 AM, Huw Davies <huw(a)codeweavers.com> wrote: > > On Tue, Mar 22, 2016 at 03:29:10PM -0700, Adam Buchbinder wrote: > > On Tue, Mar 22, 2016 at 2:09 AM, Huw Davies <huw(a)codeweavers.com> wrote: > > More importantly, I get a test failure: > > richole.c:785: Test failed: Moved scrollbar is at 60, should be 0. > > (Range 0-160.) > > > > Where? The TestBot completed okay in a variety of environments: > > > > https://testbot.winehq.org/JobDetails.pl?Key=21524 > > > > and it works on my local workstation. The trace points to a helper function, > > which is being called with expected_nonzero = 0. There are four calls in > > test_ITextRange_ScrollIntoView which could be behind this; without logging > > information or a stack trace, I can't tell what's breaking. > > It's failing for me on both OS/X and linux. Note, it's the > implementation that's failing, the tests themselves are fine. Did you > try running 'make test' on your local machine? > > Huw. Aargh! That's my bad; I *thought* I'd tested it. Implementing bStart = tomEnd is proving problematic, so I've reduced the scope, and I'll be sending a v2 patch to wine-patches@ shortly. Sorry about the noise! Adam Buchbinder

March 24, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Henri Verbeet

On 23 March 2016 at 20:05, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > On windows, IDirect3DRMTexture*::Load creates a new texture every time you > call it on the same texture pointer, effectively losing the old one and > creating a leak. The refcount also increases by one every time a new texture > is created. So if windows allows this, I guess it's fine. Do let me know if > I've missed testing something here though. > So the image can't be replaced after it has been set. > AFAICS on the trace logs of d3drm games ran so far, I haven't encountered > CreateTexture spefically. Though you can find usage of CreateTexture in the > "Trans" demo from the DX7 SDK, within trans.cpp. After a quick glance I can > confirm that it does indeed create a texture on an existing image in memory. > The implementation for this should be fairly trivial, but some tests would > be needed to check if it does a shallow/deep copy of the image struct (as > you mentioned), validation checks, if any, and its refcounting behavior. > > I'm not sure about the Init methods, but so far I haven't been able to see > them being used anywhere. > > I've initially decided to prioritize on functions that are actually used by > games rather than implementing functions that are probably not used at all > in the d3drm apps that ran on wine so far. But I don't mind doing them if > they're required somehow, or if a bug reports it. > Sure, but it's useful to have some idea what those functions are supposed to do. Right now, I think it looks like you should be able to implement LoadTexture() by creating a texture and then calling InitFromFile() on it. And related to above, InitFromFile() should then probably check that the texture hasn't been initialised before. > Right, I could use it to check if the size matches the size specifed in the > header field bfSize within BITMAPFILEHEADER. Or maybe there's another use > than this? > Mostly to make sure you don't read past the end of the buffer. >> > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, >> > BOOL palette, BOOL upside_down) >> > +{ >> > + D3DRMPALETTEENTRY *colors = (D3DRMPALETTEENTRY >> > *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 257 * sizeof(*colors)); >> Is "257" there intentional? The cast is unnecessary. HeapAlloc() can >> fail. Do you need HEAP_ZERO_MEMORY here? > > I kept it as 257 so that accessing colors[256] shouldn't segfault. The > approach I used here is to check if the total number of unique colors is > greater than 256, which happens when the 257th unique color is also stored > into the array. > It's probably better to just avoid writing it. > I guess statically allocating it on the stack i.e declaring > D3DRMPALETTEENTRY colors[257]; could possibly help avoid the HeapAlloc > failures. Makes sense since the 257 is hard-coded anyways. Should I do that? > Or is the HeapAlloc a better approach? > HeapAlloc() is fine, you just need to handle the failure.

March 24, 2016

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.

by Henri Verbeet

On 24 March 2016 at 09:56, Paul Gofman <gofmanp(a)gmail.com> wrote: > L8 render targets through GL_R8 internal format work fine on both > Intel and Nvidia. I am attaching a small patch which can be applied on > top of Matteo's patchset (it reorders L8_UNORM format records and adds a > color fixup). That patch would be ok, but you should move the existing L8_UNORM fixup instead of just adding an extra one.

March 24, 2016

Re: jscript: Added a few more arguments tests.

by Jacek Caban

On 03/24/16 17:49, Sebastian Lackner wrote: > On 24.03.2016 16:39, Jacek Caban wrote: >> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> >> --- >> dlls/jscript/tests/lang.js | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) > Was it intentional that the newly added function is never called? Not it's not, good catch, thanks. That's a typo while extracting that from my huge WIP diff. I will fix it. Thanks, Jacek

March 24, 2016

Re: jscript: Added a few more arguments tests.

by Sebastian Lackner

On 24.03.2016 16:39, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/jscript/tests/lang.js | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) Was it intentional that the newly added function is never called?

March 24, 2016

Re: [PATCH] winex11: Don't put a default icon on modal dialogs.

by Alex Henrie

2016-03-24 10:02 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> 2016-03-24 6:53 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: >>> Alex Henrie <alexhenrie24(a)gmail.com> writes: >>> >>>> @@ -611,7 +612,7 @@ static void fetch_icon_data( HWND hwnd, HICON icon_big, HICON icon_small ) >>>> if (!icon_small) icon_small = (HICON)GetClassLongPtrW( hwnd, GCLP_HICONSM ); >>>> } >>>> >>>> - if (!GetIconInfo(icon_big, &ii)) return; >>>> + if (!GetIconInfo(icon_small, &ii) && !GetIconInfo(icon_big, &ii)) return; >>> >>> This doesn't make sense. What are you trying to do? >> >> I'm trying to make the function not fail if there is no big icon, and >> at the same time prefer the small icon over the big icon. What's the >> right way? > > I don't think you want to prefer the small one. If there's no big one at > all, maybe, but otherwise it's not going to give good results. If I don't change this line, my test program fails: Wine displays the big icon in the title bar when Windows displays the small icon there. I'm sure that there's a way to improve this function, I'm just not sure how. -Alex

March 24, 2016

Re: [PATCH] winex11: Don't put a default icon on modal dialogs.

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > 2016-03-24 6:53 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: >> Alex Henrie <alexhenrie24(a)gmail.com> writes: >> >>> @@ -611,7 +612,7 @@ static void fetch_icon_data( HWND hwnd, HICON icon_big, HICON icon_small ) >>> if (!icon_small) icon_small = (HICON)GetClassLongPtrW( hwnd, GCLP_HICONSM ); >>> } >>> >>> - if (!GetIconInfo(icon_big, &ii)) return; >>> + if (!GetIconInfo(icon_small, &ii) && !GetIconInfo(icon_big, &ii)) return; >> >> This doesn't make sense. What are you trying to do? > > I'm trying to make the function not fail if there is no big icon, and > at the same time prefer the small icon over the big icon. What's the > right way? I don't think you want to prefer the small one. If there's no big one at all, maybe, but otherwise it's not going to give good results. -- Alexandre Julliard julliard(a)winehq.org

March 24, 2016

Re: [PATCH] winex11: Don't put a default icon on modal dialogs.

by Alex Henrie

2016-03-24 6:53 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> @@ -611,7 +612,7 @@ static void fetch_icon_data( HWND hwnd, HICON icon_big, HICON icon_small ) >> if (!icon_small) icon_small = (HICON)GetClassLongPtrW( hwnd, GCLP_HICONSM ); >> } >> >> - if (!GetIconInfo(icon_big, &ii)) return; >> + if (!GetIconInfo(icon_small, &ii) && !GetIconInfo(icon_big, &ii)) return; > > This doesn't make sense. What are you trying to do? I'm trying to make the function not fail if there is no big icon, and at the same time prefer the small icon over the big icon. What's the right way? -Alex

March 24, 2016

Re: jscript: Added a few more arguments tests.

by Marvin

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=21665 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

March 24, 2016

Re: [v3] bcrypt: Added BCryptHash function.

by Patrick Armstrong

Thanks for all the help with the reviews! > On Mar 24, 2016, at 2:53 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > > > >

March 24, 2016

Re: Possible security bug with unmount

by Lauri Kenttä

While security is a good concern, it's not the only concern. If "mountpoint-with-;ls" would indeed execute ls, it would also fail to unmount "mountpoint-with-;ls" and instead try to unmount only "mountpoint-with-". If that's true, the code should be fixed in any case. Actually mounting stuff with that kind of names happens easily with USB drives and udisks2. Like this: $ ntfslabel /dev/sdb1 "USB;echo foo" $ udisksctl mount --block-device /dev/sdb1 Mounted /dev/sdb1 at /run/media/user/USB;echo foo. $ ls /run/media/user 'USB;echo foo' -- Lauri Kenttä

March 24, 2016

Re: [PATCH] winex11: Don't put a default icon on modal dialogs.

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -611,7 +612,7 @@ static void fetch_icon_data( HWND hwnd, HICON icon_big, HICON icon_small ) > if (!icon_small) icon_small = (HICON)GetClassLongPtrW( hwnd, GCLP_HICONSM ); > } > > - if (!GetIconInfo(icon_big, &ii)) return; > + if (!GetIconInfo(icon_small, &ii) && !GetIconInfo(icon_big, &ii)) return; This doesn't make sense. What are you trying to do? -- Alexandre Julliard julliard(a)winehq.org

March 24, 2016

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.

by Paul Gofman

On 03/23/2016 06:27 PM, Henri Verbeet wrote: > On 23 March 2016 at 16:21, Paul Gofman <gofmanp(a)gmail.com> wrote: >> So I will try to find out what else can make it happy for now. If >> nothing really, then I will wait for Matteo's patch to test enabling >> WINED3DFMT_FLAG_RENDERTARGET for WINED3DFMT_L8_UNORM at that point. > If you want something to test with, the patch in question is at > https://source.winehq.org/patches/data/120300. You'll have to change > the order so that the ARB_TEXTURE_RG variant is preferred over the > WINED3D_GL_LEGACY_FORMATS one. > > L8 render targets through GL_R8 internal format work fine on both Intel and Nvidia. I am attaching a small patch which can be applied on top of Matteo's patchset (it reorders L8_UNORM format records and adds a color fixup). This makes L8 render target test run and succeed, as well as a Unity3D app, on Intel card also (unlike rendering to GL_LUMINANCE8). Just for the record, the app actually succeeds with Intel card on Windows 7 in a different way. It creates d3d11 device there (which fails under Wine for Intel card and succeeds under Windows 7), then (on Windows) falls back to Directx 9 rendering, but taking completely different path on caps estimation (takes it from its builtin per-vendor tables). When it fails with d3d11 device creation under Wine, it checks formats through CheckDeviceFormat and ultimately refuses to create some of the textures if D3DFMT_L8 is not supported as render target (while works seemingly flawless when it is).

March 24, 2016

Re: [PATCH 1/4] xmllite/writer: Handle initial and ready states in the rest of tested Write* methods

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + switch (This->state) > + { > + case XmlWriterState_Initial: > + return E_UNEXPECTED; > + case XmlWriterState_DocClosed: > + return WR_E_INVALIDACTION; > + default: > + ; > + } What's wrong with explicit 'break;' instead of weird ';'? -- Dmitry.

March 24, 2016

Re: oleaut32: add OleLoadPictureFile stub (try 2)

by Marcus Meissner

On Thu, Mar 24, 2016 at 11:17:08AM +0800, Dmitry Timoshkov wrote: > Austin English <austinenglish(a)gmail.com> wrote: > > > -422 stub OleLoadPictureFile > > +422 stdcall OleLoadPictureFile(long ptr) > ... > > +HRESULT WINAPI OleLoadPictureFile(VARIANT file, LPDISPATCH *picture) > > +{ > > + FIXME("(%p),stub!\n", picture); > > + return E_NOTIMPL; > > +} > > Is passing VARIANT by value supposed to be represented like this in a .spec > file? I think it is is tricky to represent. https://webcache.googleusercontent.com/search?q=cache:dYriaKiafRIJ:www.masm… We would need to specify as much longs as the variant struct is wide for the relay debugging to be correct :/ Ciao, Marcus

March 24, 2016

Re: oleaut32: add OleLoadPictureFile stub (try 2)

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > -422 stub OleLoadPictureFile > +422 stdcall OleLoadPictureFile(long ptr) ... > +HRESULT WINAPI OleLoadPictureFile(VARIANT file, LPDISPATCH *picture) > +{ > + FIXME("(%p),stub!\n", picture); > + return E_NOTIMPL; > +} Is passing VARIANT by value supposed to be represented like this in a .spec file? -- Dmitry.

March 24, 2016

Re: oleaut32: add OleLoadPictureFile stub

by Austin English

On Wed, Mar 23, 2016 at 1:07 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: >> + * OleLoadPictureFile (OLEAUT32.422) >> + */ >> +HRESULT WINAPI OleLoadPictureFile(VARIANT file, LPDISPATCH *picture) >> +{ >> + FIXME("(%p),stub!\n", picture); >> + return ERROR_CALL_NOT_IMPLEMENTED; >> +} >> + >> +/*********************************************************************** > > This should return an HRESULT, right? Probably E_NOTIMPL. > > Andrew Yes, thanks for catching Andrew. -- -Austin

March 24, 2016

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.

by Matteo Bruni

2016-03-23 16:27 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 23 March 2016 at 16:21, Paul Gofman <gofmanp(a)gmail.com> wrote: >> So I will try to find out what else can make it happy for now. If >> nothing really, then I will wait for Matteo's patch to test enabling >> WINED3DFMT_FLAG_RENDERTARGET for WINED3DFMT_L8_UNORM at that point. > If you want something to test with, the patch in question is at > https://source.winehq.org/patches/data/120300. You'll have to change > the order so that the ARB_TEXTURE_RG variant is preferred over the > WINED3D_GL_LEGACY_FORMATS one. I resent the patch (the new one is 120556), I left it mostly unchanged so you still need to reorder the table entries and enable the color fixups accordingly if you want to use the ARB_texture_rg variants on legacy contexts.

March 23, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Aaryaman Vasishta

On Wed, Mar 23, 2016 at 6:50 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > What happens when d3drm_texture_load() is called multiple times on the > same texture? Should that be possible? > On windows, IDirect3DRMTexture*::Load creates a new texture every time you call it on the same texture pointer, effectively losing the old one and creating a leak. The refcount also increases by one every time a new texture is created. So if windows allows this, I guess it's fine. Do let me know if I've missed testing something here though. > > + HeapFree(GetProcessHeap(), 0, texture->image->palette); > > + HeapFree(GetProcessHeap(), 0, texture->image); > This seems a bit suspicious. Supposedly the "image" argument to > d3drm3_CreateTexture() can be used to create a texture on an existing > image. The documentation isn't very explicit about it, but suggests > that the image data isn't copied in that case. So I'm not sure the > texture is supposed to be responsible for destroying the image. In > general I think it's not entirely clear how things like > CreateTexture(), LoadTexture() and InitFromFile() etc. are supposed to > interact. > AFAICS on the trace logs of d3drm games ran so far, I haven't encountered CreateTexture spefically. Though you can find usage of CreateTexture in the "Trans" demo from the DX7 SDK, within trans.cpp. After a quick glance I can confirm that it does indeed create a texture on an existing image in memory. The implementation for this should be fairly trivial, but some tests would be needed to check if it does a shallow/deep copy of the image struct (as you mentioned), validation checks, if any, and its refcounting behavior. I'm not sure about the Init methods, but so far I haven't been able to see them being used anywhere. I've initially decided to prioritize on functions that are actually used by games rather than implementing functions that are probably not used at all in the d3drm apps that ran on wine so far. But I don't mind doing them if they're required somehow, or if a bug reports it. > + size = GetFileSize(hfile, NULL); > > + if (size == INVALID_FILE_SIZE) > > + { > > + DeleteObject(hfile); > > + return D3DRMERR_BADVALUE; > > + } > You never use "size" after this, but you probably should. I also think > you meant CloseHandle() instead of DeleteObject(). > Right, I could use it to check if the size matches the size specifed in the header field bfSize within BITMAPFILEHEADER. Or maybe there's another use than this? > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, > BOOL palette, BOOL upside_down) > > +{ > > + D3DRMPALETTEENTRY *colors = (D3DRMPALETTEENTRY > *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 257 * sizeof(*colors)); > Is "257" there intentional? The cast is unnecessary. HeapAlloc() can > fail. Do you need HEAP_ZERO_MEMORY here? > I kept it as 257 so that accessing colors[256] shouldn't segfault. The approach I used here is to check if the total number of unique colors is greater than 256, which happens when the 257th unique color is also stored into the array. I guess statically allocating it on the stack i.e declaring D3DRMPALETTEENTRY colors[257]; could possibly help avoid the HeapAlloc failures. Makes sense since the 257 is hard-coded anyways. Should I do that? Or is the HeapAlloc a better approach? As for HEAP_ZERO_MEMORY, see below. > This is unsafe. Consider e.g. what happens when the header gives you > 0x10000 for width and height. > You're right. d3drm returns D3DRMERR_BADVALUE for textures with width and height that large. I'll add a test accordingly. I'll also be adding validation checks for bitmap format from the header, as you mentioned. > > > + buffer1 = image->buffer1; > > + memset(buffer1, 255, sizeof(unsigned char) * bpl * h); > You just initialised the memory with HEAP_ZERO_MEMORY, and now you're > overwriting it again. At least one of these two initialisations is > unnecessary, and quite possibly both of them. > > I actually intended to initialize it to 0xFF rather than zero. But you're right about the alloc's being unnecessary. I'll remove both initializations, and keep the default initialization to 0xFF as the byte padding in 32bpp bitmaps are all 0xFF. I also agree with the rest of the changes and will submit another patch very soon. Thanks for the detailed review! Really appreciate it. Cheers, Aaryaman

March 23, 2016

Re: Possible security bug with unmount

by Cédric Picard

On Wed, Mar 23, 2016 at 12:53:43PM -0500, Vincent Povirk wrote: > It's a potential issue in a situation when you have multiple users on > one machine that are allowed to mount discs or disc images without > root access, or if you have a CD with a malicious label that gets > copied into the mount point (though maybe automounters will escape the > label). > > I don't know that this can be turned into a real attack on its own, > but lack of imagination is not a good argument for something not being > a security risk. > > Thanks for your input, I opened a bug quoting Michael Müller's test-case: https://bugs.winehq.org/show_bug.cgi?id=40347 Cédric Picard

March 23, 2016

Re: oleaut32: add OleLoadPictureFile stub

by Andrew Eikum

> + * OleLoadPictureFile (OLEAUT32.422) > + */ > +HRESULT WINAPI OleLoadPictureFile(VARIANT file, LPDISPATCH *picture) > +{ > + FIXME("(%p),stub!\n", picture); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + > +/*********************************************************************** This should return an HRESULT, right? Probably E_NOTIMPL. Andrew

March 23, 2016

Re: Possible security bug with unmount

by Vincent Povirk

It's a potential issue in a situation when you have multiple users on one machine that are allowed to mount discs or disc images without root access, or if you have a CD with a malicious label that gets copied into the mount point (though maybe automounters will escape the label). I don't know that this can be turned into a real attack on its own, but lack of imagination is not a good argument for something not being a security risk.

March 23, 2016

Re: Possible security bug with unmount

by Marcus Meissner

On Wed, Mar 23, 2016 at 05:43:51PM +0100, Michael Müller wrote: > Am 23.03.2016 um 17:18 schrieb Marcus Meissner: > > Question is how to reach it... It is determined out of > > > > mount_point = get_device_mount_point ( st.st_rdev ) > > > > and not user supplied, but read out of mtab or /proc/mounts . > > Not sure if you can consider this a security risk since the windows > application can execute arbitrary opcodes anyway, but constructing such > a case is not difficult: > > mkdir "a;xterm" > mount ... "a;xterm" > > You will get "/dev/loop0 /home/michael/test/a;xterm iso9660 ro,relatime > 0 0" in /etc/mtab or /proc/mounts. > > I just tried it out using this code > (https://jon.limedaley.com/code/windows/eject/eject.c) and it will start > xterm. well, as you write ... if you can do such mounts or even execute windows binary code, then the system() call is harmless. ;) Ciao, Marcus

March 23, 2016

Re: Possible security bug with unmount

by Michael Müller

Am 23.03.2016 um 17:18 schrieb Marcus Meissner: > Question is how to reach it... It is determined out of > > mount_point = get_device_mount_point ( st.st_rdev ) > > and not user supplied, but read out of mtab or /proc/mounts . Not sure if you can consider this a security risk since the windows application can execute arbitrary opcodes anyway, but constructing such a case is not difficult: mkdir "a;xterm" mount ... "a;xterm" You will get "/dev/loop0 /home/michael/test/a;xterm iso9660 ro,relatime 0 0" in /etc/mtab or /proc/mounts. I just tried it out using this code (https://jon.limedaley.com/code/windows/eject/eject.c) and it will start xterm.

March 23, 2016

Re: [v2] d3d9: Add test for D3DFMT_L8 format as render target.

by Henri Verbeet

On 23 March 2016 at 17:17, Paul Gofman <gofmanp(a)gmail.com> wrote: > @@ -11295,10 +11296,10 @@ static void pixelshader_blending_test(void) > /* Quad with R=0x10, G=0x20 */ > quad1[] = > { > - {{-1.0f, -1.0f, 0.1f}, 0x80102000}, > - {{-1.0f, 1.0f, 0.1f}, 0x80102000}, > - {{ 1.0f, -1.0f, 0.1f}, 0x80102000}, > - {{ 1.0f, 1.0f, 0.1f}, 0x80102000}, > + {{-1.0f, -1.0f, 0.1f}, 0x80103000}, > + {{-1.0f, 1.0f, 0.1f}, 0x80103000}, > + {{ 1.0f, -1.0f, 0.1f}, 0x80103000}, > + {{ 1.0f, 1.0f, 0.1f}, 0x80103000}, > }, The patch looks fine at first sight, but you should probably either update the comment or just remove it.

March 23, 2016

Re: Possible security bug with unmount

by Marcus Meissner

On Wed, Mar 23, 2016 at 04:57:29PM +0100, Cédric Picard wrote: > Hi, > > I find that DIR_unmount_device in wine/dlls/ntdll/directory.c (latest > git) is looking like an unsafe use of system(). > > If a device was mounted to a point such as ";ls" I think it would be > passed to system and cause a command injection. > > I didn't open a bug because I wasn't able to really test it due to my > lack of knowledge of wine and because I can't think of a real world > attack based on this as it needs to mount a device first but I think > it's worth at least a thorough check. > Question is how to reach it... It is determined out of mount_point = get_device_mount_point ( st.st_rdev ) and not user supplied, but read out of mtab or /proc/mounts . Ciao, Marcus

March 23, 2016

Possible security bug with unmount

by Cédric Picard

Hi, I find that DIR_unmount_device in wine/dlls/ntdll/directory.c (latest git) is looking like an unsafe use of system(). If a device was mounted to a point such as ";ls" I think it would be passed to system and cause a command injection. I didn't open a bug because I wasn't able to really test it due to my lack of knowledge of wine and because I can't think of a real world attack based on this as it needs to mount a device first but I think it's worth at least a thorough check. Cédric Picard

March 23, 2016

Re: XInput and HID - architecture

by Roderick Colenbrander

On Wed, Mar 23, 2016 at 5:21 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > On 3/23/16 12:20 AM, Roderick Colenbrander wrote: >> On Tue, Mar 22, 2016 at 5:35 AM, Aric Stewart <aric(a)codeweavers.com> wrote: >>> On 3/21/16 7:27 PM, Roderick Colenbrander wrote: >>>> On Sat, Mar 19, 2016 at 10:59 AM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: >>>>> Hi, >>>>> >>>>> On 03/16/2016 02:45 AM, Roderick Colenbrander wrote: >>>>>> Hi Juan, >>>>>> >>>>>> Let me reply to the start of the thread before diving into the >>>>>> specifics on calibration. >>>>>> >>>>>> In my opinion, I'm not sure what the best way would be to handle >>>>>> passing of HID data to xinput. The main thing to consider as part of >>>>>> this is handling of non-native xinput devices (e.g. DS4 or >>>>>> SteamController) provided we want to support this. Aside from passing >>>>>> up the HID data the other challenge for xinput devices is the >>>>>> enumeration part, which many (older) games do through a mixture of >>>>>> WMI, dinput and xinput. For this to work we need to report an actual >>>>>> xinput gamepad. >>>>> Wine is supposed to mimic Windows' behavior as well as possible. Thus, >>>>> the proper way to implement xinput would be to access the USB devices >>>>> directly. The hid->xinput mapping is already non-compliant with the >>>>> windows behavior, but currently necessary. However, in my opinion, we >>>>> should only try to parse those HID descriptors that correspond to XInput >>>>> devices, as provided by common XInput->HID drivers on different host >>>>> OSs. Nevertheless, once wine's HID->Xinput backend is finished, the >>>>> end-users can (locally) add their own mappings for any HID controller >>>>> they want to use. I just wouldn't add those mappings to the wine repo. >>>>> I would like to get some input on that, however. Do you think we should >>>>> add mappings for non-xinput devices? >>>>> >>>>> Thank you for pointing out the enumeration process. The reason I >>>>> implemented Xinput was to play a game that didn't support any other >>>>> input method, so until now, I hadn't given it much thought. According to >>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ee417014%28v=vs.85… >>>>> , an XInput device shows up in DInput with an ID containing "IG_", which >>>>> is what developers should use to filter them out. This might make things >>>>> a bit difficult, since in Wine, both DInput and XInput devices are >>>>> supposed to be created from a common HID base, so Wine's DInput cannot >>>>> know anything about whether a device is an XInput device or not. >>>>>> >>>>>> My feeling would be for xinput to be quite stupid like it is on >>>>>> Windows and feed it xbox controller compatible HID reports with the >>>>>> same axes ranges, rumble ranges as the xbox controller. For more >>>>>> custom devices you may want to support special handling e.g. button >>>>>> emulation using touchpad on DS4 or maybe even on SteamController. >>>>> The problem is that there is not a unique HID descriptor set for XInput. >>>>> Each driver on each OS maps the xinput controls to a different layout, >>>>> so we need some logic on the Wine XInput driver to tell those apart and >>>>> map them back to XInput controls. >>>> >>>> Nonetheless a mapping is needed from evdev, optionally Linux hidraw >>>> and whatever backend other OSes use. HID is nice in theory, but in >>>> practice it is quite messy (many buggy devices, spec abuses, custom >>>> HID requests to enable a device..). My feeling is to handle the >>>> mapping to x360 at a level below xinput to avoid the mapping issues in >>>> xinput. Depending on what other non-native xinput devices we may want >>>> to handle (ds3, ds4, wii u controller, steam controller are all easy) >>>> you may want more control at a lower level to handle custom >>>> functionality, which could optionally need handling through many >>>> different fields in the HID descriptor (e.g. touch). >>>> >>> >>> The grand hope is that we can move all the platform specific code to HID and not have it reproduces in 3 different locations. We write dinput, winmm and Xinput to all be HID clients. >>> >>> You give a number of reasons that HID is messy, but I assume you are talking about windows native HID? Since right now we would be going through our own hid and hid minidrivers we are able to avoid a lot of that messiness. >> >> The main concern with HID is the way it is implemented by different >> devices. Spec abuse, custom initialization logic for different devices >> through device specific features requests, power management handling. >> Among places I would recommend to have a look at the many HID drivers >> in the Linux kernel patching up HID descriptors, doing custom device >> initialization (power management, wireless pairing). >> >> My main worry is the amount of device specific code needed in Wine to >> make HID useful for input and interpretation of HID data. For some of >> the popular devices it will be like writing a custom driver. I >> understand the desire for HID as maybe a way to avoid drivers e.g. on >> OSX where there is a decent layer but many people don't install >> gamepad drivers. >> >>> What are the specific areas that HID will be insufficient for xinput? Having specific examples will be helpful in figuring out a course of action. >> >> I see HID as a fine transport layer from xinput down to some lower >> layer (I think for the xinput use case we need to standardize on a >> certain layout). I'm worried about using it for the layers underneath >> as I will explain below mostly because I expect we will need much >> device specific code. > > > Right now, and for the foreseeable future, we control all the code from hid.dll down to the platform. So that includes hid.dll, hidclass.sys, the minidrivers and the plug and play driver/implementation. So HID is being used as a transport layer from xinput(dinput, winmm) down to the lower layer. > > On Linux I have written both a evdev and hidraw connection, mostly because the hidraw one was very easy. Now that the evdev one is working pretty well if you feel the hidraw one would be nothing but heart ache then I can drop that. > Even though I'm not a big fan of hidraw for gamepads, I would recommend keeping it. The main reason is not for input, but for custom devices. A lot of custom embedded / industrial devices these days use HID, while previously they used RS232 or an equivalent interface. For these devices HID is very simple and doesn't require drivers. Typically applications directly talk to these devices to the HID API or a helper dll using the HID API.

March 23, 2016

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.

by Henri Verbeet

On 23 March 2016 at 16:21, Paul Gofman <gofmanp(a)gmail.com> wrote: > So I will try to find out what else can make it happy for now. If > nothing really, then I will wait for Matteo's patch to test enabling > WINED3DFMT_FLAG_RENDERTARGET for WINED3DFMT_L8_UNORM at that point. If you want something to test with, the patch in question is at https://source.winehq.org/patches/data/120300. You'll have to change the order so that the ARB_TEXTURE_RG variant is preferred over the WINED3D_GL_LEGACY_FORMATS one. > So maybe then I will just modify a test case for now and resend it > without touching wined3d code? Sure, those changes should work on their own.

March 23, 2016

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.

by Paul Gofman

On 03/23/2016 05:48 PM, Henri Verbeet wrote: > On 23 March 2016 at 15:06, Paul Gofman <gofmanp(a)gmail.com> wrote: >> > How does it fail exactly? Does it fail to create a render target, or > does it just not like the result from CheckDeviceFormat()? Is there > any chance it would be happy with some other format instead, like e.g. > R8_UNORM? For what it's worth, I just checked on Windows, and both L8 > and L16 seem to be supported as render targets on AMD as well. It calls "d3d9_CheckDeviceFormat iface 0x13d108, adapter 0, device_type 0x1, adapter_format 0x16, usage 0x1, resource_type 0x3, format 0x32." in the beginning, which checks for L8 availablity as render target. It checks a lot of other formats the same way, most of them are OK. It just stores the flag based on the returned value at this point. Later when it comes to creating textures for render targets it does not attempt to create it but writes an error message 'RenderTexture.Create failed: format unsupported.' to stdout after checking the stored flag. It also checks L8A8 format the same way, but claming it available as render target did not seem to make it forget about L8 (I am not sure I checked it all correctly though, may need to recheck). Probably the simplest way to find out what else can it use is to find out how is it happy on Windows, I think I can do it. >> I know that GL spec does not suppose luminance as render target, and I >> could not find any extension on Nvidia so far which is responsible for >> allowing that. It just allows it, and does not give an error for >> glGetInternalformativ. > I'd like to avoid rendering to GL_LUMINANCE8 if we can, but GL_R8 with > appropriate swizzles may be an alternative. We'll need that to > implement luminance formats for core profiles anyway, and Matteo has a > patch for that. That patch doesn't enable WINED3DFMT_FLAG_RENDERTARGET > on WINED3DFMT_L8_UNORM yet, but it should be easy to add. > So I will try to find out what else can make it happy for now. If nothing really, then I will wait for Matteo's patch to test enabling WINED3DFMT_FLAG_RENDERTARGET for WINED3DFMT_L8_UNORM at that point. >> I can change the whole test to use different values to have different >> red and green channels after blending. I am just not sure how can I >> guess "broken" values for D3DMT_L8, as I do not have any hardware which >> has D3DFMT_L8 supported as RT and POSTPIXELSHADER_BLENDING not supported. >> > In theory the values should simply be the same as with > D3DRS_ALPHABLENDENABLE disabled. > So maybe then I will just modify a test case for now and resend it without touching wined3d code?

March 23, 2016

Re: XInput and HID - architecture

by Aric Stewart

On 3/23/16 9:59 AM, Nathan Schulte wrote: > On 03/23/2016 07:21 AM, Aric Stewart wrote: >> On Linux I have written both a evdev and hidraw connection, mostly because the hidraw one was very easy. Now that the evdev one is working pretty well if you feel the hidraw one would be nothing but heart ache then I can drop that. > > Would this prevent RawInput from working? There are a number of games that use the x360 controller but require RawInput for e.g. the triggers, or such things. I've forgotten the details, but I can re-investigate if it would be helpful. No, RawInput would be written on top of the win32 HID level. It has not been implemented but should not be too hard once the win32 HID level is in place as RawInput is pretty close to just raw HID. My first HID test program was actually a RawInput test program that I just made very minor modifications to make it use hid.dll instead. -aric > > -- > Nate

March 23, 2016

Re: XInput and HID - architecture

by Nathan Schulte

On 03/23/2016 07:21 AM, Aric Stewart wrote: > On Linux I have written both a evdev and hidraw connection, mostly because the hidraw one was very easy. Now that the evdev one is working pretty well if you feel the hidraw one would be nothing but heart ache then I can drop that. Would this prevent RawInput from working? There are a number of games that use the x360 controller but require RawInput for e.g. the triggers, or such things. I've forgotten the details, but I can re-investigate if it would be helpful. -- Nate

March 23, 2016

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.

by Henri Verbeet

On 23 March 2016 at 15:06, Paul Gofman <gofmanp(a)gmail.com> wrote: > On 03/23/2016 04:37 PM, Henri Verbeet wrote: >> Is this needed by an application? Luminance formats aren't supposed to >> be color-renderable according to the OpenGL spec, and that's why >> you're getting GL_INVALID_ENUM in query_internal_format(). Does NVIDIA >> have some extension that allows this? > This is somehow used with a Unity3D game. This makes it work flawlessly > with Nvidia under Wine. Though I found later that the same works under > Windows 7 with the similar Intel GPU (where Luminance is not allowed as > render target according to my test), so apparently it might work without > it somehow but I did not find yet what lets them get along without this > format. With Nvidia under Windows 7 unity uses Directx 11 (actually it > tries the same under Wine unless d3dx11.dll is disabled). How does it fail exactly? Does it fail to create a render target, or does it just not like the result from CheckDeviceFormat()? Is there any chance it would be happy with some other format instead, like e.g. R8_UNORM? For what it's worth, I just checked on Windows, and both L8 and L16 seem to be supported as render targets on AMD as well. > I know that GL spec does not suppose luminance as render target, and I > could not find any extension on Nvidia so far which is responsible for > allowing that. It just allows it, and does not give an error for > glGetInternalformativ. I'd like to avoid rendering to GL_LUMINANCE8 if we can, but GL_R8 with appropriate swizzles may be an alternative. We'll need that to implement luminance formats for core profiles anyway, and Matteo has a patch for that. That patch doesn't enable WINED3DFMT_FLAG_RENDERTARGET on WINED3DFMT_L8_UNORM yet, but it should be easy to add. > I can change the whole test to use different values to have different > red and green channels after blending. I am just not sure how can I > guess "broken" values for D3DMT_L8, as I do not have any hardware which > has D3DFMT_L8 supported as RT and POSTPIXELSHADER_BLENDING not supported. > In theory the values should simply be the same as with D3DRS_ALPHABLENDENABLE disabled.

March 23, 2016

Re: WineConf 2016

by Jeremy White

On 03/22/2016 02:26 PM, Tom Wickline wrote: > Hello Everyone, > > Would it be possible to set a location and date for WineConf 2016 at > this time? As no one outside of CodeWeavers has stepped up to host the > conference I take it the conference will be held once again in St. Paul? Just to be clear, we are quite cheerful to host WineConf 2016 in St. Paul. I suspect we'll want to hit the September/October time frame. We'll start looking around for venues which will then start to suggest dates. Cheers, Jeremy

March 23, 2016

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.

by Paul Gofman

On 03/23/2016 04:37 PM, Henri Verbeet wrote: > On 23 March 2016 at 09:56, Paul Gofman <gofmanp(a)gmail.com> wrote: >> Tested on Intel HD 4000 (L8 rt is not supported) and NVIDIA GeForce 650M >> (L8 rt supported). Changes in query_internal_format are for avoiding >> ERR in output when format is not supported as render target (RENDERTARGET >> flag is cleared in check_fbo_compat which is called later). > Is this needed by an application? Luminance formats aren't supposed to > be color-renderable according to the OpenGL spec, and that's why > you're getting GL_INVALID_ENUM in query_internal_format(). Does NVIDIA > have some extension that allows this? This is somehow used with a Unity3D game. This makes it work flawlessly with Nvidia under Wine. Though I found later that the same works under Windows 7 with the similar Intel GPU (where Luminance is not allowed as render target according to my test), so apparently it might work without it somehow but I did not find yet what lets them get along without this format. With Nvidia under Windows 7 unity uses Directx 11 (actually it tries the same under Wine unless d3dx11.dll is disabled). I know that GL spec does not suppose luminance as render target, and I could not find any extension on Nvidia so far which is responsible for allowing that. It just allows it, and does not give an error for glGetInternalformativ. >> @@ -11279,6 +11279,7 @@ static void pixelshader_blending_test(void) >> {"D3DFMT_R32F", D3DFMT_R32F, 0x0018ffff, 0x0020ffff}, >> {"D3DFMT_G32R32F", D3DFMT_G32R32F, 0x001818ff, 0x002010ff}, >> {"D3DFMT_A32B32G32R32F", D3DFMT_A32B32G32R32F, 0x00181800, 0x00201000}, >> + {"D3DFMT_L8", D3DFMT_L8, 0x00181818, 0x002010ff}, > The 0x002010ff there doesn't look right. It's also not exactly ideal > that the red and green channels end up with the same values after > blending, although that's and existing issue with the test. > > I can change the whole test to use different values to have different red and green channels after blending. I am just not sure how can I guess "broken" values for D3DMT_L8, as I do not have any hardware which has D3DFMT_L8 supported as RT and POSTPIXELSHADER_BLENDING not supported.

March 23, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Francois Gouget

It looks like usp10:usp10 is impacted too, but only for 64 bit builds, and only since the 18th instead of the 17th which is strange. Still compiling with -O0 instead of -O2 seems to fix the new failures: * 329dfee70c35 -O2 usp10:usp10 test 1 to 10 failures on Vista-Win8 in test.winehq.org, 1 here https://testbot.winehq.org/JobDetails.pl?Key=21620 * 329dfee70c35 -O0 usp10:usp10 test 0 failures https://testbot.winehq.org/JobDetails.pl?Key=21621 * bd332f53f2d7 -O2 usp10:usp10 test 0 failures on Vista-Win8 in test.winehq.org, 1 here https://testbot.winehq.org/JobDetails.pl?Key=21622 * bd332f53f2d7 -O0 usp10:usp10 test 0 failures https://testbot.winehq.org/JobDetails.pl?Key=21623 The last victim is wininet:url but only on some Windows XP VMs. Again compiling the test with -O0 fixes the failures. https://test.winehq.org/data/tests/wininet:url.html As far as I can tell these are the only tests that still have issues following the upgrade. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

March 23, 2016

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.

by Henri Verbeet

On 23 March 2016 at 09:56, Paul Gofman <gofmanp(a)gmail.com> wrote: > Tested on Intel HD 4000 (L8 rt is not supported) and NVIDIA GeForce 650M > (L8 rt supported). Changes in query_internal_format are for avoiding > ERR in output when format is not supported as render target (RENDERTARGET > flag is cleared in check_fbo_compat which is called later). Is this needed by an application? Luminance formats aren't supposed to be color-renderable according to the OpenGL spec, and that's why you're getting GL_INVALID_ENUM in query_internal_format(). Does NVIDIA have some extension that allows this? > @@ -11279,6 +11279,7 @@ static void pixelshader_blending_test(void) > {"D3DFMT_R32F", D3DFMT_R32F, 0x0018ffff, 0x0020ffff}, > {"D3DFMT_G32R32F", D3DFMT_G32R32F, 0x001818ff, 0x002010ff}, > {"D3DFMT_A32B32G32R32F", D3DFMT_A32B32G32R32F, 0x00181800, 0x00201000}, > + {"D3DFMT_L8", D3DFMT_L8, 0x00181818, 0x002010ff}, The 0x002010ff there doesn't look right. It's also not exactly ideal that the red and green channels end up with the same values after blending, although that's and existing issue with the test.

March 23, 2016

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

by Henri Verbeet

On 20 March 2016 at 19:24, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > - FIXME("iface %p, filename %s, texture %p stub!\n", iface, debugstr_a(filename), texture); > + TRACE("iface %p, filename %s, texture %p\n", iface, debugstr_a(filename), texture); Missing period. > @@ -853,15 +859,19 @@ static HRESULT WINAPI d3drm2_CreateUserVisual(IDirect3DRM2 *iface, > static HRESULT WINAPI d3drm2_LoadTexture(IDirect3DRM2 *iface, > const char *filename, IDirect3DRMTexture2 **texture) > { > - struct d3drm_texture *object; > + struct d3drm *d3drm = impl_from_IDirect3DRM2(iface); > + IDirect3DRMTexture3 *texture3; > HRESULT hr; > > - FIXME("iface %p, filename %s, texture %p stub!\n", iface, debugstr_a(filename), texture); > + TRACE("iface %p, filename %s, texture %p.\n", iface, debugstr_a(filename), texture); > > - if (FAILED(hr = d3drm_texture_create(&object))) > + if (FAILED(hr = IDirect3DRM3_LoadTexture(&d3drm->IDirect3DRM3_iface, filename, &texture3))) > return hr; > > - *texture = &object->IDirect3DRMTexture2_iface; > + hr = IDirect3DRMTexture3_QueryInterface(texture3, &IID_IDirect3DRMTexture2, (void**)texture); > + IDirect3DRMTexture3_Release(texture3); > + if (FAILED(hr)) > + return hr; > > return D3DRM_OK; > } This is probably ok, but you may want to consider just introducing a helper function instead. I.e.: if (FAILED(hr = d3drm_load_texture(d3drm, filename, TRUE, &object))) return hr; IDirect3DRMTexture2_AddRef(*texture = &object->IDirect3DRMTexture2_iface); return D3DRM_OK; What happens when d3drm_texture_load() is called multiple times on the same texture? Should that be possible? > +void d3drm_texture_destroy(struct d3drm_texture *texture); Missing DECLSPEC_HIDDEN. > +HRESULT d3drm_texture_load(struct d3drm_texture *texture, IDirect3DRM *d3drm, const char *path, BOOL load_upside_down) DECLSPEC_HIDDEN; This line is a bit long. Try to stick to 120 columns as a maximum, preferably a bit less. > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, BOOL palette, BOOL upside_down); Missing DECLSPEC_HIDDEN. > @@ -4103,24 +4105,34 @@ static void test_load_texture(void) > > hr = IDirect3DRM_LoadTexture(d3drm1, filename, &texture1); > ok(SUCCEEDED(hr), "Test %u: Failed to load texture, hr %#x.\n", i, hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %u, ref2 = %u.\n", ref1, ref2); The message should mention which test (i.e., "i") failed. > d3drm_img = IDirect3DRMTexture_GetImage(texture1); > - todo_wine ok(!!d3drm_img, "Test %u: Failed to get image.\n", i); > + ok(!!d3drm_img, "Test %u: Failed to get image.\n", i); > if (d3drm_img) > test_bitmap_data(i * 4, d3drm_img, FALSE, tests[i].w, tests[i].h, tests[i].palettized); Now that IDirect3DRMTexture_GetImage() succeeds, you can remove the "if (d3drm_img)". > +void d3drm_texture_destroy(struct d3drm_texture *texture) > +{ > + if (texture->image) > + { > + TRACE("Releasing attached members.\n"); > + HeapFree(GetProcessHeap(), 0, texture->image->buffer1); > + if(texture->image->palette) Missing space between "if" and "(". > + HeapFree(GetProcessHeap(), 0, texture->image->palette); > + HeapFree(GetProcessHeap(), 0, texture->image); This seems a bit suspicious. Supposedly the "image" argument to d3drm3_CreateTexture() can be used to create a texture on an existing image. The documentation isn't very explicit about it, but suggests that the image data isn't copied in that case. So I'm not sure the texture is supposed to be responsible for destroying the image. In general I think it's not entirely clear how things like CreateTexture(), LoadTexture() and InitFromFile() etc. are supposed to interact. > +HRESULT d3drm_texture_load(struct d3drm_texture *texture, IDirect3DRM *d3drm, const char *path, BOOL load_upside_down) > +{ > + BITMAPINFO *info; > + BITMAPFILEHEADER *bmp_header; > + unsigned char *buffer; > + DWORD size; > + HANDLE hfile, hmapping; > + > + hfile = CreateFileA(path, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); > + if (hfile == INVALID_HANDLE_VALUE) > + return D3DRMERR_BADFILE; > + > + size = GetFileSize(hfile, NULL); > + if (size == INVALID_FILE_SIZE) > + { > + DeleteObject(hfile); > + return D3DRMERR_BADVALUE; > + } You never use "size" after this, but you probably should. I also think you meant CloseHandle() instead of DeleteObject(). > + buffer = MapViewOfFile(hmapping, FILE_MAP_READ, 0, 0, 0); > + if (buffer == NULL) "if (!buffer)", or even "if (!(buffer = MapViewOfFile(...)))" > + bmp_header = (BITMAPFILEHEADER *)buffer; > + info = (BITMAPINFO *) (buffer + sizeof(*bmp_header)); Or just "info = (BITMAPINFO *)bmp_header + 1;". You should validate that this is actually a BMP file. You should also check which version of the BITMAPINFOHEADER structure the file has. > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, BOOL palette, BOOL upside_down) > +{ > + D3DRMPALETTEENTRY *colors = (D3DRMPALETTEENTRY *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 257 * sizeof(*colors)); Is "257" there intentional? The cast is unnecessary. HeapAlloc() can fail. Do you need HEAP_ZERO_MEMORY here? > + D3DRMIMAGE *image; > + BOOL black_used = FALSE; > + LONG w = info->bmiHeader.biWidth; > + LONG h = abs(info->bmiHeader.biHeight); > + int i, j, k; > + unsigned int idx, buffer1_idx; > + unsigned char *buffer1; > + int bpp = info->bmiHeader.biBitCount == 24 ? 32 : info->bmiHeader.biBitCount; > + int bpl = palette ? w : ((w + 3) & ~3) * bpp / 8; > + int num_colors = 0; > + struct colors_24bpp > + { > + BYTE red; > + BYTE green; > + BYTE blue; > + } *color; > + color = (struct colors_24bpp *)buffer; > + > + image = (D3DRMIMAGE *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*image)); > + image->buffer1 = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(unsigned char) * bpl * h); This is unsafe. Consider e.g. what happens when the header gives you 0x10000 for width and height. > + buffer1 = image->buffer1; > + memset(buffer1, 255, sizeof(unsigned char) * bpl * h); You just initialised the memory with HEAP_ZERO_MEMORY, and now you're overwriting it again. At least one of these two initialisations is unnecessary, and quite possibly both of them.

March 23, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Francois Gouget

On Wed, 23 Mar 2016, Francois Gouget wrote: [...] > * I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which > was not failing according to the test.winehq.org results. But all I > got is failures: > - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: > https://testbot.winehq.org/JobDetails.pl?Key=21611 > - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: > https://testbot.winehq.org/JobDetails.pl?Key=21610 > - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here > https://testbot.winehq.org/JobDetails.pl?Key=21609 > My MinGW compiler is more recent than the one WineHQ was using before > the upgrade however. So I think this points to a compiler-related > issue. Recompiling the crosstest with -O0 gets rid of the failures: - bd332f53 -O0 dinput8:dinput test https://testbot.winehq.org/JobDetails.pl?Key=21616 So it does look like a compiler issue. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

March 23, 2016

Re: [PATCH 2/5] d3d11/tests: Add test for ClearRenderTargetView().

by Marvin

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

March 23, 2016

Re: [PATCH 1/5] d3d10core/tests: Add test for ClearRenderTargetView().

by Marvin

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

March 23, 2016

Re: XInput and HID - architecture

by Aric Stewart

On 3/23/16 12:37 AM, Roderick Colenbrander wrote: > On Tue, Mar 22, 2016 at 12:18 PM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: >> On 03/22/2016 01:27 AM, Roderick Colenbrander wrote: >>> >>>>> As you have seen the xbox controller lacks proper HID descriptors and >>>>> on Windows the drivers fake descriptors to allow DirectInput to work >>>>> as well. We would be doing something not to different. For the >>>>> DirectInput I would report the real device name and the real ranges, >>>>> similar if games use raw input (not sure if there are games which do >>>>> this). >>>> On Wine, this would work the other way around. We would have raw (HID) >>>> devices as a base, and create DInput and XInput devices from those. >>> I understand that part. What I meant is that Windows reports 2 >>> different devices one with HID and one without. I was suggesting this >>> as a way to potentially handle non-native xinput devices, e.g. the >>> non-native device is made to appear like the xbox one on windows with >>> the missing descriptors etcetera. >> I'm not sure I understand what you mean. > The currently planned wine >> architecture uses the HID subsystem as a common base, allowing us to >> create a single minidriver per backend (evdev, hidraw, etc.), and then >> lets DInput and XInput access that. Are you suggesting putting all the >> XInput code (gamepad matching, control mapping) into the HID subsystem? > > I suggested maybe following the Windows 2 device approach for maybe > dealing with xinput for non-native devices (the mapping is pretty much > the same for steam / ds3 / ds4 / wii u gamepad, just slightly > different ranges and button names). For such devices it could make > sense to map them to a fixed mapping to simplify handling for xinput. > Also I'm not sure how important remapping is normally for users since > many games have configurable input. > >>> Though this still wouldn't handle >>> the enumeration situation for apps using wmi. >> Sorry, as you may have noticed, I'm not too savvy about Windows APIs. >> What is wmi? > > WMI is a subsystem let's say a bit comparable to /proc & /sys on Linux > providing all sorts of information about the system. Through WMI you > can provide information on e.g. CPU, USB devices, PCIe devices, > network information etcetera. As a developer you provide an SQL-like > query to request certain type of information. > > For xinput, Microsoft directly provided the xbox API without really > considering enumeration well (except for naive polling). One mechanism > Microsoft recommended as a bit of an oversight in my opinion was to > use WMI to enumerate input devices. > I will have to investigate this. I will add it to my list of surrounding pieces to try to make work. Right now setupapi enumeration works and all my current test applications use that. I have not run into an application trying to use WMI yet. Dinput enumeration also happens but that should be able to be made to work easily. > Also before I forget one other important thing for xinput are window > messages. I forgot the exact message name but something like > WM_DEVICECHANGED or something is important. Various applications > listen for the message to detect hotplugging of input devices and then > triggering a new device enumeration. For Linux this would require us > to tap into udev (SDL2 does this too, the code can give some > inspiration). Yes, WM_DEVICECHANGED and many of the device addition messages are missing. This is affecting any ability for the Plug and Play functionality to trick up to applications. It is on my list of things to work on along with IoRegisterPlugPlayNotifications and our plug and play facility comes into place. -aric > >> >> - Juan

March 23, 2016

Re: XInput and HID - architecture

by Aric Stewart

On 3/23/16 12:20 AM, Roderick Colenbrander wrote: > On Tue, Mar 22, 2016 at 5:35 AM, Aric Stewart <aric(a)codeweavers.com> wrote: >> On 3/21/16 7:27 PM, Roderick Colenbrander wrote: >>> On Sat, Mar 19, 2016 at 10:59 AM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: >>>> Hi, >>>> >>>> On 03/16/2016 02:45 AM, Roderick Colenbrander wrote: >>>>> Hi Juan, >>>>> >>>>> Let me reply to the start of the thread before diving into the >>>>> specifics on calibration. >>>>> >>>>> In my opinion, I'm not sure what the best way would be to handle >>>>> passing of HID data to xinput. The main thing to consider as part of >>>>> this is handling of non-native xinput devices (e.g. DS4 or >>>>> SteamController) provided we want to support this. Aside from passing >>>>> up the HID data the other challenge for xinput devices is the >>>>> enumeration part, which many (older) games do through a mixture of >>>>> WMI, dinput and xinput. For this to work we need to report an actual >>>>> xinput gamepad. >>>> Wine is supposed to mimic Windows' behavior as well as possible. Thus, >>>> the proper way to implement xinput would be to access the USB devices >>>> directly. The hid->xinput mapping is already non-compliant with the >>>> windows behavior, but currently necessary. However, in my opinion, we >>>> should only try to parse those HID descriptors that correspond to XInput >>>> devices, as provided by common XInput->HID drivers on different host >>>> OSs. Nevertheless, once wine's HID->Xinput backend is finished, the >>>> end-users can (locally) add their own mappings for any HID controller >>>> they want to use. I just wouldn't add those mappings to the wine repo. >>>> I would like to get some input on that, however. Do you think we should >>>> add mappings for non-xinput devices? >>>> >>>> Thank you for pointing out the enumeration process. The reason I >>>> implemented Xinput was to play a game that didn't support any other >>>> input method, so until now, I hadn't given it much thought. According to >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ee417014%28v=vs.85… >>>> , an XInput device shows up in DInput with an ID containing "IG_", which >>>> is what developers should use to filter them out. This might make things >>>> a bit difficult, since in Wine, both DInput and XInput devices are >>>> supposed to be created from a common HID base, so Wine's DInput cannot >>>> know anything about whether a device is an XInput device or not. >>>>> >>>>> My feeling would be for xinput to be quite stupid like it is on >>>>> Windows and feed it xbox controller compatible HID reports with the >>>>> same axes ranges, rumble ranges as the xbox controller. For more >>>>> custom devices you may want to support special handling e.g. button >>>>> emulation using touchpad on DS4 or maybe even on SteamController. >>>> The problem is that there is not a unique HID descriptor set for XInput. >>>> Each driver on each OS maps the xinput controls to a different layout, >>>> so we need some logic on the Wine XInput driver to tell those apart and >>>> map them back to XInput controls. >>> >>> Nonetheless a mapping is needed from evdev, optionally Linux hidraw >>> and whatever backend other OSes use. HID is nice in theory, but in >>> practice it is quite messy (many buggy devices, spec abuses, custom >>> HID requests to enable a device..). My feeling is to handle the >>> mapping to x360 at a level below xinput to avoid the mapping issues in >>> xinput. Depending on what other non-native xinput devices we may want >>> to handle (ds3, ds4, wii u controller, steam controller are all easy) >>> you may want more control at a lower level to handle custom >>> functionality, which could optionally need handling through many >>> different fields in the HID descriptor (e.g. touch). >>> >> >> The grand hope is that we can move all the platform specific code to HID and not have it reproduces in 3 different locations. We write dinput, winmm and Xinput to all be HID clients. >> >> You give a number of reasons that HID is messy, but I assume you are talking about windows native HID? Since right now we would be going through our own hid and hid minidrivers we are able to avoid a lot of that messiness. > > The main concern with HID is the way it is implemented by different > devices. Spec abuse, custom initialization logic for different devices > through device specific features requests, power management handling. > Among places I would recommend to have a look at the many HID drivers > in the Linux kernel patching up HID descriptors, doing custom device > initialization (power management, wireless pairing). > > My main worry is the amount of device specific code needed in Wine to > make HID useful for input and interpretation of HID data. For some of > the popular devices it will be like writing a custom driver. I > understand the desire for HID as maybe a way to avoid drivers e.g. on > OSX where there is a decent layer but many people don't install > gamepad drivers. > >> What are the specific areas that HID will be insufficient for xinput? Having specific examples will be helpful in figuring out a course of action. > > I see HID as a fine transport layer from xinput down to some lower > layer (I think for the xinput use case we need to standardize on a > certain layout). I'm worried about using it for the layers underneath > as I will explain below mostly because I expect we will need much > device specific code. Right now, and for the foreseeable future, we control all the code from hid.dll down to the platform. So that includes hid.dll, hidclass.sys, the minidrivers and the plug and play driver/implementation. So HID is being used as a transport layer from xinput(dinput, winmm) down to the lower layer. On Linux I have written both a evdev and hidraw connection, mostly because the hidraw one was very easy. Now that the evdev one is working pretty well if you feel the hidraw one would be nothing but heart ache then I can drop that. >>>>> As you have seen the xbox controller lacks proper HID descriptors and >>>>> on Windows the drivers fake descriptors to allow DirectInput to work >>>>> as well. We would be doing something not to different. For the >>>>> DirectInput I would report the real device name and the real ranges, >>>>> similar if games use raw input (not sure if there are games which do >>>>> this). >>>> On Wine, this would work the other way around. We would have raw (HID) >>>> devices as a base, and create DInput and XInput devices from those. >>> >>> I understand that part. What I meant is that Windows reports 2 >>> different devices one with HID and one without. I was suggesting this >>> as a way to potentially handle non-native xinput devices, e.g. the >>> non-native device is made to appear like the xbox one on windows with >>> the missing descriptors etcetera. Though this still wouldn't handle >>> the enumeration situation for apps using wmi. >> >> Can we just have the minidrivers for evdev / OSX / hidraw implement this? Do you have specs on what things they would need to report? What are the missing descriptors? > > Depending on the design we could have the minidriver layer handle > maybe mimicking the 2 devices and emulation for non-native devices. > > For the x360 controller as I mentioned in this email, the report > descriptors are missing and the device is not marked as a HID device > and hence in general is not available through raw hid libraries (!). > OS drivers can spoof the report descriptor and make the device be HID > (not done on Linux for x360, not sure about FreeBSD or OSX). Provided > an OS allows you to talk HID to it, Wine would have to spoof the > report descriptors and white list all the x360 controllers, last time > I checked the Linux xpad driver supported 100 devices for which we > would have to embed list the vendor/product ids. In general I expect > x360 access to require raw USB access e.g. through libusb. Also at > least on Linux raw USB access or raw HID access requires additional > permissions e.g. though udev rules, which can be considered a security > risk. My plan was to require support in the underlying OS. So yes, the x360 controller does not appear in hidraw, but it does appear in evdev so that is where we access it. Same on the mac, the user has to install a custom XBox controller driver for the xbox controller to appear to the IOHid layer. > After having dealt with input for quite a while, I'm not entirely sure > how I would design Wine's input layer. A 'fake' HID layer is > reasonable just as the layer just below xinput / dinput / winmm. For > the layer underneath I would just use evdev and the other APIs > supported on different OSes and probably skip HID, because I really > expect it will be like writing many custom device drivers for within > Wine. Though with the mini drivers doing a mapping back to HID is a > little tricky since you can't get the exact report and different > features need different device specific code paths (e.g. sysfs entries > to set player LED states). Even for mini drivers I expect device > specific code, which can't use sharing between different OSes. No > matter what path is taken I think it will become very messy and I > would urge to keep the mess to below dinput / xinput / winmm. > I think we are on the same page here actually. The HID layer is a layer below xinput / dinput / winmm but then connects to the platform via evdev, or IOHid on the mac. When I am talking about Minidrivers I am talking about the connection between win32 HID and the platform (evdev, etc...) -aric > Thanks, > Roderick > > >> thanks! >> -aric >> >>> >>>> >>>> - Juan >>>>> Thanks, >>>>> Roderick >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Mar 3, 2016 at 12:39 AM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I got a bit stuck and would like to hear your opinion on the XInput HID >>>>>> backend, specifically on the mappings, i.e. the code that "accepts" a >>>>>> certain device based on its properties and then maps its buttons and axes to >>>>>> XInput buttons and axes. >>>>>> >>>>>> As long as the mappings are fixed, i.e. are not supposed to be extended or >>>>>> edited by the user, everything can be compiled into xinput1_3.dll. However, >>>>>> I would like to provide a "xinput.cpl" control panel node for xinput similar >>>>>> to "joy.cpl", where the user can not only test the XInput gamepads, but also >>>>>> manage the XInput-HID backend mappings. The first part can be accomplished >>>>>> by using xinput1_3.dll. However, in order to load and persist different >>>>>> mappings, the second part requires access to the functions that serialize >>>>>> and deserialize the mappings. It also needs some way of getting raw >>>>>> capabilities and changes in HID devices in order to be able to create new >>>>>> mappings. >>>>>> >>>>>> Here are some possible ways of solving it: >>>>>> >>>>>> Extend xinput1_3.dll with the required management functions and add a >>>>>> "wine/xinput_hid_mgmt.h" or similar header that declares those methods. >>>>>> xinput.cpl could then simply use xinput1_3.dll to perform all management >>>>>> functions. I'm not sure if this would break anything due to the additional >>>>>> exports in the dll. >>>>>> Extract the mapping load and store logic into a separate "xinputhid.dll" or >>>>>> similar. I this case both xinput1_3.dll and xinput.cpl would access this >>>>>> library to load and store mappings. >>>>>> Move the xinput core and backends into a driver and let xinput1_3.dll access >>>>>> it via IOCTLs. I believe this is the way it works on windows, although there >>>>>> doesn't seem to be any freely available documentation regarding the internal >>>>>> architecture. The XInput-HID backend could then create its own kernel object >>>>>> as a management interface, which could be accessed by xinput.cpl. This would >>>>>> have the added effect of having a single instance managing the xinput >>>>>> devices if several programs are running at the same time, which mimics the >>>>>> behavior of windows. >>>>>> >>>>>> What do you think would be the best option? Is there another way I haven't >>>>>> mentioned? >>>>>> >>>>>> - Juan >>>>>> >>>>>> >>>>>> >>>>>> >>>>

March 23, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Michael Stefaniuc

On 03/23/2016 12:17 PM, Francois Gouget wrote: > > This is a truly weird one. dinput8:dinput start failing on the 17th, the > day after WineHQ was upgraded: > https://test.winehq.org/data/tests/dinput8:dinput.html > > What makes this weird is that: > * There has been no change to these tests between bd332f53f2d7 and > 966a07149a02. In fact the last patch goes back to 2013. > So it's not a bad patch. > > * The failures happen on every 32 bit test environment, from XP to > Windows 10, VM or not, TestBot or not. Only 64 bit is spared. > > * I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which > was not failing according to the test.winehq.org results. But all I > got is failures: > - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: > https://testbot.winehq.org/JobDetails.pl?Key=21611 > - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: > https://testbot.winehq.org/JobDetails.pl?Key=21610 > - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here > https://testbot.winehq.org/JobDetails.pl?Key=21609 > My MinGW compiler is more recent than the one WineHQ was using before > the upgrade however. So I think this points to a compiler-related > issue. > > The official WineTest binaries are build on WineHQ so I suspect the > MinGW upgrade is somehow responsible for the new failures. Well, it wasn't just a version upgrade but a change from mingw to the mingw-w64 fork. Afaik those two diverged quite a bit. bye michael

March 23, 2016

Re: [PATCH] riched20: Implement ITextRange::ScrollIntoView.

by Huw Davies

On Tue, Mar 22, 2016 at 03:29:10PM -0700, Adam Buchbinder wrote: > On Tue, Mar 22, 2016 at 2:09 AM, Huw Davies <huw(a)codeweavers.com> wrote: > On Fri, Mar 18, 2016 at 11:59:52AM -0700, Adam Buchbinder wrote: > > diff --git a/dlls/riched20/tests/richole.c b/dlls/riched20/tests/ > richole.c > > index 7c6c5d5..de3c7a0 100644 > > --- a/dlls/riched20/tests/richole.c > > +++ b/dlls/riched20/tests/richole.c > > @@ -53,6 +53,7 @@ static HWND new_window(LPCSTR lpClassName, DWORD > dwStyle, HWND parent) > > HWND hwnd = CreateWindowA(lpClassName, NULL, > > dwStyle | WS_POPUP | WS_HSCROLL | > WS_VSCROLL | WS_VISIBLE, > > 0, 0, 200, 60, parent, NULL, > hmoduleRichEdit, NULL); > > + ok(hwnd != NULL, "class: %s, error: %d\n", > lpClassName, (int) GetLastError()); > > return hwnd; > > } > > > > @@ -761,6 +762,66 @@ static void test_ITextRange_GetChar(void) > > ITextRange_Release(txtRge); > > } > > > > +/* Helper function for testing ITextRange_ScrollIntoView */ > > +static void check_range(HWND w, ITextDocument* doc, int first, int > lim, > > + LONG bStart, int expected_nonzero) { > > Please put the opening brace on a new line. > > Will do, but I'm a bit confused about this: > > More importantly, I get a test failure: > richole.c:785: Test failed: Moved scrollbar is at 60, should be 0. > (Range 0-160.) > > Where? The TestBot completed okay in a variety of environments: > > https://testbot.winehq.org/JobDetails.pl?Key=21524 > > and it works on my local workstation. The trace points to a helper function, > which is being called with expected_nonzero = 0. There are four calls in > test_ITextRange_ScrollIntoView which could be behind this; without logging > information or a stack trace, I can't tell what's breaking. It's failing for me on both OS/X and linux. Note, it's the implementation that's failing, the tests themselves are fine. Did you try running 'make test' on your local machine? Huw.

March 23, 2016

WineHQ upgrade breaking dinput8:dinput?

by Francois Gouget

This is a truly weird one. dinput8:dinput start failing on the 17th, the day after WineHQ was upgraded: https://test.winehq.org/data/tests/dinput8:dinput.html What makes this weird is that: * There has been no change to these tests between bd332f53f2d7 and 966a07149a02. In fact the last patch goes back to 2013. So it's not a bad patch. * The failures happen on every 32 bit test environment, from XP to Windows 10, VM or not, TestBot or not. Only 64 bit is spared. * I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which was not failing according to the test.winehq.org results. But all I got is failures: - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21611 - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21610 - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here https://testbot.winehq.org/JobDetails.pl?Key=21609 My MinGW compiler is more recent than the one WineHQ was using before the upgrade however. So I think this points to a compiler-related issue. The official WineTest binaries are build on WineHQ so I suspect the MinGW upgrade is somehow responsible for the new failures. However I don't know if the old compiler was masking them, of if the new one is causing them. Any ideas? For reference: * Debian Testing (my environment): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 * Debian 7 (close to former WineHQ environment): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.9.1 -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

March 23, 2016

Re: [PATCH 4/4] xmllite/writer: Fix WriteEndElement()/WriteFullEndElement() on ready state

by Marvin

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

March 23, 2016

Re: [PATCH 3/4] xmllite/writer: Properly fail on initial state in WriteEndElement()

by Marvin

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

March 23, 2016

Re: [PATCH 2/4] xmllite/writer: Fix initial state handling in WriteEndDocument()

by Marvin

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

March 23, 2016

Re: [PATCH 1/4] xmllite/tests: A test for Write* behaviour on initial writer state

by Marvin

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

March 23, 2016

Re: [v2] bcrypt: Added BCryptHash function.

by Hans Leidekker

On Tue, 2016-03-22 at 07:50 -0700, Patrick Armstrong wrote: > +NTSTATUS WINAPI BCryptHash( BCRYPT_ALG_HANDLE algorithm, UCHAR *secret, ULONG secretlen, > + UCHAR *input, ULONG inputlen, UCHAR *output, ULONG outputlen ) > +{ > + NTSTATUS status; > + BCRYPT_HASH_HANDLE handle; > + > + TRACE( "%p, %p, %u, %p, %u, %p, %u\n", algorithm, secret, secretlen, > + input, inputlen, output, outputlen ); > + > + status = BCryptCreateHash( algorithm, &handle, NULL, 0, secret, secretlen, 0); > + if (status != STATUS_SUCCESS) > + { > + BCryptDestroyHash( handle ); > + return status; > + } BCryptCreateHash doesn't return a handle when it fails. > NTSTATUS WINAPI BCryptCloseAlgorithmProvider(BCRYPT_ALG_HANDLE, ULONG); > NTSTATUS WINAPI BCryptCreateHash(BCRYPT_ALG_HANDLE, BCRYPT_HASH_HANDLE *, PUCHAR, ULONG, PUCHAR, ULONG, ULONG); > NTSTATUS WINAPI BCryptDestroyHash(BCRYPT_HASH_HANDLE); > +NTSTATUS WINAPI BCryptHash(BCRYPT_ALG_HANDLE, PUCHAR, ULONG, PUCHAR, ULONG, PUCHAR, ULONG); > NTSTATUS WINAPI BCryptEnumAlgorithms(ULONG, ULONG *, BCRYPT_ALGORITHM_IDENTIFIER **, ULONG); > NTSTATUS WINAPI BCryptFinishHash(BCRYPT_HASH_HANDLE, PUCHAR, ULONG, ULONG); > NTSTATUS WINAPI BCryptGenRandom(BCRYPT_ALG_HANDLE, PUCHAR, ULONG, ULONG); While you're at it, please keep these sorted.

March 23, 2016

Re: [v5 2/8] d3dx9: Introduce preshaders in effect.

by Paul Gofman

On 03/23/2016 01:24 AM, Paul Gofman wrote: > On 03/23/2016 01:05 AM, Matteo Bruni wrote: >> 2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: >>> Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> >>> @@ -5435,9 +5416,30 @@ static HRESULT d3dx9_parse_array_selector(struct d3dx9_base_effect *base, struct >>> } >>> TRACE("Unknown DWORD: 0x%.8x.\n", *(DWORD *)(ptr + string_size)); >>> >>> - FIXME("Parse preshader.\n"); >>> + d3dx_create_param_eval(base, (DWORD *)(ptr + string_size) + 1, object->size - (string_size + 1), >>> + D3DXPT_INT, &param->param_eval); >> Does this do the right thing if ptr + string_size is aligned to a >> DWORD? In other words, does the bytecode contain 4 bytes of padding if >> string_size % 4 == 0? >> > Oh, I will check that, thanks. I've checked that, actually string_size is already always 4 bytes aligned, otherwise this code would not work at all as it does not align ptr + string_size. When I was writing this I actually trusted an estimation of next DWORD location in a pre-existing TRACE above. I will add a FIXME on misaligned string_size. The same d3dx_param_eval call has though an error in bytecode size estimation, I will fix it.

March 23, 2016

Re: mshtml: Fixed remaining xmlhttprequest test failures.

by Marvin

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

March 23, 2016

Re: [tools 2/2] Support for disabling and enabling warnings, handle warning number 2368

by Sergei Bolotov

23.03.2016, 07:25, "Nikolay Sivov" <bunglehead(a)gmail.com>: > On 23.03.2016 1:16, Sergei Bolotov wrote: >> 22.03.2016, 22:39, "Nikolay Sivov" <bunglehead(a)gmail.com>: >>> Duplicate UUID is not a warning 2368, it's an error 2270. >>> Could you share a minimal idl you're using to test that? >> >> Calling midl on dlls/oleaut32/tests/test_tlb.idl produces this output: >> "midl\oleaut32.dll : warning MIDL2368 : error generating type library, >> ignored : Could not set UUID : nn (0x800288C6)". Adding >> "midl_pragma warning(disable: 2368)" in file suppress such output. > > Why do we care about midl output? And even if there is a reason to, > parser support to ignore pragma is enough, so you don't need to actually > support warnings in widl. Is pedantic mode ever enabled explicitly when > building wine? As Alexandre mentioned in here: https://www.winehq.org/pipermail/wine-devel/2015-November/110224.html the correct way to suppress such warnings would be to implement support for midl_pragma warning(disable). -- Regards, Bolotov Sergei

March 23, 2016

Re: XInput and HID - architecture

by Roderick Colenbrander

On Tue, Mar 22, 2016 at 12:18 PM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: > On 03/22/2016 01:27 AM, Roderick Colenbrander wrote: >> >>>> As you have seen the xbox controller lacks proper HID descriptors and >>>> on Windows the drivers fake descriptors to allow DirectInput to work >>>> as well. We would be doing something not to different. For the >>>> DirectInput I would report the real device name and the real ranges, >>>> similar if games use raw input (not sure if there are games which do >>>> this). >>> On Wine, this would work the other way around. We would have raw (HID) >>> devices as a base, and create DInput and XInput devices from those. >> I understand that part. What I meant is that Windows reports 2 >> different devices one with HID and one without. I was suggesting this >> as a way to potentially handle non-native xinput devices, e.g. the >> non-native device is made to appear like the xbox one on windows with >> the missing descriptors etcetera. > I'm not sure I understand what you mean. The currently planned wine > architecture uses the HID subsystem as a common base, allowing us to > create a single minidriver per backend (evdev, hidraw, etc.), and then > lets DInput and XInput access that. Are you suggesting putting all the > XInput code (gamepad matching, control mapping) into the HID subsystem? I suggested maybe following the Windows 2 device approach for maybe dealing with xinput for non-native devices (the mapping is pretty much the same for steam / ds3 / ds4 / wii u gamepad, just slightly different ranges and button names). For such devices it could make sense to map them to a fixed mapping to simplify handling for xinput. Also I'm not sure how important remapping is normally for users since many games have configurable input. >> Though this still wouldn't handle >> the enumeration situation for apps using wmi. > Sorry, as you may have noticed, I'm not too savvy about Windows APIs. > What is wmi? WMI is a subsystem let's say a bit comparable to /proc & /sys on Linux providing all sorts of information about the system. Through WMI you can provide information on e.g. CPU, USB devices, PCIe devices, network information etcetera. As a developer you provide an SQL-like query to request certain type of information. For xinput, Microsoft directly provided the xbox API without really considering enumeration well (except for naive polling). One mechanism Microsoft recommended as a bit of an oversight in my opinion was to use WMI to enumerate input devices. Also before I forget one other important thing for xinput are window messages. I forgot the exact message name but something like WM_DEVICECHANGED or something is important. Various applications listen for the message to detect hotplugging of input devices and then triggering a new device enumeration. For Linux this would require us to tap into udev (SDL2 does this too, the code can give some inspiration). > > - Juan

March 23, 2016

Re: XInput and HID - architecture

by Roderick Colenbrander

On Tue, Mar 22, 2016 at 5:35 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > On 3/21/16 7:27 PM, Roderick Colenbrander wrote: >> On Sat, Mar 19, 2016 at 10:59 AM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: >>> Hi, >>> >>> On 03/16/2016 02:45 AM, Roderick Colenbrander wrote: >>>> Hi Juan, >>>> >>>> Let me reply to the start of the thread before diving into the >>>> specifics on calibration. >>>> >>>> In my opinion, I'm not sure what the best way would be to handle >>>> passing of HID data to xinput. The main thing to consider as part of >>>> this is handling of non-native xinput devices (e.g. DS4 or >>>> SteamController) provided we want to support this. Aside from passing >>>> up the HID data the other challenge for xinput devices is the >>>> enumeration part, which many (older) games do through a mixture of >>>> WMI, dinput and xinput. For this to work we need to report an actual >>>> xinput gamepad. >>> Wine is supposed to mimic Windows' behavior as well as possible. Thus, >>> the proper way to implement xinput would be to access the USB devices >>> directly. The hid->xinput mapping is already non-compliant with the >>> windows behavior, but currently necessary. However, in my opinion, we >>> should only try to parse those HID descriptors that correspond to XInput >>> devices, as provided by common XInput->HID drivers on different host >>> OSs. Nevertheless, once wine's HID->Xinput backend is finished, the >>> end-users can (locally) add their own mappings for any HID controller >>> they want to use. I just wouldn't add those mappings to the wine repo. >>> I would like to get some input on that, however. Do you think we should >>> add mappings for non-xinput devices? >>> >>> Thank you for pointing out the enumeration process. The reason I >>> implemented Xinput was to play a game that didn't support any other >>> input method, so until now, I hadn't given it much thought. According to >>> https://msdn.microsoft.com/en-us/library/windows/desktop/ee417014%28v=vs.85… >>> , an XInput device shows up in DInput with an ID containing "IG_", which >>> is what developers should use to filter them out. This might make things >>> a bit difficult, since in Wine, both DInput and XInput devices are >>> supposed to be created from a common HID base, so Wine's DInput cannot >>> know anything about whether a device is an XInput device or not. >>>> >>>> My feeling would be for xinput to be quite stupid like it is on >>>> Windows and feed it xbox controller compatible HID reports with the >>>> same axes ranges, rumble ranges as the xbox controller. For more >>>> custom devices you may want to support special handling e.g. button >>>> emulation using touchpad on DS4 or maybe even on SteamController. >>> The problem is that there is not a unique HID descriptor set for XInput. >>> Each driver on each OS maps the xinput controls to a different layout, >>> so we need some logic on the Wine XInput driver to tell those apart and >>> map them back to XInput controls. >> >> Nonetheless a mapping is needed from evdev, optionally Linux hidraw >> and whatever backend other OSes use. HID is nice in theory, but in >> practice it is quite messy (many buggy devices, spec abuses, custom >> HID requests to enable a device..). My feeling is to handle the >> mapping to x360 at a level below xinput to avoid the mapping issues in >> xinput. Depending on what other non-native xinput devices we may want >> to handle (ds3, ds4, wii u controller, steam controller are all easy) >> you may want more control at a lower level to handle custom >> functionality, which could optionally need handling through many >> different fields in the HID descriptor (e.g. touch). >> > > The grand hope is that we can move all the platform specific code to HID and not have it reproduces in 3 different locations. We write dinput, winmm and Xinput to all be HID clients. > > You give a number of reasons that HID is messy, but I assume you are talking about windows native HID? Since right now we would be going through our own hid and hid minidrivers we are able to avoid a lot of that messiness. The main concern with HID is the way it is implemented by different devices. Spec abuse, custom initialization logic for different devices through device specific features requests, power management handling. Among places I would recommend to have a look at the many HID drivers in the Linux kernel patching up HID descriptors, doing custom device initialization (power management, wireless pairing). My main worry is the amount of device specific code needed in Wine to make HID useful for input and interpretation of HID data. For some of the popular devices it will be like writing a custom driver. I understand the desire for HID as maybe a way to avoid drivers e.g. on OSX where there is a decent layer but many people don't install gamepad drivers. > What are the specific areas that HID will be insufficient for xinput? Having specific examples will be helpful in figuring out a course of action. I see HID as a fine transport layer from xinput down to some lower layer (I think for the xinput use case we need to standardize on a certain layout). I'm worried about using it for the layers underneath as I will explain below mostly because I expect we will need much device specific code. > > >>>> >>>> As you have seen the xbox controller lacks proper HID descriptors and >>>> on Windows the drivers fake descriptors to allow DirectInput to work >>>> as well. We would be doing something not to different. For the >>>> DirectInput I would report the real device name and the real ranges, >>>> similar if games use raw input (not sure if there are games which do >>>> this). >>> On Wine, this would work the other way around. We would have raw (HID) >>> devices as a base, and create DInput and XInput devices from those. >> >> I understand that part. What I meant is that Windows reports 2 >> different devices one with HID and one without. I was suggesting this >> as a way to potentially handle non-native xinput devices, e.g. the >> non-native device is made to appear like the xbox one on windows with >> the missing descriptors etcetera. Though this still wouldn't handle >> the enumeration situation for apps using wmi. > > Can we just have the minidrivers for evdev / OSX / hidraw implement this? Do you have specs on what things they would need to report? What are the missing descriptors? Depending on the design we could have the minidriver layer handle maybe mimicking the 2 devices and emulation for non-native devices. For the x360 controller as I mentioned in this email, the report descriptors are missing and the device is not marked as a HID device and hence in general is not available through raw hid libraries (!). OS drivers can spoof the report descriptor and make the device be HID (not done on Linux for x360, not sure about FreeBSD or OSX). Provided an OS allows you to talk HID to it, Wine would have to spoof the report descriptors and white list all the x360 controllers, last time I checked the Linux xpad driver supported 100 devices for which we would have to embed list the vendor/product ids. In general I expect x360 access to require raw USB access e.g. through libusb. Also at least on Linux raw USB access or raw HID access requires additional permissions e.g. though udev rules, which can be considered a security risk. After having dealt with input for quite a while, I'm not entirely sure how I would design Wine's input layer. A 'fake' HID layer is reasonable just as the layer just below xinput / dinput / winmm. For the layer underneath I would just use evdev and the other APIs supported on different OSes and probably skip HID, because I really expect it will be like writing many custom device drivers for within Wine. Though with the mini drivers doing a mapping back to HID is a little tricky since you can't get the exact report and different features need different device specific code paths (e.g. sysfs entries to set player LED states). Even for mini drivers I expect device specific code, which can't use sharing between different OSes. No matter what path is taken I think it will become very messy and I would urge to keep the mess to below dinput / xinput / winmm. Thanks, Roderick > thanks! > -aric > >> >>> >>> - Juan >>>> Thanks, >>>> Roderick >>>> >>>> >>>> >>>> >>>> On Thu, Mar 3, 2016 at 12:39 AM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: >>>>> Hi, >>>>> >>>>> I got a bit stuck and would like to hear your opinion on the XInput HID >>>>> backend, specifically on the mappings, i.e. the code that "accepts" a >>>>> certain device based on its properties and then maps its buttons and axes to >>>>> XInput buttons and axes. >>>>> >>>>> As long as the mappings are fixed, i.e. are not supposed to be extended or >>>>> edited by the user, everything can be compiled into xinput1_3.dll. However, >>>>> I would like to provide a "xinput.cpl" control panel node for xinput similar >>>>> to "joy.cpl", where the user can not only test the XInput gamepads, but also >>>>> manage the XInput-HID backend mappings. The first part can be accomplished >>>>> by using xinput1_3.dll. However, in order to load and persist different >>>>> mappings, the second part requires access to the functions that serialize >>>>> and deserialize the mappings. It also needs some way of getting raw >>>>> capabilities and changes in HID devices in order to be able to create new >>>>> mappings. >>>>> >>>>> Here are some possible ways of solving it: >>>>> >>>>> Extend xinput1_3.dll with the required management functions and add a >>>>> "wine/xinput_hid_mgmt.h" or similar header that declares those methods. >>>>> xinput.cpl could then simply use xinput1_3.dll to perform all management >>>>> functions. I'm not sure if this would break anything due to the additional >>>>> exports in the dll. >>>>> Extract the mapping load and store logic into a separate "xinputhid.dll" or >>>>> similar. I this case both xinput1_3.dll and xinput.cpl would access this >>>>> library to load and store mappings. >>>>> Move the xinput core and backends into a driver and let xinput1_3.dll access >>>>> it via IOCTLs. I believe this is the way it works on windows, although there >>>>> doesn't seem to be any freely available documentation regarding the internal >>>>> architecture. The XInput-HID backend could then create its own kernel object >>>>> as a management interface, which could be accessed by xinput.cpl. This would >>>>> have the added effect of having a single instance managing the xinput >>>>> devices if several programs are running at the same time, which mimics the >>>>> behavior of windows. >>>>> >>>>> What do you think would be the best option? Is there another way I haven't >>>>> mentioned? >>>>> >>>>> - Juan >>>>> >>>>> >>>>> >>>>> >>>

March 23, 2016

Re: [tools 2/2] Support for disabling and enabling warnings, handle warning number 2368

by Nikolay Sivov

On 23.03.2016 1:16, Sergei Bolotov wrote: > 22.03.2016, 22:39, "Nikolay Sivov" <bunglehead(a)gmail.com>: >> Duplicate UUID is not a warning 2368, it's an error 2270. >> Could you share a minimal idl you're using to test that? > > Calling midl on dlls/oleaut32/tests/test_tlb.idl produces this output: > "midl\oleaut32.dll : warning MIDL2368 : error generating type library, > ignored : Could not set UUID : nn (0x800288C6)". Adding > "midl_pragma warning(disable: 2368)" in file suppress such output. > > Why do we care about midl output? And even if there is a reason to, parser support to ignore pragma is enough, so you don't need to actually support warnings in widl. Is pedantic mode ever enabled explicitly when building wine? > -- > Regards, > Bolotov Sergei >

March 23, 2016

Re: [v5 8/8] d3dx9: Implement setting named shader constants in effect.

by Matteo Bruni

2016-03-22 23:48 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > On 03/23/2016 01:09 AM, Matteo Bruni wrote: >> >>> diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c >>> index fec9de4..1770046 100644 >>> --- a/dlls/d3dx9_36/preshader.c >>> +++ b/dlls/d3dx9_36/preshader.c >>> @@ -242,7 +242,7 @@ static void regstore_set_values(struct d3dx_regstore *rs, unsigned int table, vo >>> static unsigned int regstore_is_val_set_reg(struct d3dx_regstore *rs, unsigned int table, unsigned int reg_idx) >>> { >>> return rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] & >>> - (1ul << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); >>> + (1u << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); >> When you end up changing stuff introduced in a previous patch in the >> series you know there is something wrong ;) >> I guess it's a rebase glitch (by any chance, was this a remnant of a >> try with the uint_ptr idea you mentioned earlier?) >> > Yes, I put uint_ptr in, then realized that it would require an extra > include to the common header file, or using ULONG_PTR instead (for which > I was not sure if it is decent enough :), so I gave up as the difference > introduced by this looked not important really. So I got back in patch > stack and changed 1ul's, which were introduced in two different patches, > and took a wrong (later) patch for the second change. So I saw 1u in the > final file and I did not notice this mess in between, sorry. No problem at all :)

March 22, 2016

Re: [v5 8/8] d3dx9: Implement setting named shader constants in effect.

by Paul Gofman

On 03/23/2016 01:09 AM, Matteo Bruni wrote: > >> diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c >> index fec9de4..1770046 100644 >> --- a/dlls/d3dx9_36/preshader.c >> +++ b/dlls/d3dx9_36/preshader.c >> @@ -242,7 +242,7 @@ static void regstore_set_values(struct d3dx_regstore *rs, unsigned int table, vo >> static unsigned int regstore_is_val_set_reg(struct d3dx_regstore *rs, unsigned int table, unsigned int reg_idx) >> { >> return rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] & >> - (1ul << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); >> + (1u << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); > When you end up changing stuff introduced in a previous patch in the > series you know there is something wrong ;) > I guess it's a rebase glitch (by any chance, was this a remnant of a > try with the uint_ptr idea you mentioned earlier?) > Yes, I put uint_ptr in, then realized that it would require an extra include to the common header file, or using ULONG_PTR instead (for which I was not sure if it is decent enough :), so I gave up as the difference introduced by this looked not important really. So I got back in patch stack and changed 1ul's, which were introduced in two different patches, and took a wrong (later) patch for the second change. So I saw 1u in the final file and I did not notice this mess in between, sorry.

March 22, 2016

Re: [v5 1/8] d3dx9: Add test for preshader in effect.

by Matteo Bruni

2016-03-22 23:22 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > On 03/23/2016 01:05 AM, Matteo Bruni wrote: >> 2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: >> >>> +struct test_struct >>> +{ >>> + float3 v1; >>> + float fv; >>> + float4 v2; >>> +}; >>> + >>> +test_struct ts1[1] = {{{9, 10, 11}, 12, {13, 14, 15, 16}}}; >>> +test_struct ts2[2] = {{{0, 0, 0}, 0, {0, 0, 0, 0}}, {{1, 2, 3}, 4, {5, 6, 7, 8}}}; >> Is it also possible to create a struct with an array field? And an >> array of those structs? > Since you signed this off already, I suggest I do it together with a > couple of additions to this test effect I wanted to do for > IsParameterUsed test I am preparing. Sure. It can even be two separate patches.

March 22, 2016

Re: [PATCH] riched20: Implement ITextRange::ScrollIntoView.

by Adam Buchbinder

On Tue, Mar 22, 2016 at 2:09 AM, Huw Davies <huw(a)codeweavers.com> wrote: > On Fri, Mar 18, 2016 at 11:59:52AM -0700, Adam Buchbinder wrote: > > diff --git a/dlls/riched20/tests/richole.c > b/dlls/riched20/tests/richole.c > > index 7c6c5d5..de3c7a0 100644 > > --- a/dlls/riched20/tests/richole.c > > +++ b/dlls/riched20/tests/richole.c > > @@ -53,6 +53,7 @@ static HWND new_window(LPCSTR lpClassName, DWORD > dwStyle, HWND parent) > > HWND hwnd = CreateWindowA(lpClassName, NULL, > > dwStyle | WS_POPUP | WS_HSCROLL | > WS_VSCROLL | WS_VISIBLE, > > 0, 0, 200, 60, parent, NULL, > hmoduleRichEdit, NULL); > > + ok(hwnd != NULL, "class: %s, error: %d\n", lpClassName, (int) > GetLastError()); > > return hwnd; > > } > > > > @@ -761,6 +762,66 @@ static void test_ITextRange_GetChar(void) > > ITextRange_Release(txtRge); > > } > > > > +/* Helper function for testing ITextRange_ScrollIntoView */ > > +static void check_range(HWND w, ITextDocument* doc, int first, int lim, > > + LONG bStart, int expected_nonzero) { > > Please put the opening brace on a new line. > > Will do, but I'm a bit confused about this: > More importantly, I get a test failure: > richole.c:785: Test failed: Moved scrollbar is at 60, should be 0. (Range > 0-160.) > Where? The TestBot completed okay in a variety of environments: https://testbot.winehq.org/JobDetails.pl?Key=21524 and it works on my local workstation. The trace points to a helper function, which is being called with expected_nonzero = 0. There are four calls in test_ITextRange_ScrollIntoView which could be behind this; without logging information or a stack trace, I can't tell what's breaking. How were you able to get the test to fail? I'd like to try and reproduce the issue myself. Thanks for the feedback, and sorry about the hassle--if there's some kind of local testing I should have done before sending it off, please let me know. Adam Buchbinder

March 22, 2016

Re: [v5 2/8] d3dx9: Introduce preshaders in effect.

by Paul Gofman

On 03/23/2016 01:05 AM, Matteo Bruni wrote: > 2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: >> Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> >> @@ -5435,9 +5416,30 @@ static HRESULT d3dx9_parse_array_selector(struct d3dx9_base_effect *base, struct >> } >> TRACE("Unknown DWORD: 0x%.8x.\n", *(DWORD *)(ptr + string_size)); >> >> - FIXME("Parse preshader.\n"); >> + d3dx_create_param_eval(base, (DWORD *)(ptr + string_size) + 1, object->size - (string_size + 1), >> + D3DXPT_INT, &param->param_eval); > Does this do the right thing if ptr + string_size is aligned to a > DWORD? In other words, does the bytecode contain 4 bytes of padding if > string_size % 4 == 0? > Oh, I will check that, thanks.

March 22, 2016

Re: [v5 1/8] d3dx9: Add test for preshader in effect.

by Paul Gofman

On 03/23/2016 01:05 AM, Matteo Bruni wrote: > 2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > >> +struct test_struct >> +{ >> + float3 v1; >> + float fv; >> + float4 v2; >> +}; >> + >> +test_struct ts1[1] = {{{9, 10, 11}, 12, {13, 14, 15, 16}}}; >> +test_struct ts2[2] = {{{0, 0, 0}, 0, {0, 0, 0, 0}}, {{1, 2, 3}, 4, {5, 6, 7, 8}}}; > Is it also possible to create a struct with an array field? And an > array of those structs? Since you signed this off already, I suggest I do it together with a couple of additions to this test effect I wanted to do for IsParameterUsed test I am preparing.

March 22, 2016

Re: [tools 2/2] Support for disabling and enabling warnings, handle warning number 2368

by Sergei Bolotov

22.03.2016, 22:39, "Nikolay Sivov" <bunglehead(a)gmail.com>: > Duplicate UUID is not a warning 2368, it's an error 2270. > Could you share a minimal idl you're using to test that? Calling midl on dlls/oleaut32/tests/test_tlb.idl produces this output: "midl\oleaut32.dll : warning MIDL2368 : error generating type library, ignored : Could not set UUID : nn (0x800288C6)". Adding "midl_pragma warning(disable: 2368)" in file suppress such output. -- Regards, Bolotov Sergei

March 22, 2016

Re: [v5 8/8] d3dx9: Implement setting named shader constants in effect.

by Matteo Bruni

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > +HRESULT d3dx_set_shader_const_fxlc(struct ID3DXEffectImpl *effect, struct d3dx_pass *pass, > + struct d3dx_parameter *param, unsigned int vs) Using a BOOL for the vs flag seems nicer. > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index fec9de4..1770046 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -242,7 +242,7 @@ static void regstore_set_values(struct d3dx_regstore *rs, unsigned int table, vo > static unsigned int regstore_is_val_set_reg(struct d3dx_regstore *rs, unsigned int table, unsigned int reg_idx) > { > return rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] & > - (1ul << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); > + (1u << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); When you end up changing stuff introduced in a previous patch in the series you know there is something wrong ;) I guess it's a rebase glitch (by any chance, was this a remnant of a try with the uint_ptr idea you mentioned earlier?) > +HRESULT d3dx_param_eval_set_shader_constants(struct IDirect3DDevice9 *device, struct d3dx_param_eval *peval) > +{ > + HRESULT hr, res; > + struct d3dx_preshader *pres = &peval->pres; > + struct d3dx_regstore *rs = &pres->regs; > + > + TRACE("device %p, peval %p, param_type %u.\n", device, peval, peval->param_type); > + > + if (FAILED(hr = set_constants(rs, &pres->inputs))) > + return hr; > + if (FAILED(hr = execute_preshader(pres))) > + return hr; > + if (FAILED(hr = set_constants(rs, &peval->shader_inputs))) > + return hr; > + > + #define SET_TABLE(table, func_suff, type) \ > + { \ > + unsigned int is, n; \ > + \ > + is = 0; \ > + while (is < rs->table_sizes[table]) \ > + {\ > + n = 0; \ > + while (is < rs->table_sizes[table] && !regstore_is_val_set_reg(rs, table, is)) \ > + is++; \ > + while (is + n < rs->table_sizes[table] && regstore_is_val_set_reg(rs, table, is + n)) \ > + n++; \ > + if (!n) \ > + continue; \ > + TRACE("setting %u consts at %u.\n", n, is); \ > + hr = IDirect3DDevice9_##func_suff(device, is, \ > + (const type *)rs->tables[table] + is * table_info[table].reg_component_count, n); \ > + if (FAILED(hr)) \ > + { \ > + ERR(#func_suff " failed, hr %#x.\n", hr); \ > + res = hr; \ > + } \ > + is += n; \ > + } \ > + regstore_reset_table(rs, table); \ > + } > + res = D3D_OK; > + if (peval->param_type == D3DXPT_VERTEXSHADER) > + { > + SET_TABLE(PRES_REGTAB_OCONST, SetVertexShaderConstantF, float); > + SET_TABLE(PRES_REGTAB_OICONST, SetVertexShaderConstantI, int); > + SET_TABLE(PRES_REGTAB_OBCONST, SetVertexShaderConstantB, BOOL); > + } > + else if (peval->param_type == D3DXPT_PIXELSHADER) > + { > + SET_TABLE(PRES_REGTAB_OCONST, SetPixelShaderConstantF, float); > + SET_TABLE(PRES_REGTAB_OICONST, SetPixelShaderConstantI, int); > + SET_TABLE(PRES_REGTAB_OBCONST, SetPixelShaderConstantB, BOOL); > + } > + else > + { > + FIXME("Unexpected parameter type %u.\n", peval->param_type); > + return D3DERR_INVALIDCALL; > + } > + #undef SET_TABLE This is certainly hard to handle nicely because of the multiple similar d3d9 functions with slightly different signatures but I think it's better to avoid macros (especially such large ones) as much as possible. There are multiple ways to achieve that. Perhaps the easiest one is to turn SET_TABLE into a function taking an array of enum PRES_REG_TABLES (which, btw, should be lowercase) and the shader type as additional parameters, loop over the tables and call the correct d3d9 function by using two levels of switches (or ifs). The type isn't really necessary, you can calculate the offset with table_info[].component_size.

March 22, 2016

Re: [v5 5/8] d3dx9: Implement fxlc constants (expressions) in effect.

by Matteo Bruni

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > +static unsigned int regstore_is_val_set_reg(struct d3dx_regstore *rs, unsigned int table, unsigned int reg_idx) > +{ > + return rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] & > + (1ul << (reg_idx % PRES_BITMASK_BLOCK_SIZE)); > +} Actually you don't want "ul" here, just "u". > +static void regstore_set_float(struct d3dx_regstore *rs, unsigned int table, unsigned int offset, float v) > +{ > + BYTE *p; > + unsigned int reg_idx; > + > + p = (BYTE *)rs->tables[table] + table_info[table].component_size * offset; > + switch (table_info[table].type) > + { > + case PRES_VT_FLOAT : *(float *)p = v; break; > + case PRES_VT_DOUBLE: *(double *)p = v; break; > + case PRES_VT_INT : *(int *)p = roundf(v); break; > + case PRES_VT_BOOL : *(BOOL *)p = !!v; break; > + } > + reg_idx = OFFSET2REG(table, offset); > + rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] |= > + 1ul << (reg_idx % PRES_BITMASK_BLOCK_SIZE); Same here. > +static HRESULT set_constants_param(struct d3dx_regstore *rs, struct d3dx_const_tab *const_tab, > + D3DXHANDLE hc, struct d3dx_parameter *param) > +{ > + ID3DXConstantTable *ctab = const_tab->ctab; > + D3DXCONSTANT_DESC desc; > + unsigned int const_count, param_count, i, j, n, table, start_offset; > + unsigned int nminor, nmajor, major_stride, inp_ind; Nitpick, also rename nmajor/nminor to major_size or just major (resp. minor). inp_ind also feels like it has room for improvement, although I don't have any good suggestion. > +#define ARGS_ARRAY_SIZE 8 > +static HRESULT execute_preshader(struct d3dx_preshader *pres) > +{ > + unsigned int i, j, k; > + float args[ARGS_ARRAY_SIZE]; Doesn't this need to be double to preserve the precision of the immediate operands / literals? I guess that means the regstore should also be able to return doubles.

March 22, 2016

Re: [v5 3/8] d3dx9: Implement preshader parsing.

by Matteo Bruni

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > +enum PRES_VALUE_TYPE Please use lowercase for type names. > +#define OFFSET2REG(table, offset) ((offset) / table_info[table].reg_component_count) I think this could be a function instead, that's usually preferred to macros when possible. Not sure about the name, maybe get_reg_offset(). > +static HRESULT regstore_alloc_table(struct d3dx_regstore *rs, unsigned int table) > +{ > + unsigned int sz; Nitpick, I would just spell out "size", it's pretty short anyway. > +static void regstore_set_values(struct d3dx_regstore *rs, unsigned int table, void *data, > + unsigned int start_offset, unsigned int count) > +{ > + unsigned int reg_idx; > + > + if (!count) > + return; > + > + memcpy((BYTE *)rs->tables[table] + start_offset * table_info[table].component_size, > + data, count * table_info[table].component_size); > + for (reg_idx = OFFSET2REG(table, start_offset); reg_idx <= OFFSET2REG(table, start_offset + count - 1); > + ++reg_idx) > + rs->table_value_set[table][reg_idx / PRES_BITMASK_BLOCK_SIZE] |= > + 1u << (reg_idx % PRES_BITMASK_BLOCK_SIZE); This might be optimized, enabling each bit one by one doesn't seem very efficient. > +} > + > +static void dump_bytecode(void *data, unsigned int size) > +{ > + unsigned int *bytecode = (unsigned int *)data; > + unsigned int i, j, n; > + > + size /= 4; Nitpick, sizeof(*bytecode).

March 22, 2016

Re: [v5 2/8] d3dx9: Introduce preshaders in effect.

by Matteo Bruni

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > @@ -5435,9 +5416,30 @@ static HRESULT d3dx9_parse_array_selector(struct d3dx9_base_effect *base, struct > } > TRACE("Unknown DWORD: 0x%.8x.\n", *(DWORD *)(ptr + string_size)); > > - FIXME("Parse preshader.\n"); > + d3dx_create_param_eval(base, (DWORD *)(ptr + string_size) + 1, object->size - (string_size + 1), > + D3DXPT_INT, &param->param_eval); Does this do the right thing if ptr + string_size is aligned to a DWORD? In other words, does the bytecode contain 4 bytes of padding if string_size % 4 == 0?

March 22, 2016

Re: [v5 1/8] d3dx9: Add test for preshader in effect.

by Matteo Bruni

2016-03-21 14:55 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > +struct test_struct > +{ > + float3 v1; > + float fv; > + float4 v2; > +}; > + > +test_struct ts1[1] = {{{9, 10, 11}, 12, {13, 14, 15, 16}}}; > +test_struct ts2[2] = {{{0, 0, 0}, 0, {0, 0, 0, 0}}, {{1, 2, 3}, 4, {5, 6, 7, 8}}}; Is it also possible to create a struct with an array field? And an array of those structs? > + static const struct > + { > + const char *comment; > + BOOL todo[4]; > + unsigned int result[4]; > + } > + test_effect_preshader_op_results[] = > + { > + {"1 / op", { TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0xff800000, 0xbee8ba2e, 0x00200000}}, > +#if __x86_64__ > + {"rsq", { TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0x7f800000, 0x3f2c985d, 0x1f800000}}, > +#else > + {"rsq", { TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0x7f800000, 0x3f2c985c, 0x1f800001}}, > +#endif > + {"mul", { TRUE, TRUE, TRUE, TRUE}, {0x00000000, 0x80000000, 0x40d33334, 0x7f800000}}, > + {"add", {FALSE, TRUE, TRUE, TRUE}, {0x3f800000, 0x40000000, 0xc0a66666, 0x7f7fffff}}, > + {"lt", {FALSE, FALSE, TRUE, FALSE}, {0x3f800000, 0x3f800000, 0x00000000, 0x00000000}}, > + {"ge", { TRUE, TRUE, FALSE, TRUE}, {0x00000000, 0x00000000, 0x3f800000, 0x3f800000}}, > + {"neg", { TRUE, TRUE, TRUE, TRUE}, {0x80000000, 0x00000000, 0x400ccccd, 0xff7fffff}}, > + {"rcp", { TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0xff800000, 0xbee8ba2e, 0x00200000}}, > + {"frac", {FALSE, FALSE, TRUE, FALSE}, {0x00000000, 0x00000000, 0x3f4ccccc, 0x00000000}}, > + {"min", {FALSE, TRUE, TRUE, TRUE}, {0x00000000, 0x80000000, 0xc0400000, 0x40800000}}, > + {"max", { TRUE, TRUE, TRUE, TRUE}, {0x3f800000, 0x40000000, 0xc00ccccd, 0x7f7fffff}}, > +#if __x86_64__ > + {"sin", {FALSE, TRUE, TRUE, TRUE}, {0x00000000, 0x80000000, 0xbf4ef99e, 0xbf0599b3}}, > + {"cos", { TRUE, TRUE, TRUE, TRUE}, {0x3f800000, 0x3f800000, 0xbf16a803, 0x3f5a5f96}}, > +#else > + {"sin", {FALSE, TRUE, TRUE, TRUE}, {0x00000000, 0x80000000, 0xbf4ef99e, 0x3f792dc4}}, > + {"cos", { TRUE, TRUE, TRUE, TRUE}, {0x3f800000, 0x3f800000, 0xbf16a803, 0xbe6acefc}}, > +#endif > + {"den mul",{ TRUE, TRUE, TRUE, TRUE}, {0x7f800000, 0xff800000, 0xbb94f209, 0x000051ec}}, > + {"dot", {FALSE, TRUE, TRUE, FALSE}, {0x00000000, 0x7f800000, 0x41f00000, 0x00000000}}, > +#if __x86_64__ > + {"prec", { TRUE, TRUE, TRUE, FALSE}, {0x2b8cbccc, 0x2c0cbccc, 0xac531800, 0x00000000}} > +#else > + {"prec", { TRUE, TRUE, FALSE, FALSE}, {0x2b8cbccc, 0x2c0cbccc, 0x00000000, 0x00000000}} > +#endif > + }; I don't like those #ifdefs much although apparently I don't have nicer suggestions.

March 22, 2016

Re: [v4 2/6] d3dx9: add preshaders to effect.

by Matteo Bruni

2016-03-18 23:54 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > On 03/19/2016 12:55 AM, Matteo Bruni wrote: >> 2016-03-17 12:59 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: >> >>> +enum PRES_REG_TABLES >>> +{ >>> + PRES_REGTAB_NONE, >>> + PRES_REGTAB_IMMED, /* immediate double constants from CLIT */ >>> + PRES_REGTAB_CONST, >>> + PRES_REGTAB_VERTEX, /* not used */ >>> + PRES_REGTAB_OCONST, >>> + PRES_REGTAB_OBCONST, >>> + PRES_REGTAB_OICONST, >>> + PRES_REGTAB_REG, >>> + PRES_REGTAB_MAX, >>> + PRES_REGTAB_FIRST = PRES_REGTAB_IMMED, >>> + PRES_REGTAB_LAST = PRES_REGTAB_REG, >>> +}; >> You can drop PRES_REGTAB_NONE unless it's going to be used. > These constants currently match values in preshader bytecode. > PRES_REGTAB_NONE is used as a placeholder for value 0. I can remove it, > but then have PRES_REGTAB_IMMED = 1 explicitly, or introduce a separate > mapping table between original constants and these enum. I'm late on this one... Both options are fine with me, with a slight preference for the latter since that avoids allocating space for the unused tables in a number of places. Ah, I just noticed a couple more bits here. The enum name should be lowercase and I'd rename PRES_REGTAB_MAX to PRES_REGTAB_COUNT.

March 22, 2016

Re: [tools 2/2] Support for disabling and enabling warnings, handle warning number 2368

by Nikolay Sivov

On 20.03.2016 13:12, Bolotov Sergey wrote: > diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c > index 8b65ead..137bb2d 100644 > --- a/tools/widl/write_msft.c > +++ b/tools/widl/write_msft.c > @@ -51,6 +51,7 @@ > #include "header.h" > #include "hash.h" > #include "typetree.h" > +#include "parser.h" > > enum MSFT_segment_index { > MSFT_SEG_TYPEINFO = 0, /* type information */ > @@ -504,7 +505,7 @@ static int ctl2_alloc_guid( > offset = ctl2_find_guid(typelib, hash_key, &guid->guid); > if (offset != -1) > { > - if (pedantic) > + if (is_warning_enabled(2368)) > warning("duplicate uuid {%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x}\n", > guid->guid.Data1, guid->guid.Data2, guid->guid.Data3, > guid->guid.Data4[0], guid->guid.Data4[1], guid->guid.Data4[2], guid->guid.Data4[3], > Duplicate UUID is not a warning 2368, it's an error 2270, I don't think you can suppress it, so we should really abort compilation at this point. Also if we're doing this, it looks cleaner to have is_warning..() check within warning(), so you can check there if it's enabled or not, and it's possible 'pedantic' should take precedence. Could you share a minimal idl you're using to test that?

March 22, 2016

Re: [tools 1/2] Handle "midl_pragma warning" statement in parser

by Nikolay Sivov

On 20.03.2016 13:11, Bolotov Sergey wrote: > Signed-off-by: Bolotov Sergey <bolotov.s.s(a)yandex.ru> > --- > tools/widl/parser.h | 2 ++ > tools/widl/parser.l | 25 +++++++++++++++++++++++++ > tools/widl/parser.y | 38 +++++++++++++++++++++++++++++++++++++- > tools/widl/widltypes.h | 7 +++++++ > 4 files changed, 71 insertions(+), 1 deletion(-) > > diff --git a/tools/widl/parser.h b/tools/widl/parser.h > index 1bcc3c1..c15d874 100644 > --- a/tools/widl/parser.h > +++ b/tools/widl/parser.h > @@ -45,6 +45,8 @@ void pop_import(void); > > int is_type(const char *name); > > +int do_warning(char *toggle, warning_list_t *wnum); > + > extern char *temp_name; > > #endif > diff --git a/tools/widl/parser.l b/tools/widl/parser.l > index 5c2dcab..65e0f45 100644 > --- a/tools/widl/parser.l > +++ b/tools/widl/parser.l > @@ -164,6 +164,7 @@ UUID *parse_uuid(const char *u) > yy_pop_state(); > } > <PP_PRAGMA>[^\n]* parser_lval.str = xstrdup(yytext); yy_pop_state(); return aPRAGMA; > +<INITIAL>^{ws}*"midl_pragma warning" return tPRAGMA_WARNING; > <INITIAL,ATTR>\" yy_push_state(QUOTE); cbufidx = 0; > <QUOTE>\" { This is wrong, any number of spaces is allowed before 'warning'. > yy_pop_state(); > @@ -555,3 +556,27 @@ void abort_import(void) > for (ptr=0; ptr<import_stack_ptr; ptr++) > unlink(import_stack[ptr].temp_name); > } > + > +static void warning_disable(int warning) > +{ > + printf("disable %d\n", warning); > +} > + > +static void warning_enable(int warning) > +{ > + printf("enable %d\n", warning); > +} > + > +int do_warning(char *toggle, warning_list_t *wnum) > +{ > + warning_t *warning; > + if(!strcmp(toggle, "disable")) > + LIST_FOR_EACH_ENTRY(warning, wnum, warning_t, entry) > + warning_disable(warning->num); > + else if(!strcmp(toggle, "enable")) > + LIST_FOR_EACH_ENTRY(warning, wnum, warning_t, entry) > + warning_enable(warning->num); > + else > + return 0; > + return 1; > +} You remove this in next patch, I think it'd be enough to add parser support first, so widl does not fail on such construct, and add handling as 2/2. Why do you need this in a first place? Is it to process some third party idls?

March 22, 2016

Re: WineConf 2016

by Tom Wickline

Hello Everyone, Would it be possible to set a location and date for WineConf 2016 at this time? As no one outside of CodeWeavers has stepped up to host the conference I take it the conference will be held once again in St. Paul? Cheers, Tom On Wed, Mar 2, 2016 at 11:42 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Hello guys, > > it's that time of the year again where we start thinking about the next > WineConf. > > Last year would already have been the turn for North America so the next > WineConf will happen definitely there. > > Jeremy White / CodeWeavers, as always, was very generous and offered to > host it in Minneapolis (or was it St. Paul? ;). > > But if you're in US / Canada and really hoped to host the next WineConf > now is your time to speak up! The Twin Cities are beautiful at -30 C but > we wouldn't mind seeing other places too. > > bye > michael > > >

March 22, 2016

Re: XInput and HID - architecture

by Juan Jose Gonzalez

On 03/22/2016 01:27 AM, Roderick Colenbrander wrote: > >>> As you have seen the xbox controller lacks proper HID descriptors and >>> on Windows the drivers fake descriptors to allow DirectInput to work >>> as well. We would be doing something not to different. For the >>> DirectInput I would report the real device name and the real ranges, >>> similar if games use raw input (not sure if there are games which do >>> this). >> On Wine, this would work the other way around. We would have raw (HID) >> devices as a base, and create DInput and XInput devices from those. > I understand that part. What I meant is that Windows reports 2 > different devices one with HID and one without. I was suggesting this > as a way to potentially handle non-native xinput devices, e.g. the > non-native device is made to appear like the xbox one on windows with > the missing descriptors etcetera. I'm not sure I understand what you mean. The currently planned wine architecture uses the HID subsystem as a common base, allowing us to create a single minidriver per backend (evdev, hidraw, etc.), and then lets DInput and XInput access that. Are you suggesting putting all the XInput code (gamepad matching, control mapping) into the HID subsystem? > Though this still wouldn't handle > the enumeration situation for apps using wmi. Sorry, as you may have noticed, I'm not too savvy about Windows APIs. What is wmi? - Juan

March 22, 2016

Re: [PATCH 1/6] ddraw/tests: Rewrite blt_test().

by Marvin

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=21588 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w8 (32 bit visual) === visual.c:1387: Test failed: unexpected colortable on offscreen surface === w864 (32 bit visual) === visual.c:1387: Test failed: unexpected colortable on offscreen surface === w1064 (32 bit visual) === visual.c:307: Test failed: Clear rectangle 3(pos, neg) has color 0000ff00 visual.c:309: Test failed: Clear rectangle 1(pos, pos) has color 0000ff00 visual.c:311: Test failed: Clear rectangle 4(NULL) has color 0000ff00 visual.c:313: Test failed: Clear rectangle 4(neg, neg) has color 0000ff00 visual.c:1387: Test failed: unexpected colortable on offscreen surface === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

March 22, 2016

Re: Student interested in GSoC 2016 implementing D3DX9 API idea

by Xu Zhao

Hello Matteo, I spent some time reading the code as well as read several current bugs from bugzilla. I think working on fonts and mesh related APIs is good for this GSoC project, for example: d3dx:ID3DXFontImpl_DrawText d3dx:ID3DXFontImpl_PreloadText d3dx:ID3DXFontImpl_OnLostDevice d3dx:ID3DXFontImpl_OnResetDevice d3dx:D3DXCreateFontIndirect d3dx:ID3DXMeshImpl_OptimizeInplace I am also interested in following surface API if I got more time. d3dx:D3DXLoadSurfaceFromMemory Here is my current proposal: https://docs.google.com/document/d/1i8de2gWloRMJeDuziAfwqq65pBeGrQ3bXjvzQBB… What do you think? Regards, - Xu -- Xu Zhao i(a)xuzhao.net On Tue, Mar 1, 2016, at 09:26 AM, Matteo Bruni wrote: > 2016-02-29 23:53 GMT+01:00 Xu Zhao <i(a)xuzhao.net>: > > Hello Wine Community, > > > > First congrats that Wine Project get accepted into GSoC 2016 summer > > organization! > > I am currently a PhD student in University of Toronto and I am > > interested in the D3DX9 API implementation task. Mainly because I would > > like to see more games can run in wine because of my work! > > That's great! > > > > > My research field is operating system so I am a pretty good C/CPP > > programmer. However I am not very familiar with DirectX related > > programming and hopefully I can get some help from the community, like > > where to start. > > I have read the wiki entry of D3DX9 API and want to get some help in > > selecting a reasonable sized API list, maybe someone can reply and > > provide some help? > > I guess it depends on what you find most interesting among the > available functions / APIs. I suggest you to lookup the functions and > "areas" listed in the wiki on MSDN, in the Wine source code and on > Wine's bugzilla and then decide what you like or find most useful. The > various things listed aren't all of the same "size" (e.g. the fonts > stuff might be good enough for a GSoC project by itself while each of > the other entries probably isn't enough, while the entire "effect > framework" is likely too big) but selecting a reasonable set should be > easier once we know your preferences. > > > > > Thank you! > > > > Regards, > > - Xu > > > > -- > > Xu Zhao > > i(a)xuzhao.net > > > >

March 22, 2016

Re: Server Downtime 2016-03-16 19:00 CDT

by Jeremy Newman

I'll look into it, most likely some defaults changed when the system packages updated. -N On 03/22/2016 01:10 PM, Sebastian Lackner wrote: > On 17.03.2016 02:08, Jeremy Newman wrote: >> Server and all services should be back online. Let me know if you notice any unexpected changes in behavior. >> >> -N > > Hiho, > > I already tried to contact you via IRC, but since you probably missed it, I will ask again this way. > Is it intentional that the RSYNC server, previously used to synchronize WineHQ packages, is no longer > present / accessible? It would be nice if you could fix that soon, so that we can continue pushing > the latest release. > > Regards, > Sebastian >

March 22, 2016

Allowing child HWND to be shared across multiple processes

by Brandon Adkins

Hi guys. If this is the wrong forum for this question, please direct me to the correct one. I am working on porting a Windows application over to Linux, and my hope is to use Wine to make that go as quickly as possible. In my research, I have found one possible hangup, and hopefully you guys can answer it in a few minutes, vs the week or so of work for me to test it out myself. Long story short, I have an application which creates child HWNDs. The application also launches separate processes. When WM_PAINT messages come in for those child HWNDs, it passes the HWND to one of the other processes, and that other process is the one that actually draws on it. This works great on Windows. But I have found out that Wine only makes XWindows for top level HWNDs. So my question is: Can an application in wine perform operations (like drawing, BitBlting) onto a child HWND owned by another process? Any tips or guidance you can give will be greatly appreciated. Best regards!

March 22, 2016

Re: Server Downtime 2016-03-16 19:00 CDT

by Sebastian Lackner

On 17.03.2016 02:08, Jeremy Newman wrote: > Server and all services should be back online. Let me know if you notice any unexpected changes in behavior. > > -N Hiho, I already tried to contact you via IRC, but since you probably missed it, I will ask again this way. Is it intentional that the RSYNC server, previously used to synchronize WineHQ packages, is no longer present / accessible? It would be nice if you could fix that soon, so that we can continue pushing the latest release. Regards, Sebastian

March 22, 2016

Re: [PATCH 2/6] ddraw/tests: Get rid of the unused "d3d" variable in test_shademode().

by Marvin

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=21589 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

March 22, 2016

Re: [PATCH] vulkan-icd: Add stub dll.

by Gabríel Arthúr Pétursson

On Tue, Mar 22, 2016 at 4:43 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > Thanks for sharing some of the material. I did some more reading last > night and now. I was already leaning towards having to implement the > ICD interface since now it is properly documented, which wasn't the > case for OpenGL. I don't like the fact too much that applications can > statically link the loader portions yikes, which will probably cause > issues down the road. Applications statically linking the loader shouldn't cause issues. I believe that if we decide to ship a loader with Wine, and I assume we want to do that, it would probably be best/simplest to use Khronos' loader. That loader, unmodified, is what I'm currently using to run Vulkan applications against the ICD implementation. > The part which I'm not sure about is how and if we want to handle > multiple Linux vulkan ICD drivers. Assuming big chunks of our vulkan > code would live in the display driver, I guess it would somehow act > like a 'proxy' to the Linux ICD drivers. Handling multiple ICDs is entirely up to the loader. I believe supporting multiple Vulkan ICD drivers is worth it. Software implementations of Vulkan, for example, could be installed alongside Wine's ICD and not need any special interaction with Wine or the host. The loader is also responsible for hooking up any explicit or implicit layers installed, which is needed for some applications to function properly, such as the Steam overlay and RenderDoc. > I haven't used the vulkan APIs yet, so I don't have a good feeling for > all aspects yet. Based on what I described, I wonder to what extend we > need vulkan-icd.dll. Assuming there is enough code we can share > between future other vulkan backends in wine for Android and who knows > some day crApple when they support Vulkan, it may make sense to have > this dll. Else maybe it should live in the ICD implementation, which > I'm leaning towards should live as part of the display driver. (Maybe > winex11.drv should just be registered in the registry as an ICD, not > sure) Significant parts of the ICD has to with plumbing between Windows' loader and the host's loader. WSI integrations are exposed in Vulkan as optional extensions. It is valid for implementations not to support them; applications that only require compute or off-screen rendering don't need them. > I don't want to scare you, but window management will also be quite a > challenge. Handling of applications using a full window for vulkan is > probably easy since there is a direct mapping to an x11 window. If > vulkan allows child window rendering (which I guess it does), that > will need some special handling. The challenge is that we only have 1 > X11 window per application. For OpenGL on Linux we use a hack by > rendering to a pixmap and copying the output back on the X11 window. > Not sure what can be done for Vulkan. I would say this is not high > priority yet, however our vulkan wsi layer shouldn't need a complete > redesign to support this. Vulkan does not allow child rendering. On Windows, an application passes a pair of HINSTANCE and HWND to the implementation. On Linux with XLib, a pair of Display* and Window is passed. Mapping between those two should be trivial. With that given, I admit I have not yet implemented the WSI integration so unforeseen issues may or may not arise. I'll find out shortly. :) > I will have a closer look at Vulkan as well in the coming days and > maybe able to help out a little bit on the side, but my time is a bit > limited these days :( I'm more than happy to collaborate with anyone interested in helping out. If you find the time, feel free to drop me a line.

March 22, 2016

Re: [PATCH] vulkan-icd: Add stub dll.

by Roderick Colenbrander

On Mon, Mar 21, 2016 at 10:03 PM, Gabríel Arthúr Pétursson <gabriel(a)system.is> wrote: > On Tue, Mar 22, 2016 at 4:36 AM, Roderick Colenbrander > <thunderbird2k(a)gmail.com> wrote: >> Hi Gabríel, >> >> Thanks for your patch. Depending on the direction where you intend to >> take this, I'm not sure if we need this dll. Note I haven't done much >> with Vulkan myself yet, but following the analogy of opengl32, the ICD >> portion should be inside winex11.drv (and our other drivers). It is >> what should export this function call ultimately and similar needs to >> host the x11 related vulkan code, which has to live in here as well, >> because such code is not supposed to live outside winex11.drv. >> >> Thanks, >> Roderick > > The ICD is intended for use by Khronos' official Vulkan loader, which > typically is shipped as a separate DLL, vulkan-1.dll, although > applications may statically link the loader. The interaction between > an ICD and a loader is well documented[1]. > > I have provisional patches available on my Github repository[2]. It's > not yet fully complete though, missing the WSI integration. My plan is > to link to winex11.drv and map a HWND to xlib's Display* and Window. > Maybe that's not the best solution, in which case, I'd love to hear > your suggestions. > > [1] https://github.com/LunarG/VulkanSamples/blob/master/loader/LoaderAndLayerIn… > [2] https://github.com/polarina/wine/commits/vulkan Thanks for sharing some of the material. I did some more reading last night and now. I was already leaning towards having to implement the ICD interface since now it is properly documented, which wasn't the case for OpenGL. I don't like the fact too much that applications can statically link the loader portions yikes, which will probably cause issues down the road. The main thing, which I think needs a lot of attention is the design of the driver model and how to load the native vulkan driver. This is quite tricky and I'm not sure yet what the right way is, technically this also still needs solving for wine's opencl implementation, which is also not correct. My initial feeling is that loading of the vulkan library needs to live next to the WSI implementation, which I think should be in the wine display drivers. The part which I'm not sure about is how and if we want to handle multiple Linux vulkan ICD drivers. Assuming big chunks of our vulkan code would live in the display driver, I guess it would somehow act like a 'proxy' to the Linux ICD drivers. I haven't used the vulkan APIs yet, so I don't have a good feeling for all aspects yet. Based on what I described, I wonder to what extend we need vulkan-icd.dll. Assuming there is enough code we can share between future other vulkan backends in wine for Android and who knows some day crApple when they support Vulkan, it may make sense to have this dll. Else maybe it should live in the ICD implementation, which I'm leaning towards should live as part of the display driver. (Maybe winex11.drv should just be registered in the registry as an ICD, not sure) I don't want to scare you, but window management will also be quite a challenge. Handling of applications using a full window for vulkan is probably easy since there is a direct mapping to an x11 window. If vulkan allows child window rendering (which I guess it does), that will need some special handling. The challenge is that we only have 1 X11 window per application. For OpenGL on Linux we use a hack by rendering to a pixmap and copying the output back on the X11 window. Not sure what can be done for Vulkan. I would say this is not high priority yet, however our vulkan wsi layer shouldn't need a complete redesign to support this. I will have a closer look at Vulkan as well in the coming days and maybe able to help out a little bit on the side, but my time is a bit limited these days :( Thanks, Roderick

March 22, 2016

Re: [PATCH] msvcr120/tests: Add critical section test.

by Piotr Caban

On 03/22/16 17:28, YongHao Hu wrote: > How long is a test running acceptable? I want to know a appropriate > standard. There's no rule for that. In most cases 100ms wait is long enough to make sure something works. Of course if the test is useful and it can't be written to end quickly it can take much longer. I'm trying to avoid tests that calls Sleep if possible. Thanks, Piotr

March 22, 2016

Re: [PATCH] msvcr120/tests: Add critical section test.

by YongHao Hu

Hi Piotr, On 16/3/22 下午10:29, Piotr Caban wrote: > Hi YongHao, > > On 03/18/16 17:24, YongHao Hu wrote: >> dlls/msvcr120/tests/msvcr120.c | 300 >> +++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 300 insertions(+) > I don't think this is a good approach for adding tests of > critical_section class. Executing tons of enter/leave calls is not > really testing much. Your test_critical_section_lock tests will > probably pass if you comment all critical section related calls out > (it passed on my computer in 10 consecutive runs, never failed, > probably it's because the code was optimized during compilation). > Testing 5s/6s timeouts is also not a good idea. Because of it the > tests are running much longer. How long is a test running acceptable? I want to know a appropriate standard. > > It would be much better if you test following things: > - just check some basic functionality of enter/leave: enter cs in > main thread, start new thread that tries to enter it as well, wait for > 100ms and check that it was not able to enter the cs, then leave cs in > main thread and wait for thread to enter cs and finish > - check some basic functionality of try_lock: use it to lock the cs, > check if it fails on locked cs Thank you for your comment, it's of great help. I will try it. > > Also the tests failed on testbot, I was not checking why. The tests failed on w2008s64(64bit msvcr120), however, it succeed on 32bit msvcr120. I did not figure out this. Thank you.

March 22, 2016

Re: services: Make release_process() static.

by Sebastian Lackner

On 22.03.2016 11:26, Francois Gouget wrote: > Signed-off-by: Francois Gouget <fgouget(a)free.fr> > --- > programs/services/services.c | 12 ++++++------ > programs/services/services.h | 1 - > 2 files changed, 6 insertions(+), 7 deletions(-) > I do not mind if this patch is accepted, but follow patches would have to undo this change again. We also need the function from other services files.

March 22, 2016

Re: [PATCH] msvcr120/tests: Add critical section test.

by Piotr Caban

Hi YongHao, On 03/18/16 17:24, YongHao Hu wrote: > dlls/msvcr120/tests/msvcr120.c | 300 > +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 300 insertions(+) I don't think this is a good approach for adding tests of critical_section class. Executing tons of enter/leave calls is not really testing much. Your test_critical_section_lock tests will probably pass if you comment all critical section related calls out (it passed on my computer in 10 consecutive runs, never failed, probably it's because the code was optimized during compilation). Testing 5s/6s timeouts is also not a good idea. Because of it the tests are running much longer. It would be much better if you test following things: - just check some basic functionality of enter/leave: enter cs in main thread, start new thread that tries to enter it as well, wait for 100ms and check that it was not able to enter the cs, then leave cs in main thread and wait for thread to enter cs and finish - check some basic functionality of try_lock: use it to lock the cs, check if it fails on locked cs Also the tests failed on testbot, I was not checking why. Thanks, Piotr

March 22, 2016

Re: XInput and HID - architecture

by Aric Stewart

On 3/21/16 7:27 PM, Roderick Colenbrander wrote: > On Sat, Mar 19, 2016 at 10:59 AM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: >> Hi, >> >> On 03/16/2016 02:45 AM, Roderick Colenbrander wrote: >>> Hi Juan, >>> >>> Let me reply to the start of the thread before diving into the >>> specifics on calibration. >>> >>> In my opinion, I'm not sure what the best way would be to handle >>> passing of HID data to xinput. The main thing to consider as part of >>> this is handling of non-native xinput devices (e.g. DS4 or >>> SteamController) provided we want to support this. Aside from passing >>> up the HID data the other challenge for xinput devices is the >>> enumeration part, which many (older) games do through a mixture of >>> WMI, dinput and xinput. For this to work we need to report an actual >>> xinput gamepad. >> Wine is supposed to mimic Windows' behavior as well as possible. Thus, >> the proper way to implement xinput would be to access the USB devices >> directly. The hid->xinput mapping is already non-compliant with the >> windows behavior, but currently necessary. However, in my opinion, we >> should only try to parse those HID descriptors that correspond to XInput >> devices, as provided by common XInput->HID drivers on different host >> OSs. Nevertheless, once wine's HID->Xinput backend is finished, the >> end-users can (locally) add their own mappings for any HID controller >> they want to use. I just wouldn't add those mappings to the wine repo. >> I would like to get some input on that, however. Do you think we should >> add mappings for non-xinput devices? >> >> Thank you for pointing out the enumeration process. The reason I >> implemented Xinput was to play a game that didn't support any other >> input method, so until now, I hadn't given it much thought. According to >> https://msdn.microsoft.com/en-us/library/windows/desktop/ee417014%28v=vs.85… >> , an XInput device shows up in DInput with an ID containing "IG_", which >> is what developers should use to filter them out. This might make things >> a bit difficult, since in Wine, both DInput and XInput devices are >> supposed to be created from a common HID base, so Wine's DInput cannot >> know anything about whether a device is an XInput device or not. >>> >>> My feeling would be for xinput to be quite stupid like it is on >>> Windows and feed it xbox controller compatible HID reports with the >>> same axes ranges, rumble ranges as the xbox controller. For more >>> custom devices you may want to support special handling e.g. button >>> emulation using touchpad on DS4 or maybe even on SteamController. >> The problem is that there is not a unique HID descriptor set for XInput. >> Each driver on each OS maps the xinput controls to a different layout, >> so we need some logic on the Wine XInput driver to tell those apart and >> map them back to XInput controls. > > Nonetheless a mapping is needed from evdev, optionally Linux hidraw > and whatever backend other OSes use. HID is nice in theory, but in > practice it is quite messy (many buggy devices, spec abuses, custom > HID requests to enable a device..). My feeling is to handle the > mapping to x360 at a level below xinput to avoid the mapping issues in > xinput. Depending on what other non-native xinput devices we may want > to handle (ds3, ds4, wii u controller, steam controller are all easy) > you may want more control at a lower level to handle custom > functionality, which could optionally need handling through many > different fields in the HID descriptor (e.g. touch). > The grand hope is that we can move all the platform specific code to HID and not have it reproduces in 3 different locations. We write dinput, winmm and Xinput to all be HID clients. You give a number of reasons that HID is messy, but I assume you are talking about windows native HID? Since right now we would be going through our own hid and hid minidrivers we are able to avoid a lot of that messiness. What are the specific areas that HID will be insufficient for xinput? Having specific examples will be helpful in figuring out a course of action. >>> >>> As you have seen the xbox controller lacks proper HID descriptors and >>> on Windows the drivers fake descriptors to allow DirectInput to work >>> as well. We would be doing something not to different. For the >>> DirectInput I would report the real device name and the real ranges, >>> similar if games use raw input (not sure if there are games which do >>> this). >> On Wine, this would work the other way around. We would have raw (HID) >> devices as a base, and create DInput and XInput devices from those. > > I understand that part. What I meant is that Windows reports 2 > different devices one with HID and one without. I was suggesting this > as a way to potentially handle non-native xinput devices, e.g. the > non-native device is made to appear like the xbox one on windows with > the missing descriptors etcetera. Though this still wouldn't handle > the enumeration situation for apps using wmi. Can we just have the minidrivers for evdev / OSX / hidraw implement this? Do you have specs on what things they would need to report? What are the missing descriptors? thanks! -aric > >> >> - Juan >>> Thanks, >>> Roderick >>> >>> >>> >>> >>> On Thu, Mar 3, 2016 at 12:39 AM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote: >>>> Hi, >>>> >>>> I got a bit stuck and would like to hear your opinion on the XInput HID >>>> backend, specifically on the mappings, i.e. the code that "accepts" a >>>> certain device based on its properties and then maps its buttons and axes to >>>> XInput buttons and axes. >>>> >>>> As long as the mappings are fixed, i.e. are not supposed to be extended or >>>> edited by the user, everything can be compiled into xinput1_3.dll. However, >>>> I would like to provide a "xinput.cpl" control panel node for xinput similar >>>> to "joy.cpl", where the user can not only test the XInput gamepads, but also >>>> manage the XInput-HID backend mappings. The first part can be accomplished >>>> by using xinput1_3.dll. However, in order to load and persist different >>>> mappings, the second part requires access to the functions that serialize >>>> and deserialize the mappings. It also needs some way of getting raw >>>> capabilities and changes in HID devices in order to be able to create new >>>> mappings. >>>> >>>> Here are some possible ways of solving it: >>>> >>>> Extend xinput1_3.dll with the required management functions and add a >>>> "wine/xinput_hid_mgmt.h" or similar header that declares those methods. >>>> xinput.cpl could then simply use xinput1_3.dll to perform all management >>>> functions. I'm not sure if this would break anything due to the additional >>>> exports in the dll. >>>> Extract the mapping load and store logic into a separate "xinputhid.dll" or >>>> similar. I this case both xinput1_3.dll and xinput.cpl would access this >>>> library to load and store mappings. >>>> Move the xinput core and backends into a driver and let xinput1_3.dll access >>>> it via IOCTLs. I believe this is the way it works on windows, although there >>>> doesn't seem to be any freely available documentation regarding the internal >>>> architecture. The XInput-HID backend could then create its own kernel object >>>> as a management interface, which could be accessed by xinput.cpl. This would >>>> have the added effect of having a single instance managing the xinput >>>> devices if several programs are running at the same time, which mimics the >>>> behavior of windows. >>>> >>>> What do you think would be the best option? Is there another way I haven't >>>> mentioned? >>>> >>>> - Juan >>>> >>>> >>>> >>>> >>

March 22, 2016

Re: [PATCH 2/2] ddraw/tests: Use SetRect() instead of open coding it.

by Michael Stefaniuc

On 03/22/2016 10:59 AM, Marvin wrote: > 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=21571 > > Your paranoid android. > > > === w864 (32 bit d3d) === > d3d.c:2311: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level > d3d.c:2311: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level > d3d.c:2311: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level > d3d.c:2311: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level > d3d.c:2492: Test failed: Unexpected destination texture level pixels; 257 differences > d3d.c:2636: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level > d3d.c:2636: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level > d3d.c:2636: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level > d3d.c:2636: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level > > === w1064 (32 bit d3d) === > d3d.c:2311: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level > d3d.c:2311: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level > d3d.c:2311: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level > d3d.c:2311: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level > d3d.c:2492: Test failed: Unexpected destination texture level pixels; 257 differences > d3d.c:2636: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level > d3d.c:2636: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level > d3d.c:2636: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level > d3d.c:2636: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level This are unrelated and pre-existing failures: https://test.winehq.org/data/bc357819296594aca300fdf30bb0cda46e9f0be0/win8_… > === w8 (32 bit visual) === > visual.c:1478: Test failed: unexpected colortable on offscreen surface > > === w864 (32 bit visual) === > visual.c:307: Test failed: Clear rectangle 3(pos, neg) has color 0000ff00 > visual.c:309: Test failed: Clear rectangle 1(pos, pos) has color 0000ff00 > visual.c:311: Test failed: Clear rectangle 4(NULL) has color 0000ff00 > visual.c:313: Test failed: Clear rectangle 4(neg, neg) has color 0000ff00 > visual.c:1478: Test failed: unexpected colortable on offscreen surface > > === w1064 (32 bit visual) === > visual.c:307: Test failed: Clear rectangle 3(pos, neg) has color 0000ff00 > visual.c:309: Test failed: Clear rectangle 1(pos, pos) has color 0000ff00 > visual.c:311: Test failed: Clear rectangle 4(NULL) has color 0000ff00 > visual.c:313: Test failed: Clear rectangle 4(neg, neg) has color 0000ff00 > visual.c:1478: Test failed: unexpected colortable on offscreen surface Same as before a no-op patch produces the same issues: https://testbot.winehq.org/JobDetails.pl?Key=21575 bye michael

March 22, 2016