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

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