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

Re: [1/3] xmllite: Use buffer offset instead of pointers

by Nikolay Sivov

On 10/6/2013 19:06, Nikolay Sivov wrote: > It's normal to grow destination buffer, in this case all stored > pointers will be trashed. This patch uses offsets from start of a > buffer instead. > Hi, Alexandre. Patches list shows a build failure for this one, and I don't see any failures on testbot for it so assuming something it fails on your machine. So what's the exact failure you get?

Oct. 7, 2013

Re: mscoree: Partial implement ICLRMetaHost RequestRuntimeLoadedNotification (try 2)

by Vincent Povirk

HRESULT CLRMetaHost_CreateInstance(REFIID riid, void **ppobj) { + GlobalCLRMetaHost.callback = NULL; return ICLRMetaHost_QueryInterface(&GlobalCLRMetaHost.ICLRMetaHost_iface, riid, ppobj); } I don't think we should be changing global state every time someone creates an instance of this object. We can't assume it only happens once.

Oct. 7, 2013

Re: riched20: Set control content in WM_CREATE message

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/riched20/editor.c | 21 +++++++++++++++++++++ > dlls/riched20/tests/editor.c | 38 ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 59 insertions(+) It doesn't work: ../../../tools/runtest -q -P wine -M riched20.dll -T ../../.. -p riched20_test.exe.so txtsrv.c && touch txtsrv.ok wine: Unhandled page fault on read access to 0x00000024 at address 0x7ac23e94 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000024 in 32-bit code (0x7ac23e94). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ac23e94 ESP:0032f290 EBP:0032fb98 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:7ac58c00 ECX:0032fc80 EDX:003338e8 ESI:003338e8 EDI:00000001 Stack dump: 0x0032f290: 0032fc80 00000000 00000000 00000000 0x0032f2a0: 00000001 00000000 00000000 00333428 0x0032f2b0: 4d430002 00000008 00000004 7bc3c8e3 0x0032f2c0: 00333558 00333550 00000000 7bc3c8e3 0x0032f2d0: 00000780 000004b0 0032f300 6890a34c 0x0032f2e0: 00000000 0000001f 0032f318 688bd210 Backtrace: =>0 0x7ac23e94 ME_HandleMessage+0x32d4(editor=0x3338e8, msg=0x1, wParam=0, lParam=0, unicode=0x1, phresult=0x32fbdc) [/home/julliard/wine/wine/dlls/riched20/editor.c:4029] in riched20 (0x0032fb98) 1 0x7ac3d3ab CreateTextServices+0x11a(pUnkOuter=<couldn't compute location>, pITextHost=<couldn't compute location>, ppUnk=<couldn't compute location>) [/home/julliard/wine/wine/dlls/riched20/txtsrv.c:417] in riched20 (0x0032fbf8) 2 0x686569cb func_txtsrv+0x2fa() [/home/julliard/wine/wine/dlls/riched20/tests/txtsrv.c:864] in riched20_test (0x0032fd38) 3 0x6862a5a7 main+0x386(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/riched20/tests/../../../include/wine/test.h:570] in riched20_test (0x0032fe08) 4 0x68657e30 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in riched20_test (0x0032fe58) 5 0x7b85f36c call_process_entry+0xb() in kernel32 (0x0032fe78) 6 0x7b86054b start_process+0x6a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1085] in kernel32 (0x0032feb8) 7 0x7bc7fe70 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 8 0x7bc82d7d call_thread_func+0x7c(entry=0x7b8604e0, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2602] in ntdll (0x0032ffa8) 9 0x7bc7fe4e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 10 0x7bc54a1e start_process+0x1d(kernel_start=0x7b8604e0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2694] in ntdll (0x0032ffe8) 11 0x6803128d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 12 0x6803134b wine_switch_to_stack+0x2a(func=0x7bc54a00, arg=0x7b8604e0, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xff8b7288) 13 0x7bc5a557 LdrInitializeThunk+0x3a6(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2750] in ntdll (0xff8b72f8) 14 0x7b866ac0 __wine_kernel_init+0xbbf() [/home/julliard/wine/wine/dlls/kernel32/process.c:1257] in kernel32 (0xff8b8208) 15 0x7bc5ac23 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2959] in ntdll (0xff8b8298) 16 0x6802eeda wine_init+0x2b9(argc=0x3, argv=0xff8b87d4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:952] in libwine.so.1 (0xff8b82f8) 17 0x7bf00d3b main+0x7a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xff8b8738) 18 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x00000000) 0x7ac23e94 ME_HandleMessage+0x32d4 [/home/julliard/wine/wine/dlls/riched20/editor.c:4029] in riched20: movl 0x24(%eax),%eax 4029 : (void*)((CREATESTRUCTA*)lParam)->lpszName); -- Alexandre Julliard julliard(a)winehq.org

