October 2015 - Wine-devel - list.winehq.org

Re: quartz: Add stub IAMStreamSelect to MPEG-1 Stream Splitter. (try 3)
by Nikolay Sivov 28 Oct '15

28 Oct '15

On 22.10.2015 19:54, Anton Baskanov wrote: > Signed-off-by: Anton Baskanov <baskanov(a)gmail.com> > > Fixes crash on in-game video playback in Earth 2150. > > try3: > - better function parameter names > - replaced 'LPVOID' with 'void *' > - renamed StreamSelect_* functions to AMStreamSelect_* > - renamed StreamSelect_Vtbl to AMStreamSelectVtbl > - replaced 'if' with 'else if' in the QueryInterface function > --- > dlls/quartz/mpegsplit.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++- > include/axcore.idl | 39 +++++++++++++++++++ > 2 files changed, 137 insertions(+), 1 deletion(-) > This looks fine to me. I don't know why it's stuck in a queue, maybe it makes sense to add a simple test that only checks if IAMStreamSelect is supported for this filter?

1 0

Re: [RFC PATCH v2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.
by Martin Storsjö 28 Oct '15

28 Oct '15

On Tue, 20 Oct 2015, Martin Storsjo wrote: > Since MSVC 2015/Windows 10, the C runtime has now been split into two > parts, ucrtbase, which is the generic C runtime which is now considered > a system component, and vcruntimeX which is specific to the compiler > version. > > This DLL is built using only a small subset of the msvcrt source > files. In particular, the DLL should not use most of the global > CRT state as a normal msvcrt carries - the only TLS state handled > is for exceptions. > > The functions in main.c are simplified versions of the corresponding > ones from msvcrt. Additionally, two stub functions (relating to telemetry) > are added; they are required for a plain empty exe built with MSVC 2015 > with dynamic C runtime to start up with the builtin vcruntime140.dll. > > Some functions that are available in the full msvcrt, that vcruntime140.dll > should export, are not included since they haven't been split off to be > buildable without the full internals of msvcrt yet. Those functions are: > _CxxThrowException > __AdjustPointer > __RTCastToVoid > __RTDynamicCast > __RTtypeid > _chkesp > _get_unexpected > > Signed-off-by: Martin Storsjo <martin(a)martin.st> > --- > Changed since last version: Moved main-vcruntime.c to the vcruntime140 > directory; skipped the separate memory.c and included all of it in the > vcruntime main.c instead. Removed a leftover commented out statement. > > In this build configuration, some functions use simpler error handling > - instead of calling _amsg_exit, it calls ExitProcess directly. > (_amsg_exit checks the error mode, which is state that lives within > ucrtbase.dll; vcruntime140.dll shouldn't have a separate copy of that > state, and there's no function in ucrtbase.dll that would allow quering it.) > --- > configure.ac | 1 + > dlls/msvcrt/except.c | 4 + > dlls/msvcrt/except_i386.c | 4 + > dlls/vcruntime140/Makefile.in | 12 ++ > dlls/vcruntime140/main.c | 224 ++++++++++++++++++++++++++++++++++++ > dlls/vcruntime140/vcruntime140.spec | 87 ++++++++++++++ > 6 files changed, 332 insertions(+) > create mode 100644 dlls/vcruntime140/Makefile.in > create mode 100644 dlls/vcruntime140/main.c > create mode 100644 dlls/vcruntime140/vcruntime140.spec Piotr asked whether this would make sense as a DLL that only forwards calls down to ucrtbase, instead of a standalone DLL that duplicates the implementation. For i386, this DLL has got 81 exported functions, and all of those except a few do exist in ucrtbase.dll. The ones that are unique to vcruntime140.dll are the following: __C_specific_handler_noexcept __std_terminate __telemetry_main_invoke_trigger __telemetry_main_return_trigger __uncaught_exceptions __vcrt_GetModuleFileNameW __vcrt_GetModuleHandleW __vcrt_InitializeCriticalSectionEx __vcrt_LoadLibraryExW Out of these, the telemetry ones actually are called implicitly even in a plain hello world executable built with MSVC 2015 (but having them as empty stubs seems to work fine so far), the other ones I haven't had reason to look into yet. The real vcruntime140.dll actually also do some calls to ucrtbase.dll (linked via the api-ms-win-crt-* stub dlls), but not all the real functions - it only links to the following ones: terminate abort strcpy_s malloc _free_base free _malloc_base _calloc_base __stdio_common_vsprintf_s atol (Additionally it links to a few symbols from kernel32.dll and one from advapi32.dll.) Given this, I still think this DLL makes sense as a standalone DLL instead of just a stub forwarding to ucrtbase, since that's what the original one does as well. At worst some of the functions may need to have subtly different behaviour in different versions (which I guess is the main reason for the DLL existing in the first place). // Martin

2 2

Re: [PATCH 5/5] kernel32/tests: Add tests for GetConsoleFontSize (v2)
by Marvin 28 Oct '15

28 Oct '15

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

2 1

Re: [PATCH v3] ucrtbase: Implement some printf functions
by Piotr Caban 27 Oct '15

27 Oct '15

Hi, On 10/26/15 16:53, Martin Storsjo wrote: > --- a/dlls/msvcrt/printf.h > +++ b/dlls/msvcrt/printf.h > +static int FUNC_NAME(puts_clbk_str_c99)(void *ctx, int len, const APICHAR *str) I think that it would be nicer if this function is added in wcs.c. Other callback functions are already added to files that uses them (e.g. file.c defines callbacks for functions printing to files). > /********************************************************************* > + * __stdio_common_vsprintf (MSVCRT.@) > + */ > +int CDECL MSVCRT__stdio_common_vsprintf( unsigned __int64 options, char *str, MSVCRT_size_t len, const char *format, > + MSVCRT__locale_t locale, __ms_va_list valist ) > +{ > + static const char nullbyte = '\0'; > + struct _str_ctx_a ctx = {len, str}; > + int ret; > + > + ret = pf_printf_a(options & 2 ? puts_clbk_str_c99_a : puts_clbk_str_a, > + &ctx, format, locale, FALSE, FALSE, arg_clbk_valist, NULL, &valist); Is there any guarantee that options can only equal 1 or 2? If not please add a FIXME for other values. Thanks, Piotr

2 3

Re: [PATCH 01/4] msvcp110: Add tr2_sys__Open_dir implementation.(try 3)
by Piotr Caban 27 Oct '15

27 Oct '15

Hi, I've missed one more thing in last review. On 10/27/15 07:18, YongHao Hu wrote: > + strcat(temppath, "\\*.*"); Probably the search pattern should be "\\*". Thanks, Piotr

1 0

Re: [PATCH 01/4] msvcp110: Add tr2_sys__Open_dir implementation.(try 3)
by Piotr Caban 27 Oct '15

27 Oct '15

On 10/27/15 07:18, YongHao Hu wrote: > + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), err_code, type); target is an output parameter, it contains garbage on call. Please display it as pointer in trace message. Thanks, Piotr

