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

Re: [PATCH] server: Implement serial port read interval timeouts.
by Alexandre Julliard Jan. 21, 2016

Jan. 21, 2016

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Fixes https://bugs.winehq.org/show_bug.cgi?id=39875 > > There is a test program attached to the bug report. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > server/async.c | 13 +++++++++++++ > server/fd.c | 6 ++++++ > server/file.h | 2 ++ > server/serial.c | 3 +++ > 4 files changed, 24 insertions(+) That's a good start, but I think you should be able to do it through the reselect_async fd operation, without making changes to the generic async code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] ddraw/tests: Port test_lockrect_invalid to other versions (v2).
by Marvin Jan. 21, 2016

Jan. 21, 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=19863 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2523: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2338: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit dsurface) === dsurface.c:144: Test failed: Destination data after blitting is not correct dsurface.c:178: Test failed: Destination data after blitting is not correct dsurface.c:357: Test failed: Surface data after srckey blit does not match dsurface.c:382: Test failed: Surface data after src override key blit does not match dsurface.c:436: Test failed: Surface data after dest key blit does not match dsurface.c:462: Test failed: Surface data after dest key override blit does not match dsurface.c:524: Test failed: Surface data with src key and dest key blit does not match === w1064 (32 bit ddraw1) === ddraw1.c:2187: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: Updated WineHQ.org
by Theodore Dubois Jan. 20, 2016

Jan. 20, 2016

You are allowed to use table layout (i.e: display: table, display: table-cell, etc.) Just not <table> tags. ~Theodore > On Jan 20, 2016, at 11:53 AM, Jeremy Newman <jnewman(a)codeweavers.com> wrote: > > This is why I miss using tables for HTML layout. This kind of problem was easy to solve with tables. But Nooooo tables are bad now. :-| > > I only applied my resize handler to the right side. I could apply it to the left side as well, but I think that will cause issues as the two sides fight over who should be the correct height. > > On 01/20/2016 01:44 PM, Ruslan Kabatsayev wrote: >> On Wed, Jan 20, 2016 at 10:19 PM, Jeremy Newman <jnewman(a)codeweavers.com> wrote: >>> On 01/20/2016 12:10 AM, Ruslan Kabatsayev wrote: >>>> >>>> Current version makes the Download/Support/Development/Donate block >>>> have twice the needed height with my 782px wide Chromium window, i.e. >>>> has empty space under the links. >>> >>> >>> This is by design. I added some jquery-fu to make sure that box was the same >>> height as the two boxes to the left of it. I think this looks better than a >>> larger empty black space under it. >>> >>> I do notice that at that width that the Development link does get a bit too >>> close to the edge of the box. Perhaps I should shrink down the font size by >>> a couple of px. >> >> OK, that thing was due my too old Chromium, it appears not >> reproducible with current versions. >> >> The jquery-fu though seems to not always work, namely with zoomed out >> page, see "zoomed" attachment (zoom is 50% there). This remains true >> with up-to-date Chromium and Firefox. >> >>> >>> -N > >

1 0

Updated WineHQ.org
by Jeremy Newman Jan. 20, 2016

Jan. 20, 2016

I have updated the WineHQ.org main website with a new mobile friendly (bootstrap based) theme. The goal was the preserve the old look somewhat, while bringing it up to modern standards. I've ported most of the existing translations for the home page. Sub-pages will need to be updated. Translators, please update your sub-pages. Please update download.template first. -N

3 6

WWN?
by André Hentschel Jan. 20, 2016

Jan. 20, 2016

Hi, As you might have noticed, I lost time and motivation to do WWN. Someone out there to continue it? Then I would cleanup the tools for it and guide her/him into using them.

1 0

Re: [PATCH 1/2] d3drm: Fix QueryInterface for IDirect3DRMTexture* (v2).
by Henri Verbeet Jan. 20, 2016

Jan. 20, 2016

On 19 January 2016 at 15:29, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > WARN("%s not implemented, returning E_NOINTERFACE.\n", debugstr_guid(riid)); > - return E_NOINTERFACE; > + return CLASS_E_CLASSNOTAVAILABLE; I missed this in the original patch as well, but now the message doesn't match the return value. These two patches seem fine otherwise.

2 1

Re: [2/2] comctl32: Don't update the status if the item is no longer valid.
by Nikolay Sivov Jan. 20, 2016

Jan. 20, 2016

