October 2017 - Wine-Devel - list.winehq.org

Re: [v3 PATCH 2/3] gdiplus/metafile: Partially implement EmfPlusImage deserialization
by Nikolay Sivov Oct. 14, 2017

Oct. 14, 2017

On 13.10.2017 19:45, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > v3: fail on indexed formats for now > > dlls/gdiplus/gdiplus_private.h | 1 + > dlls/gdiplus/metafile.c | 82 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 83 insertions(+) > Ignore that one please. Indexed case is trivial enough, I'll send complete version instead.

1 0

Re: [PATCH 1/2] dx8vb: Add D3DX8 coclass plus ID3DX8 interface and its dependencies
by Nikolay Sivov Oct. 14, 2017

Oct. 14, 2017

How exactly this is supposed to work? When you mentioned such dx8-vb style wrappers exist I thought about usual scripting way to create and access them, yet your idls don't define a type library and interface wrappers are not IDispatch descendants. Normal way is to create factory object using ProgID for example, in this case DXD8, and then all method are requested using IDispatch. Also, is it possible to reuse actual dx8 headers for enums and the like ? P.S. for enum members please use hex notation for fourcc values, and FORCE_DWORD things.

2 1

Regression bug in 2.18: Endless Legend broken
by Walter Woods Oct. 14, 2017

Oct. 14, 2017

Hi all, I'm posting to this list as a result of the instructions on the "AppDB Maintainers" page. Anyway, Endless Legend (https://appdb.winehq.org/objectManager.php?sClass= application&iId=16492) was broken somewhere between 2.17-staging and 2.18-staging. While the initial credits videos load alright, the game's own loading splashscreen (for the Tempest expansion) crashes without fail. If I run Wine 2.18-staging in a terminal, the error messages look like this: fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #11: fixme:d3d_shader:print_glsl_info_log Vertex info fixme:d3d_shader:print_glsl_info_log ----------- fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[0].zw" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[1].zw" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[2]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[3]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[4]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[5]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[6]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[7]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[9]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[11]" might be used before being initialized err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols err:seh:setup_exception stack overflow 1600 bytes in thread 0096 eip 000000007bc62c85 esp 00000000053e0fd0 stack 0x53e0000-0x53e1000-0x54e0000 fixme:shell:CustomDestinationList_QueryInterface not implemented for {00000003-0000-0000-c000-000000000046} (unknown) fixme:shell:CustomDestinationList_QueryInterface not implemented for {00000003-0000-0000-c000-000000000046} (unknown) fixme:shell:CustomDestinationList_QueryInterface not implemented for {00000019-0000-0000-c000-000000000046} (unknown) fixme:shell:CustomDestinationList_BeginList 0x5385410 (0x1284e52c {92ca9dcd-5622-4bba-a805-5e9f541bd8c9} 0x1284e538): stub fixme:shell:CustomDestinationList_QueryInterface not implemented for {00000003-0000-0000-c000-000000000046} (unknown) fixme:shell:CustomDestinationList_QueryInterface not implemented for {00000003-0000-0000-c000-000000000046} (unknown) fixme:shell:CustomDestinationList_QueryInterface not implemented for {00000019-0000-0000-c000-000000000046} (unknown) fixme:shell:CustomDestinationList_BeginList 0x5384490 (0x12a4e52c {92ca9dcd-5622-4bba-a805-5e9f541bd8c9} 0x12a4e538): stub If I run Wine 2.17-staging in a terminal, then I get only the following: fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #263: fixme:d3d_shader:print_glsl_info_log Vertex info fixme:d3d_shader:print_glsl_info_log ----------- fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[2].zw" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[3].zw" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[5]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[6]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[7]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[8]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[9]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[10]" might be used before being initialized fixme:d3d_shader:print_glsl_info_log 0(19) : warning C7050: "vs_out[11]" might be used before being initialized So, it seems safe to assume that something in 2.18 causes all of those page faults. Cheers, Walt

2 1

Re: [PATCH] msvcrt: Add vf[w]printf_p & vf[w]printf_p_l.
by Piotr Caban Oct. 13, 2017

Oct. 13, 2017

Hi Gijs, I think support for MSVCRT_PRINTF_POSITIONAL_PARAMS flag may be integrated into helper. Thanks to it you will be able to implement vfprintf_p without changing all helper callers. I'm thinking about something like this: static int vfprintf_helper(DWORD options, MSVCRT_FILE* file, const char *format, MSVCRT__locale_t locale, __ms_va_list valist) { printf_arg args_ctx[MSVCRT__ARGMAX+1]; BOOL tmp_buf; int ret; if(!MSVCRT_CHECK_PMT( file != NULL )) return -1; if(!MSVCRT_CHECK_PMT( format != NULL )) return -1; if(options & MSVCRT_PRINTF_POSITIONAL_PARAMS) { memset(args_ctx, 0, sizeof(args_ctx)); ret = create_positional_ctx_a(args_ctx, format, valist); if(ret < 0) { MSVCRT__invalid_parameter(NULL, NULL, NULL, 0, 0); *MSVCRT__errno() = MSVCRT_EINVAL; return ret; } else if(!ret) otions &= ~MSVCRT_PRINTF_POSITIONAL_PARAMS; } MSVCRT__lock_file(file); tmp_buf = add_std_buffer(file); ret = pf_printf_a(puts_clbk_file_a, file, format, locale, options, options & MSVCRT_PRINTF_POSITIONAL_PARAMS ? arg_clbk_positional : arg_clbk_valist, options & MSVCRT_PRINTF_POSITIONAL_PARAMS ? args_ctx : NULL, &valist); if(tmp_buf) remove_std_buffer(file); MSVCRT__unlock_file(file); return ret; } Thanks, Piotr

