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

Re: [PATCH 1/3] msvcrt: Call C structured exception translator in x86_64 __CxxFrameHandler
by Piotr Caban March 26, 2016

March 26, 2016

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

1 0

Re: [PATCH 5/5] d3d9/tests: Add a test for color varyings clamping.
by Marvin March 25, 2016

March 25, 2016

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.

1 0

Re: Need some advice on shell32
by Mathy Vanvoorden March 25, 2016

March 25, 2016

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.

1 0

Question about wine XWindow to HWND mapping
by Brandon Adkins March 25, 2016

March 25, 2016

Hi guys. 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!

2 2

Re: [PATCH] riched20: Implement ITextRange::ScrollIntoView.
by Huw Davies March 24, 2016

March 24, 2016

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. More importantly, I get a test failure: richole.c:785: Test failed: Moved scrollbar is at 60, should be 0. (Range 0-160.) Huw.

2 3

Re: [PATCH] wined3d: Support D3DFMT_L8 format as render target when supported by GPU.
by Henri Verbeet March 24, 2016

March 24, 2016

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.

3 7

Re: jscript: Added a few more arguments tests.
by Sebastian Lackner March 24, 2016

March 24, 2016

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?

2 1

Re: jscript: Added a few more arguments tests.
by Marvin March 24, 2016

March 24, 2016

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

1 0

Re: [v3] bcrypt: Added BCryptHash function.
by Patrick Armstrong March 24, 2016

March 24, 2016

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

1 0

Possible security bug with unmount
by Cédric Picard March 24, 2016

March 24, 2016

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

5 6

Re: [PATCH 1/4] xmllite/writer: Handle initial and ready states in the rest of tested Write* methods
by Dmitry Timoshkov March 24, 2016

March 24, 2016

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.

1 0

Re: oleaut32: add OleLoadPictureFile stub (try 2)
by Dmitry Timoshkov March 24, 2016

March 24, 2016

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.

2 1

Re: oleaut32: add OleLoadPictureFile stub
by Andrew Eikum March 24, 2016

March 24, 2016

> + * 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

2 1

Re: [v2] d3d9: Add test for D3DFMT_L8 format as render target.
by Henri Verbeet March 23, 2016

March 23, 2016

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.

1 0

XInput and HID - architecture
by Juan Jose Gonzalez March 23, 2016

March 23, 2016

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

6 24

Re: [PATCH 2/5] d3d11/tests: Add test for ClearRenderTargetView().
by Marvin March 23, 2016

March 23, 2016

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

1 0

Re: [PATCH 1/5] d3d10core/tests: Add test for ClearRenderTargetView().
by Marvin March 23, 2016

March 23, 2016

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

1 0

Re: [PATCH 4/4] xmllite/writer: Fix WriteEndElement()/WriteFullEndElement() on ready state
by Marvin March 23, 2016

March 23, 2016

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

1 0

Re: [PATCH 3/4] xmllite/writer: Properly fail on initial state in WriteEndElement()
by Marvin March 23, 2016

March 23, 2016

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

1 0

Re: [PATCH 2/4] xmllite/writer: Fix initial state handling in WriteEndDocument()
by Marvin March 23, 2016

March 23, 2016

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

1 0

Re: [PATCH 1/4] xmllite/tests: A test for Write* behaviour on initial writer state
by Marvin March 23, 2016

March 23, 2016

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

1 0

Re: [v2] bcrypt: Added BCryptHash function.
by Hans Leidekker March 23, 2016

March 23, 2016

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.

1 0

Re: [v5 2/8] d3dx9: Introduce preshaders in effect.
by Matteo Bruni March 23, 2016

March 23, 2016

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?

2 2

Re: mshtml: Fixed remaining xmlhttprequest test failures.
by Marvin March 23, 2016

March 23, 2016

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

1 0

Re: [tools 2/2] Support for disabling and enabling warnings, handle warning number 2368
by Nikolay Sivov March 23, 2016

March 23, 2016

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?

2 3

Re: [v5 8/8] d3dx9: Implement setting named shader constants in effect.
by Matteo Bruni March 22, 2016

March 22, 2016

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.

2 2

Re: [v5 1/8] d3dx9: Add test for preshader in effect.
by Matteo Bruni March 22, 2016

March 22, 2016

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.

2 2