On 19.01.2016 17:45, Akihiro Sagawa wrote: > > This fixes https://bugs.winehq.org/show_bug.cgi?id=39677 > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/comctl32/listview.c | 2 +- > dlls/comctl32/tests/listview.c | 22 ++++++++++++++++++++++ > 2 files changed, 23 insertions(+), 1 deletion(-) > I think this is correct, but to make sure I fully understand what's going on. The idea is to return early from _SetItemT() for the case when old focused item index is larger than current number items in a list? >From reading surrounding code, it looks like application will receive state notifications for item number that's no longer valid, am I right? > + /* The focused item isn't updated after the invalidation */ The opposite is true, focused item is updated in this new test, from 0 to -1 (nothing focused), please fix this comment to reflect that. > comctl32: Don't update the status if the item is no longer valid. Subject needs some adjusting to, something like "Prevent invalid focuse change notifications from LVS_OWNERDATA lists", or similar. Right now it's not clear what 'status' and 'item' mean in this context. Thanks for debugging this.

2 1

Re: [PATCH] ntoskrnl.exe: Implement ZwLoadDriver and ZwUnloadDriver
by Dmitry Timoshkov Jan. 20, 2016

Jan. 20, 2016

Aric Stewart <aric(a)codeweavers.com> wrote: > Code is mostly moved from winedevice.exe > winedevice.exe now uses these functions > > With consultation and help from Damjan Jovanovic This code is broken in so many ways, so I woudn't bother listing them all. -- Dmitry.

2 1

Re: [PATCH] d2d1: Don't update target dpi if only one SetDpi() argument is zero
by Henri Verbeet Jan. 20, 2016

Jan. 20, 2016

On 19 January 2016 at 22:43, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > @@ -1436,6 +1436,8 @@ static void STDMETHODCALLTYPE d2d_d3d_render_target_SetDpi(ID2D1RenderTarget *if > dpi_x = 96.0f; > dpi_y = 96.0f; > } > + else if (dpi_x == 0.0f || dpi_y == 0.0f) > + return; > Should this affect rendertarget creation (i.e., d2d_d3d_render_target_init()) as well? What about bitmap creation?

2 1

Re: [PATCH 1/8] wined3d: Do not update surface when empty box is passed.
by Henri Verbeet Jan. 20, 2016

Jan. 20, 2016

On 19 January 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > if (box->left >= box->right || box->right > sub_resource->width > - || box->top >= box->bottom || box->bottom > sub_resource->height) > + || box->top >= box->bottom || box->bottom > sub_resource->height > + || box->front >= box->back) It seems likely that you'll need to validate box->back against sub_resource->depth as well, although you may need 3D textures for a reliable test.

1 0

Re: [PATCH 1/3] msvcrt: Fix size test of structure returned by _Gettnames
by Marvin Jan. 20, 2016

Jan. 20, 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=19825 Your paranoid android. === w1064 (32 bit locale) === locale.c:461: Test failed: ret = Norwegian Bokmål_Norway.1252 locale.c:468: Test failed: ret = Norwegian Bokmål_Norway.1252

2 1

Re: winspool.drv: add EnumPrinterKeyA/W stubs (try 2)
by Huw Davies Jan. 20, 2016

Jan. 20, 2016

