binfmt support
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/76ebd5d29effaf4b6b39ceecb689f7008bf6b376 What do you think ? x.
Re: binfmt support
On 7 October 2013 12:06, xantares 09 xantare...@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/76ebd5d29effaf4b6b39ceecb689f7008bf6b376 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.
Re: msvcrt: add support for _chsize_s (try #2)
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
Re: [PATCH 3/3] msvcrt: Add support for vtordispex demangling
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@_impl_Engine@SalomeApp@@$R4CE@BA@PPPM@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 )
Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling
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}}' }'
Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling (try2)
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@_impl_Engine@SalomeApp@@$R4CE@BA@PPPM@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 )
Re: riched20: Set control content in WM_CREATE message
Piotr Caban pi...@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 0x0024 at address 0x7ac23e94 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x0024 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: EBX:7ac58c00 ECX:0032fc80 EDX:003338e8 ESI:003338e8 EDI:0001 Stack dump: 0x0032f290: 0032fc80 0x0032f2a0: 0001 00333428 0x0032f2b0: 4d430002 0008 0004 7bc3c8e3 0x0032f2c0: 00333558 00333550 7bc3c8e3 0x0032f2d0: 0780 04b0 0032f300 6890a34c 0x0032f2e0: 001f 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 (0x) 12 0x6803134b wine_switch_to_stack+0x2a(func=0x7bc54a00, arg=0x7b8604e0, stack=0x33) [/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 (0x) 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 julli...@winehq.org
Re: mscoree: Partial implement ICLRMetaHost RequestRuntimeLoadedNotification (try 2)
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.
Re: [1/3] xmllite: Use buffer offset instead of pointers
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?
Re: msi/tests: Use BOOL type where appropriate
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=2660 Your paranoid android. === wvista (32 bit msi) === The test timed out === w2008s64 (32 bit msi) === The test timed out === w7pro64 (32 bit msi) === No test summary line found Failure running script in VM: network read timed out === w2008s64 (64 bit msi) === Timeout === w7pro64 (64 bit msi) === Timeout