2 1

Re: [PATCH] msi: Defer the appropriate standard actions to the install script.
by Hans Leidekker Oct. 13, 2017

Oct. 13, 2017

I get test failures: automation.c:2545: Test failed: Expected ERROR_SUCCESS, got 2 automation.c:2550: Test failed: Expected ERROR_SUCCESS, got 6 automation.c:2551: Test failed: Expected imaname, got H�2 automation.c:2556: Test failed: Expected ERROR_FILE_NOT_FOUND, got 6 automation.c:2561: Test failed: Expected ERROR_SUCCESS, got 6 automation.c:2562: Test failed: Expected 314, got 0 automation.c:2567: Test failed: Expected ERROR_SUCCESS, got 6 automation.c:2568: Test failed: Expected imaname, got H�2 automation.c:2573: Test failed: Expected ERROR_SUCCESS, got 2 Makefile:227: recipe for target 'automation.ok' failed make: *** [automation.ok] Error 9 This is the kind of patch that could use lots of tests, though it looks like you are working on it ;-) It would also be a good idea to check a few real installers, such as those for .NET and Office, if you haven't done so already.

2 1

Re: [v2 PATCH 2/3] gdiplus/metafile: Implement EmfPlusImage deserialization ImageDataTypeBitmap image type
by Vincent Povirk Oct. 13, 2017

Oct. 13, 2017

We should have a FIXME for indexed color formats.

2 2

Re: [PATCH 2/4] msvcp90: Call exception ctor in logic_error and runtime_error ctor.
by Piotr Caban Oct. 13, 2017

Oct. 13, 2017

Hi Daniel, this patch doesn't look right. The runtime_error class is supposed to override "what" virtual function. I'm attaching a simple test case that shows that name field should not be set to passed string (at least in msvcp60). Thanks, Piotr

2 2

Exported functions in tests
by Zebediah Figura Oct. 13, 2017

Oct. 13, 2017

Hello all, I was working on a test for MSI type 1 custom actions, i.e. functions exported from a given DLL and called by the install script. I've tested both with an independent file and in the Wine test environment, and I've found that I can successfully export functions from the executable itself with DECLSPEC_EXPORT, and MSI will successfully execute the function, as the attached patch demonstrates. The function returns ERROR_SUCCESS, and changing this to other values gets reflected in the install's error code appropriately. However, as soon as I add a function call to the custom action, the install fails with ERROR_INSTALL_FAILURE, and the function is never called—making it look, in all probability, like a page fault occurred. This is the case when compiling with mingw-w64, both inside the Wine test environment and in an independent file. Notably I have no trouble calling DLLs taken from real MSI packages in this way. I also have no trouble calling the function if I use GetModuleHandle() and GetProcAddress() directly, nor do I run into any trouble whatsoever running the custom action on Linux. It is specifically this environment—running this function as part of a custom action, on Windows. Does anyone know, or have a hunch, as to what the problem might be here? For what it's worth, it's known that native MSI uses a separate process to execute custom actions, although I don't know how this would lend any clue to what's going wrong. --Zeb

3 5

Re: [PATCH 3/4] msvcp90: Define basic_string for runtime_error when not msvcirt.
by Piotr Caban Oct. 13, 2017

Oct. 13, 2017

Hi Daniel, why do you need it? The class should be not used/exported in msvcirt. Thanks, Piotr

2 4

Re: [PATCH] server_ioctl_file() - Prefix printed hex values with '0x'
by Alexandre Julliard Oct. 12, 2017

Oct. 12, 2017

Chris Morgan <chmorgan(a)gmail.com> writes: > Avoids the ambiguity with non-alphanumeric hex values. > > Signed-off-by: Chris Morgan <chmorgan(a)gmail.com> > --- > dlls/ntdll/file.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index fd7f3dd..4d081b7 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -1567,7 +1567,7 @@ static NTSTATUS server_ioctl_file( HANDLE handle, HANDLE event, > SERVER_END_REQ; > > if (status == STATUS_NOT_SUPPORTED) > - FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n", > + FIXME("Unsupported ioctl 0x%x (device=0x%x access=0x%x func=0x%x method=0x%x)\n", That's mostly a matter of taste, so I don't think it's necessary to change it. -- Alexandre Julliard julliard(a)winehq.org

3 2