Re: [v5 5/8] d3dx9: Implement fxlc constants (expressions) in effect.
by Matteo Bruni March 22, 2016

March 22, 2016

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.

1 0

Re: [v5 3/8] d3dx9: Implement preshader parsing.
by Matteo Bruni March 22, 2016

March 22, 2016

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).

1 0

Re: [v4 2/6] d3dx9: add preshaders to effect.
by Matteo Bruni March 22, 2016

March 22, 2016

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. > +++ b/dlls/d3dx9_36/preshader.c > @@ -0,0 +1,627 @@ > +/* > + * FX preshader parsing & execution, setting shader constants > + * from effect parameters. > + * It looks like that kind of general file description is omitted in newer source files. Maybe drop it? I don't particularly care though. > + /* TODO: use double precision for x64 arch */ > + {sizeof(float), 4, PRES_VT_FLOAT } /* PRES_REGTAB_REG */ Nitpick, just mention "64 bit" or something, we don't want to make all the non-Intel archs angry ;) > +#define PRES_VS_BITS_PER_WORD (sizeof(unsigned int) * 8) What does the _VS_ part of the name mean? I'm also a bit thrown off by the _WORD part, mostly because in Win32 WORD is a 16 bit while DWORD is 32 bit and unsigned int is also 32 bit. Maybe it's just me, I don't know. > +static void dump_shader_bytecode(void *data, unsigned int size) > +{ > + unsigned int *words = (unsigned int *)data; Same here. I guess you could call it "bytecode" or such. > +static unsigned int *find_bytecode_comment(unsigned int *ptr, unsigned int fourcc) > +{ > + while ((*ptr & 0xFFFF) == 0xFFFE) A couple leftover uppercase hexadecimal constants. > + hr = D3DXGetShaderConstantTable(byte_code, &ctab); > + if (FAILED(hr) || !ctab) > + { > + TRACE("Could not get CTAB data, hr %#x.\n", hr); > + /* returning OK is not a typo */ > + return D3D_OK; > + } Sorry, back to that comment again. I guess it would be better to spell out why that's the intended return value instead (e.g. "Not returning an error, shaders without a CTAB are valid."). > +static void dump_arg(struct d3dx_regstore *rs, struct d3dx_pres_operand *arg, int component_count) > +{ > + static const char *xyzw_str = "xyzw"; > + unsigned int i, table; > + > + table = arg->table; > + if (table == PRES_REGTAB_IMMED) > + { > + TRACE("("); > + for (i = 0; i < component_count; ++i) > + TRACE(i < component_count - 1 ? "%lf, " : "%lf", > + ((double *)rs->tables[PRES_REGTAB_IMMED])[arg->offset + i]); %lf is not right, %f already expects a double. I'd just use %.16e (which has the added benefit of showing something different from 0 in the "precision" test from the previous patch). Another option would be to use the same format used by MS when disassembling shaders, although this seems to be a case where it's worth diverging. > +static void dump_ins(struct d3dx_regstore *rs, struct d3dx_pres_ins *ins) > +{ > + unsigned int i; > + > + TRACE(" %s ", pres_op_info[ins->op].mnem); > + dump_arg(rs, &ins->output, pres_op_info[ins->op].func_all_comps ? 1 : ins->component_count); > + for (i = 0; i < pres_op_info[ins->op].input_count; ++i) > + { > + TRACE(","); With a blank after the comma it would be prettier. There is still some inconsistent formatting (e.g. "== NULL" vs "!", uppercase hexadecimals, cnt vs count). A possible idea to split this patch further: what if you move the addition of (most of) the contents of the various functions in preshader.c to a separate patch? That is, make a patch which adds the various calls to d3dx_create_param_eval(), d3dx_free_param_eval() and similar (i.e. most if not all the changes to effect.c) but only introduces a skeleton implementation of those functions in preshader.c. Those are actually fleshed out only in the next patch. Many of the new preshader-related definitions can probably also go into the second patch. The traces of the disassembled preshader can also potentially go to a separate patch (leaving only dump_shader_bytecode() in the initial implementation - btw, I think it should be called dump_preshader_bytecode() given the renaming of the other stuff).

2 2

Re: [tools 1/2] Handle "midl_pragma warning" statement in parser
by Nikolay Sivov March 22, 2016

March 22, 2016

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?

1 0

Re: [PATCH 1/6] ddraw/tests: Rewrite blt_test().
by Marvin March 22, 2016

March 22, 2016

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}.

1 0

Student interested in GSoC 2016 implementing D3DX9 API idea
by Xu Zhao March 22, 2016

March 22, 2016

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! 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? Thank you! Regards, - Xu -- Xu Zhao i(a)xuzhao.net

2 2

Server Downtime 2016-03-16 19:00 CDT
by Jeremy Newman March 22, 2016

March 22, 2016

WineHQ.org and all related websites will be offline for maintenance and upgrades on 2016-03-16 starting at 19:00 CDT. This downtime should last 1-2 hours. Some websites may remain offline longer if they need additional work. I'll reply to this post when everything looks to be back online. -N

4 6

Re: [PATCH 2/6] ddraw/tests: Get rid of the unused "d3d" variable in test_shademode().
by Marvin March 22, 2016

March 22, 2016

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}.