1 0

Re: [PATCH 02/4] msvcp110: Add tr2_sys__Read_dir implementation.(resend)
by Piotr Caban 27 Oct '15

27 Oct '15

On 10/27/15 07:19, YongHao Hu wrote: > + if(!FindNextFileA(handle, &data)) { > + *type = status_unknown; > + return (char*)""; > + } This looks wrong. You should probably set target to "" and return pointer to it. Thanks, Piotr

1 0

Re: [PATCH 04/4] msvcp120/tests: Add tests of tr2_sys__Open_dir, tr2_sys__Read_dir and tr2_sys__Close_dir.(try 3)
by Piotr Caban 27 Oct '15

27 Oct '15

Hi, the tests are failing here: fixme:file:CreateSymbolicLinkA ("tr2_test_dir/f1_link" "tr2_test_dir/f1" 0): stub fixme:file:CreateSymbolicLinkA ("tr2_test_dir/dir_link" "tr2_test_dir" 1): stub msvcp120.c:1179: Test failed: tr2_sys__Open_dir(): expect: regular_file, got 3 Makefile:159: recipe for target 'msvcp120.ok' failed make: *** [msvcp120.ok] Error 1 The tests should not depend on read order of files inside a directory. The patch is also causing compilation warning when 64-bit wine is compiled: ../../../../wine_src/dlls/msvcp120/tests/msvcp120.c: In function 'test_tr2_sys__dir_operation': ../../../../wine_src/dlls/msvcp120/tests/msvcp120.c:1162:5: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t' [-Wformat=] ok(strlen(longer_path) == MAX_PATH, "tr2_sys__Open_dir(): expect MAX_PATH, got %d\n", strlen(longer_path)); Thanks, Piotr

1 0

Re: [v3 signed 4/6] wined3d: introduce a new wined3d_rendertarget_view_create_from_sub_resource function
by Henri Verbeet 27 Oct '15

27 Oct '15

On 22 October 2015 at 12:01, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > +HRESULT __cdecl wined3d_rendertarget_view_create_from_sub_resource(struct wined3d_texture *texture, Just use CDECL here. include/wine/wined3d.h should actually use CDECL as well, but currently uses __cdecl for historic reasons. > + sub_resource = wined3d_texture_get_sub_resource(texture, sub_resource_idx); > + surface = surface_from_resource(sub_resource); You can't assume the sub-resource is a surface here.

2 1

Re: [v3 signed 3/6] wined3d: introduce new wined3d_texture_{get, release}_dc functions
by Henri Verbeet 27 Oct '15

27 Oct '15

On 22 October 2015 at 12:01, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > +HRESULT CDECL wined3d_texture_get_dc(struct wined3d_texture *texture, unsigned int sub_resource_idx, HDC *dc) > +{ > + struct wined3d_resource *sub_resource = wined3d_texture_get_sub_resource(texture, sub_resource_idx); > + > + return wined3d_surface_getdc(surface_from_resource(sub_resource), dc); > +} I think this should be fairly obvious at this point, but you're missing traces and you need to validate the sub-resource type.

2 1