Oct. 7, 2013

Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling (try2)

by Marvin

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://newtestbot.winehq.org/JobDetails.pl?Key=2651 Your paranoid android. === wxppro (32 bit cpp) === cpp.c:1329: Test failed: 125: Got name "?_dispatch(a)_impl_Engine@SalomeApp@@$R4CE(a)BA@PPPPPPPM(a)7AE_NAAVomniCallHandle@@@Z" cpp.c:1332: Test failed: 125: Expected "[thunk]:public: virtual bool __thiscall SalomeApp::_impl_Engine::_dispatch`vtordispex{36,16,4294967292,8}' (class omniCallHandle &)"

Oct. 7, 2013

Re: [PATCH 3/3] msvcrt: Add support for vtordispex demangling

by Marvin

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://newtestbot.winehq.org/JobDetails.pl?Key=2650 Your paranoid android. === wxppro (32 bit cpp) === cpp.c:1328: Test failed: 124: Got name "[thunk]: __thiscall CView::`vcall'{392,{flat}}' " cpp.c:1331: Test failed: 124: Expected "[thunk]: __thiscall CView::`vcall'{392,{flat}}' }'" cpp.c:1328: Test failed: 125: Got name "?_dispatch(a)_impl_Engine@SalomeApp@@$R4CE(a)BA@PPPPPPPM(a)7AE_NAAVomniCallHandle@@@Z" cpp.c:1331: Test failed: 125: Expected "[thunk]:public: virtual bool __thiscall SalomeApp::_impl_Engine::_dispatch`vtordispex{36,16,4294967292,8}' (class omniCallHandle &)"

Oct. 7, 2013

Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling

by Marvin

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://newtestbot.winehq.org/JobDetails.pl?Key=2649 Your paranoid android. === wxppro (32 bit cpp) === cpp.c:1326: Test failed: 124: Got name "[thunk]: __thiscall CView::`vcall'{392,{flat}}' " cpp.c:1329: Test failed: 124: Expected "[thunk]: __thiscall CView::`vcall'{392,{flat}}' }'"

Oct. 7, 2013

Re: msvcrt: add support for _chsize_s (try #2)

by Piotr Caban

Hi, On 10/06/13 00:45, morphiend wrote: > + * _chsize_s (MSVCRT.@) > + */ > +int CDECL MSVCRT__chsize_s(int fd, __int64 size) > +{ > + LARGE_INTEGER cur, pos; > + LARGE_INTEGER temp = { 0 }; This causes compilation warnings. There's also a trailing space in this line. > + TRACE("(fd=%d, size=%lld)\n", fd, size); You can't print 64-bit numbers this way, it's not portable. You can use wine_dbgstr_longlong function. > + handle = msvcrt_fdtoh(fd); > + if (!MSVCRT_CHECK_PMT_ERR(handle == INVALID_HANDLE_VALUE, MSVCRT_EBADF) || > + !MSVCRT_CHECK_PMT_ERR(size < 0, MSVCRT_EINVAL)) You're validating parameters incorrectly. Did you test this patch? > + { > + ret = SetEndOfFile(handle); > + if (!ret) > + { > + msvcrt_set_errno(GetLastError()); > + ret = *MSVCRT__errno(); > + } This causes the _chsize_s function to return TRUE in case of success. > + /* restore the file pointer */ > + MSVCRT__lseek(fd, cur.QuadPart, SEEK_SET); MSVCRT__lseek takes LONG as second argument. Cheers, Piotr

Oct. 7, 2013

Re: binfmt support

by Henri Verbeet

On 7 October 2013 12:06, xantares 09 <xantares09(a)hotmail.com> wrote: > ... I don't see a reason why to not include it at the wine level instead of > every linux distros, see: > https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf… > > What do you think ? > Ignoring the discussion if we want this or not for the moment, I'd guess this would break as soon as you pass something other than /usr for --prefix to configure.

Oct. 7, 2013

binfmt support

by xantares 09

Hello, I made a patch to add a configuration file to be picked up by binfmt to allow to associate windows executables to wine. As binfmt is now a part of systemd in most linux disttributions: http://www.freedesktop.org/software/systemd/man/systemd-binfmt.service.html ... I don't see a reason why to not include it at the wine level instead of every linux distros, see: https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf… What do you think ? x.

Oct. 7, 2013

Re: msvcrt: add support for _chsize_s (try #2)

by Henri Verbeet

On 6 October 2013 20:32, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > On Sun, Oct 6, 2013 at 12:45 AM, morphiend <morphiend(a)gmail.com> wrote: >> This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. >> This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without >> the implementation of _chsize_s(), certain binaries caused an internal crash >> of IDA. This patch fixed that crash. >> > You need to use your real name when sending patches. > Well, it is actually there in the patch.

Oct. 6, 2013