1 0

Re: [PATCH] vulkan-icd: Add stub dll.
by Roderick Colenbrander March 22, 2016

March 22, 2016

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 On Mon, Mar 21, 2016 at 8:26 PM, Gabríel Arthúr Pétursson <gabriel(a)system.is> wrote: > Signed-off-by: Gabríel Arthúr Pétursson <gabriel(a)system.is> > --- > configure.ac | 1 + > dlls/vulkan-icd/Makefile.in | 2 ++ > dlls/vulkan-icd/vulkan-icd.spec | 1 + > 3 files changed, 4 insertions(+) > create mode 100644 dlls/vulkan-icd/Makefile.in > create mode 100644 dlls/vulkan-icd/vulkan-icd.spec > > diff --git a/configure.ac b/configure.ac > index 77c54c8..04ddb54 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -3310,6 +3310,7 @@ WINE_CONFIG_DLL(vnbt.vxd,enable_win16) > WINE_CONFIG_DLL(vnetbios.vxd,enable_win16) > WINE_CONFIG_DLL(vssapi) > WINE_CONFIG_DLL(vtdapi.vxd,enable_win16) > +WINE_CONFIG_DLL(vulkan-icd,,[implib]) > WINE_CONFIG_DLL(vwin32.vxd,enable_win16) > WINE_CONFIG_DLL(w32skrnl,enable_win16) > WINE_CONFIG_DLL(w32sys.dll16,enable_win16) > diff --git a/dlls/vulkan-icd/Makefile.in b/dlls/vulkan-icd/Makefile.in > new file mode 100644 > index 0000000..c41bf8f > --- /dev/null > +++ b/dlls/vulkan-icd/Makefile.in > @@ -0,0 +1,2 @@ > +MODULE = vulkan-icd.dll > +IMPORTLIB = vulkan-icd > diff --git a/dlls/vulkan-icd/vulkan-icd.spec b/dlls/vulkan-icd/vulkan-icd.spec > new file mode 100644 > index 0000000..db3616e > --- /dev/null > +++ b/dlls/vulkan-icd/vulkan-icd.spec > @@ -0,0 +1 @@ > +@ stub vk_icdGetInstanceProcAddr > -- > 2.7.0 > > >

2 3

Re: services: Make release_process() static.
by Sebastian Lackner March 22, 2016

March 22, 2016

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.

1 0

Re: [PATCH 2/2] ddraw/tests: Use SetRect() instead of open coding it.
by Marvin March 22, 2016

March 22, 2016

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

2 1

Failing mshtml:xmlhttprequest test
by Francois Gouget March 22, 2016

March 22, 2016