On Tue, Jan 19, 2016 at 03:45:32PM -0600, Austin English wrote: > diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c > index 04def86..06fa2a2 100644 > --- a/dlls/winspool.drv/info.c > +++ b/dlls/winspool.drv/info.c > @@ -7527,6 +7527,26 @@ DWORD WINAPI EnumPrinterDataW( HANDLE hPrinter, DWORD dwIndex, LPWSTR pValueName > } > > /***************************************************************************** > + * EnumPrinterKeyA [WINSPOOL.@] > + * > + */ > +DWORD WINAPI EnumPrinterKeyA(HANDLE printer, const CHAR *key, CHAR *subkey, DWORD size, DWORD *ret) 'needed' is probably better than 'ret'. > +{ > + FIXME("%p %s %s %x %p\n", printer, debugstr_a(key), debugstr_a(subkey), size, ret); subkey is an [out] param, so just print the ptr. Same goes for the spec file. Huw.

1 0

Re: hidclass.sys: Properly quit hid_device_thread when both completion event and halt event are signaled (try 3)
by Aric Stewart Jan. 20, 2016

Jan. 20, 2016

Sorry for the late reply, I have lost this e-mail as well. + rc = WaitForSingleObject(ext->halt_event, 0) You appear to be missing a ; This does not compile. did you even test that before sending in the patch? Otherwise the patch looks fine. -aric

2 1

Re: [2/2] shell32/tests: Call okShell() after a shell_execute{_ex}() test.
by Marvin Jan. 20, 2016

Jan. 20, 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=19814 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2333: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt206D.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt206D.tmp\test file.sde")]' shlexec.c:2321: Test failed: failed: rc=29 err=2 shlexec.c:2321: Test failed: failed: rc=29 err=2

1 0

Re: [1/2] shell32/tests: Trace the last ShellExecute command whenever a corresponding test fails.
by Marvin Jan. 20, 2016

Jan. 20, 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=19813 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2340: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde")]' shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF1B.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1298.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1298.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1298.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2328: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1298.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: [PATCH v2] ole32: The type of the size of IMalloc'ed blocks is SIZE_T.
by Alexandre Julliard Jan. 19, 2016

Jan. 19, 2016

Huw Davies <huw(a)codeweavers.com> writes: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/ole32/ifs.c | 48 +++++++++++++++++++++++++----------------------- > include/objbase.h | 4 ++-- > include/objidl.idl | 18 +++++++++--------- > 3 files changed, 36 insertions(+), 34 deletions(-) There are more interfaces like IMimeAllocator that derive from IMalloc that need fixing too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ole32: The type of the size of IMalloc'ed blocks is SIZE_T.
by Dmitry Timoshkov Jan. 19, 2016

Jan. 19, 2016

Huw Davies <huw(a)codeweavers.com> wrote: > -static HRESULT WINAPI IMalloc_fnQueryInterface(LPMALLOC iface,REFIID refiid,LPVOID *obj) { > - > +static HRESULT WINAPI IMalloc_fnQueryInterface(LPMALLOC iface,REFIID refiid,LPVOID *obj) > +{ Since basically every method entry is being changed, why not get rid of LPMALLOC as well? -- Dmitry.

2 1

Re: [PATCH 2/3] winex11: Don't recompute string length in remove_startup_notification.
by Alexandre Julliard Jan. 19, 2016

Jan. 19, 2016

Alex Henrie <alexhenrie24(a)gmail.com> writes: > The string length was computed during the loop earlier in the function. > There is no need to call the O(n) strlen function to compute it again. Saving a couple of cycles in a function that is executed at most once is irrelevant, and not worth the code churn. Please avoid such "optimizations". -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] winebuild: Added support for entry points generated in runtime.
by Sebastian Lackner Jan. 19, 2016

Jan. 19, 2016

On 19.01.2016 12:20, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > tools/winebuild/build.h | 1 + > tools/winebuild/parser.c | 1 + > tools/winebuild/spec32.c | 59 > ++++++++++++++++++++++++++++++++++++++++ > tools/winebuild/winebuild.man.in | 3 ++ > 4 files changed, 64 insertions(+) > > > > 0001-winebuild-Added-support-for-entry-points-generated-in.diff > > > diff --git a/tools/winebuild/build.h b/tools/winebuild/build.h > index e32e7a9..2d5a162 100644 > --- a/tools/winebuild/build.h > +++ b/tools/winebuild/build.h > @@ -171,6 +171,7 @@ struct strarray > #define FLAG_REGISTER 0x10 /* use register calling convention */ > #define FLAG_PRIVATE 0x20 /* function is private (cannot be imported) */ > #define FLAG_ORDINAL 0x40 /* function should be imported by ordinal */ > +#define FLAG_JIT 0x80 /* function is generated at runtime */ > > #define FLAG_FORWARD 0x100 /* function is a forwarded name */ > #define FLAG_EXT_LINK 0x200 /* function links to an external symbol */ > diff --git a/tools/winebuild/parser.c b/tools/winebuild/parser.c > index 1d7b84e..c42fceb 100644 > --- a/tools/winebuild/parser.c > +++ b/tools/winebuild/parser.c > @@ -69,6 +69,7 @@ static const char * const FlagNames[] = > "register", /* FLAG_REGISTER */ > "private", /* FLAG_PRIVATE */ > "ordinal", /* FLAG_ORDINAL */ > + "jit", /* FLAG_JIT */ > NULL > }; > > diff --git a/tools/winebuild/spec32.c b/tools/winebuild/spec32.c > index cb56abe..ebce6b4 100644 > --- a/tools/winebuild/spec32.c > +++ b/tools/winebuild/spec32.c > @@ -270,6 +270,60 @@ static void output_relay_debug( DLLSPEC *spec ) > } > } > > +static void output_jit_descs( DLLSPEC *spec ) > +{ > + int i, emited_descs = 0, jit_cnt = 0; No native english speaker here, but shouldn't it be "emitted" ? > + char **jit_entries, *sym_name; > + ORDDEF *odp; > + > + if (target_cpu != CPU_x86) > + return; > + > + for (odp = spec->entry_points; odp < spec->entry_points + spec->nb_entry_points; odp++) > + if (odp->flags & FLAG_JIT) > + jit_cnt++; This code should probably ignore spec entries with FLAG_FORWARD. Generating thunks wouldn't make sense then. Also, winebuild should probably complain when non-stdcall functions use -jit. > + if (!jit_cnt) > + return; > + > + jit_entries = xmalloc( jit_cnt*sizeof(*jit_entries) ); > + > + output( "\t.data\n" ); > + output( "%s\n", asm_globl("__wine_jit_descs") ); > + > + for (odp = spec->entry_points; odp < spec->entry_points + spec->nb_entry_points; odp++) { Minor issue, but coding style in winebuild usually has "{" on the next line. There are a couple more minor style issues in the next lines, like missing space inbetween of "(...)" and arguments. > + if (!(odp->flags & FLAG_JIT)) > + continue; > + > + for (i=0; i < emited_descs; i++) { > + if (!strcmp(odp->link_name, jit_entries[i])) > + break; > + } > + if (i < emited_descs) > + continue; /* already emited */ > + jit_entries[emited_descs] = odp->link_name; > + > + output( "\t%s %s\n", get_asm_ptr_keyword(), asm_name(odp->link_name) ); > + output( "\t.long %u\n", get_args_size(odp) ); > + emited_descs++; > + } > + > + output( "\t%s 0\n", get_asm_ptr_keyword() ); > + output( "\t.long 0\n" ); You should use .previous here to restore the previous section. > + > + output("\t.text\n" ); > + output( "%s\n", asm_globl("__wine_jit_entries") ); > + > + for (i=0; i < emited_descs; i++) { > + sym_name = strmake( "__jit_%s", jit_entries[i] ); > + output( "%s\n", asm_globl(sym_name) ); > + free( sym_name ); > + > + output( "\t.long 0\n\t.long 0\n\t.long 0\n\t.long 0\n" ); You might want to to emit .cfi_startproc and .cgi_endproc CFI directives here, to ensure debuggers and unwinding code can split it into separate functions. Also, you might want to use output_function_size(). > + } Same as above, you should add a ".restore" here. > + > + free(jit_entries); > +} > + > /******************************************************************* > * output_exports > * > @@ -332,6 +386,10 @@ void output_exports( DLLSPEC *spec ) > output( "\t%s %s_%s\n", > get_asm_ptr_keyword(), asm_name("__wine_spec_ext_link"), odp->link_name ); > } > + else if (target_cpu == CPU_x86 && (odp->flags & FLAG_JIT)) > + { > + output( "\t%s %s_%s\n", get_asm_ptr_keyword(), asm_name("__jit"), odp->link_name ); > + } > else > { > output( "\t%s %s\n", get_asm_ptr_keyword(), asm_name(odp->link_name) ); > @@ -622,6 +680,7 @@ void BuildSpec32File( DLLSPEC *spec ) > output_stubs( spec ); > output_exports( spec ); > output_imports( spec ); > + output_jit_descs( spec ); > if (is_undefined( "__wine_call_from_regs" )) output_asm_relays(); > output_resources( spec ); > output_gnu_stack_note(); > diff --git a/tools/winebuild/winebuild.man.in b/tools/winebuild/winebuild.man.in > index 2063738..2905bac 100644 > --- a/tools/winebuild/winebuild.man.in > +++ b/tools/winebuild/winebuild.man.in > @@ -299,6 +299,9 @@ accessed through GetProcAddress. > The entry point will be imported by ordinal instead of by name. The > name is still exported. > .TP > +.B -jit > +The function body will be generated in runtime. For internal Wine usage only. > +.TP > .BI -arch= cpu\fR[\fB,\fIcpu\fR] > The entry point is only available on the specified CPU > architecture(s). The names \fBwin32\fR and \fBwin64\fR match all > > >

1 0

Re: [PATCH 1/3] winebuild: Added support for entry points generated in runtime.
by Marcus Meissner Jan. 19, 2016

Jan. 19, 2016

On Tue, Jan 19, 2016 at 12:20:30PM +0100, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> I am curious ... for what is this needed? Ciao, Marcus

2 1

Re: [PATCH] winex11: Avoid inefficiency and overflow in remove_startup_notification.
by Alex Henrie Jan. 19, 2016

Jan. 19, 2016

Could I get some feedback on this patch? I'd rather not have it drop off the list a second time, especially since Vincent already signed off on it: https://www.winehq.org/pipermail/wine-patches/2015-November/144119.html -Alex

2 1

Re: [PATCH 2/2] d3drm/tests: Add QueryInterface tests for IDirect3DRMTexture*.
by Henri Verbeet Jan. 19, 2016

Jan. 19, 2016

On 18 January 2016 at 19:57, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > + char *file = NULL; Why do you initialize this to NULL? > + BOOL check; > + > + > + hr = Direct3DRMCreate(&d3drm1); The extra empty line is weird. Is that intentional? > + file = create_bitmap(1, 1, TRUE); > + hr = IDirect3DRM_LoadTexture(d3drm1, file, &texture1); I think "file" is a bad name. I'd expect that to be a file handle or descriptor, not a string. > + ok(SUCCEEDED(hr), "Failed to load texture (hr = %x).\n", hr); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMTexture interface (hr = %x)\n", hr); This looks like it was leftover from somewhere, but in either case it doesn't test what the message says it's testing. It's fairly harmless here, but %x is a bad format in most cases. E.g., is "1000" decimal 4096 or decimal 1000? Just use %#x. Ideally you'd also use the same message format as the other D3D tests. > + check = DeleteFileA(file); > + ok(check, "Cannot delete image stored in %s (error = %d).\n", file, GetLastError()); > +} You're leaking "file".

2 1

Re: [PATCH 1/2] d3drm: Fix QueryInterface for IDirect3DRMTexture*.
by Henri Verbeet Jan. 19, 2016

Jan. 19, 2016

On 18 January 2016 at 19:57, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > - if (IsEqualGUID(riid, &IID_IDirect3DRMTexture2) > - || IsEqualGUID(riid, &IID_IDirect3DRMTexture) > + if (IsEqualGUID(riid, &IID_IDirect3DRMTexture) > + || IsEqualGUID(riid, &IID_IDirect3DRMVisual) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > || IsEqualGUID(riid, &IID_IUnknown)) > { > + *out = &texture->IDirect3DRMTexture_iface; This isn't necessarily wrong, but it does seem weird. You return &texture->IDirect3DRMTexture_iface here for e.g. IUnknown, but the implementation then forwards to &texture->IDirect3DRMTexture3_iface. It seems more logical to return the IDirect3DRMTexture3 interface here directly. We also tend to check the "newest" IID first, in D3D code at least. I.e., IID_IDirect3DRMTexture3 before IID_IDirect3DRMTexture.

2 1

Re: winspool.drv: add EnumPrinterKeyA/W stubs
by Dmitry Timoshkov Jan. 19, 2016

Jan. 19, 2016

Austin English <austinenglish(a)gmail.com> wrote: > +DWORD WINAPI EnumPrinterKeyW(HANDLE printer, const WCHAR *key, WCHAR *subkey, DWORD size, DWORD *ret); > +DWORD WINAPI EnumPrinterKeyW(HANDLE printer, const WCHAR *key, WCHAR *subkey, DWORD size, DWORD *ret); > +#define EnumPrinterKey WINELIB_NAME_AW(EnumPrinterKey) This doesn't look right. -- Dmitry.

2 1

Re: [PATCH 5/5] d3d8/tests: Block validation checks the surface size too.
by Marvin Jan. 18, 2016

Jan. 18, 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=19764 Your paranoid android. === w1064 (32 bit device) === device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2618: Test failed: The focus window is active. device.c:2626: Test failed: Got unexpected hr 0x88760869. device.c:2632: Test failed: Got unexpect screen size 800x600. device.c:2647: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2656: Test failed: Got unexpect screen size 800x600. device.c:2669: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2677: Test failed: Got unexpect width 640. device.c:2678: Test failed: Got unexpect height 480.

1 0