Since the WineHQ.org upgrade the mshtml:xmlhttprequest test has been failing on all platforms: xmlhttprequest.c:448: Test failed: Expect Server: Apache, got L"Apache/2.4.10 (Debian)" Due to: 583 static const struct HEADER_TYPE expect_headers[] = { 584 {"Server", "Apache"}, 585 {"Accept-Ranges", "bytes"}, Fixing the failure is easy, but maybe the test should be more flexible? It could be annoying to have to upgrade it with each minor server upgrade. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.

2 1

Re: [PATCH 1/2] ddraw/tests: Fix copy&paste errors in open coded SetRect()
by Marvin March 22, 2016

March 22, 2016

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=21570 Your paranoid android. === w8 (32 bit visual) === visual.c:1486: 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:1486: 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:1486: Test failed: unexpected colortable on offscreen surface

2 1

Re: [PATCH] msctf/tests: Fix a crash on unsupported interface
by Marvin March 22, 2016

March 22, 2016

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=21569 Your paranoid android. === w864 (32 bit inputprocessor) === inputprocessor.c:787: Test failed: Deactivation came unexpectedly === w1064 (64 bit inputprocessor) === inputprocessor.c:787: Test failed: Deactivation came unexpectedly

1 0

Re: [PATCH 2/2] msctf: Added stub ITextStoreACPServices support for context ITextStoreACPSink
by Marvin March 22, 2016

March 22, 2016

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=21563 Your paranoid android. === w864 (32 bit inputprocessor) === inputprocessor.c:793: Test failed: Deactivation came unexpectedly

2 1

Re: [PATCH 1/2] d3drm: Move struct d3drm_texture to header for global access.
by Henri Verbeet March 21, 2016

March 21, 2016

On 20 March 2016 at 19:24, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -1038,12 +1029,11 @@ static const struct IDirect3DRMTexture3Vtbl d3drm_texture3_vtbl = > d3drm_texture3_SetValidationCallback, > }; > > -HRESULT Direct3DRMTexture_create(REFIID riid, IUnknown **out) > +HRESULT d3drm_texture_create(struct d3drm_texture **texture) > { > struct d3drm_texture *object; > - HRESULT hr; > > - TRACE("riid %s, out %p.\n", debugstr_guid(riid), out); > + TRACE("out %p.\n", texture); You'll also want to fix the TRACE message here.

2 1

Re: [PATCH] include: Use fixed stack size for rbtree.
by Henri Verbeet March 21, 2016

March 21, 2016

On 20 March 2016 at 21:05, Gabríel Arthúr Pétursson <gabriel(a)system.is> wrote: > struct wine_rb_stack > { > - struct wine_rb_entry ***entries; > size_t count; > - size_t size; > + struct wine_rb_entry **entries[2 * sizeof(void *) * 8]; > }; Why do you think this is a good idea?

4 12

Re: shell32: Don't return argified string in FindExecutable
by Alexandre Julliard March 21, 2016

March 21, 2016

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -698,10 +698,15 @@ static UINT SHELL_FindExecutable(LPCWSTR lpPath, LPCWSTR lpFile, LPCWSTR lpVerb, > > if (retval > 32) > { > - DWORD finishedLen; > - SHELL_ArgifyW(lpResult, resultLen, command, xlpFile, pidl, args, &finishedLen); > - if (finishedLen > resultLen) > - ERR("Argify buffer not large enough.. truncated\n"); > + if (exec_only) > + lstrcpynW(lpResult, command, resultLen); > + else > + { > + DWORD finishedLen; > + SHELL_ArgifyW(lpResult, resultLen, command, xlpFile, pidl, args, &finishedLen); > + if (finishedLen > resultLen) > + ERR("Argify buffer not large enough.. truncated\n"); > + } That's not much of an improvement, and I don't see why it should be limited to FindExecutable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: bcrypt: Added BCryptHash function.
by Hans Leidekker March 21, 2016

March 21, 2016

On Fri, 2016-03-18 at 09:26 -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_ALG_HANDLE handle; This should be BCRYPT_HASH_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) > + { > + goto cleanup_bcrypt_hash; > + } There's no need for cleanup here. > + status = BCryptHashData( handle, input, inputlen, 0 ); > + if (status != STATUS_SUCCESS) > + { > + goto cleanup_bcrypt_hash; > + } >+ > + status = BCryptFinishHash( handle, output, outputlen, 0 ); > + if (status != STATUS_SUCCESS) > + { > + goto cleanup_bcrypt_hash; > + } > + > + return BCryptDestroyHash( handle ); > + > +cleanup_bcrypt_hash: > + > + BCryptDestroyHash( handle ); > + > + return status; > +} I don't think this goto is better than repeated BCryptDestroyHash calls.

1 0

Re: [v4 3/6] d3dx9: implement fxlc constants (expressions) in effect.
by Matteo Bruni March 21, 2016

March 21, 2016

2016-03-17 12:59 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -2616,7 +2630,7 @@ static void d3dx9_set_material_parameter(enum MATERIAL_TYPE op, D3DMATERIAL9 *ma > D3DCOLORVALUE c = *(D3DCOLORVALUE *)value; > > TRACE("%s, value (%f %f %f %f).\n", material_tbl[op].name, c.r, c.g, c.b, c.a); > - *(D3DCOLORVALUE *)((char *)material + material_tbl[op].offset) = c; > + *(D3DCOLORVALUE *)((BYTE *)material + material_tbl[op].offset) = c; > break; > } > default: While you're at it, you could change the format strings to use %.8e for the float values. > +static void regstore_reset_table(struct d3dx_regstore *rs, unsigned int table) > +{ > + unsigned int sz; > + > + sz = rs->table_sizes[table] * table_info[table].reg_component_count * table_info[table].component_size; > + > + memset(rs->tables[table], 0, sz); > + memset(rs->table_value_set[table], 0, > + sizeof(*rs->table_value_set[table]) * > + ((rs->table_sizes[table] + PRES_VS_BITS_PER_WORD - 1) / PRES_VS_BITS_PER_WORD)); > +} This function is unused and the compiler should throw a warning about it. > + rs->table_value_set[table][reg_idx / PRES_VS_BITS_PER_WORD] |= > + 1 << (reg_idx % PRES_VS_BITS_PER_WORD); That should be "1u", otherwise here shifting by 31 is technically undefined behavior and there are some compilers that complain about it. The line continuation is also misindented. > + while (param->member_count && param->element_count) > + { > + if (param->element_count > 1) > + { > + FIXME("Unexpected param having both elements and members.\n"); > + return D3DERR_INVALIDCALL; > + } > + param = &param->members[0]; > + } I don't quite understand what you're trying to do here but it doesn't look right. > + TRACE("%s rows %u, par columns %u, par class %u, par flags %u, par bytes %u, c rows %u," \ > + "c columns %u, c class %u, c bytes %u, transpose %u.\n", > + desc.Name, param->rows, param->columns, param->class, param->flags, param->bytes, > + desc.Rows, desc.Columns, desc.Class, desc.Bytes, transpose); I would make two separate TRACEs for parameter and constant info. Also the string comes from the application so you should use debugstr_a(). Something like: TRACE("Constant %s rows %u, columns %u, class %u, bytes %u.\n", debugstr_a(desc.Name), desc.Rows, desc.Columns, desc.Class, desc.Bytes); TRACE("Parameter rows %u, columns %u, class %u, flags %#x, bytes %u, transpose %#x.\n", param->rows, param->columns, param->class, param->flags, param->bytes, transpose); Gmail will probably mangle the code but you get the point.

2 2

Wine fonts
by Jens Reyer March 21, 2016

March 21, 2016

Hi, I'm currently working on the correct Debian packaging of the fonts. Afaik vanilla wine installs the following ttf-fonts: marlett.ttf symbol.ttf tahomabd.ttf tahoma.ttf wingding.ttf I realize that these are indeed necessary for the fon-fonts to display correctly. However in the source there are additionally the following ttf: courier.ttf fixedsys_jp.ttf fixedsys.ttf ms_sans_serif.ttf small_fonts_jp.ttf small_fonts.ttf system.ttf Shouldn't these be installed, too? I haven't noted any difference, but that could be because I don't know how to test this. Can anybody with more knowledge enlighten me? Thanks in advance! jre

2 1

Re: winscard: add stubs for SCardListReadersA/W (try 4)
by Nikolay Sivov March 21, 2016

March 21, 2016

Spec file needs fixing too.

1 0

Re: winscard: add stubs for SCardListReadersA/W (try 3)
by Nikolay Sivov March 21, 2016

March 21, 2016

> +LONG WINAPI SCardListReadersA(SCARDCONTEXT context, const CHAR *groups, char *readers, DWORD *buflen) > +{ > + FIXME("(%lx, %s, %s, %p) stub\n", context, debugstr_a(groups), debugstr_a(readers), buflen); > + return SCARD_F_INTERNAL_ERROR; > +} > + > +LONG WINAPI SCardListReadersW(SCARDCONTEXT context, const WCHAR *groups, WCHAR *readers, DWORD *buflen) > +{ > + FIXME("(%lx, %s, %s, %p) stub\n", context, debugstr_w(groups), debugstr_w(readers), buflen); > + return SCARD_F_INTERNAL_ERROR; > +} 'readers' is an out buffer.

1 0