July 2012 - Wine-Devel - list.winehq.org

Re: "Complimentary" msvcrt?

by Vincent Povirk

> If there's some code I'd must write natively to bind the Windows app > to the Linux system (e.g. interacting with some low-level Linux stuff), > can I build that library as a DLL with wineg++ / winelib and have > the WINE-invoked app use that? Yes. This is what I meant by a bridge between Linux and Windows code. The easiest way to do this is with LoadLibrary and GetProcAddress, but linking to a winelib dll is also possible.

July 31, 2012

Re: "Complimentary" msvcrt?

by Ilya Konstantinov

On Wed, Aug 1, 2012 at 12:34 AM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > Visual C++ ships with headers and a compiler. Anyway, there's no > advantage to winelib as a build environment compared to MSVC or the > Platform SDK, assuming you are able to use one of those, except for > the ability to port to architectures other than x86, x86_64, and arm. Oooh. Now I understand what you mean: build with MSVC as usual, run in WINE on Linux. Thanks for the patience :-) If there's some code I'd must write natively to bind the Windows app to the Linux system (e.g. interacting with some low-level Linux stuff), can I build that library as a DLL with wineg++ / winelib and have the WINE-invoked app use that?

July 31, 2012

Re: "Complimentary" msvcrt?

by Vincent Povirk

>>> 1) provide Windows headers, to keep those DWORDs etc. defined >> >> Yes, but so does MSVC. > > MSVC as in Microsoft Visual C++? It only provides a C/C++ runtime. The > headers come > from the Platform SDK. In any case, here Winelib provides them, > probably slightly altered > so they'd built better on gcc. Visual C++ ships with headers and a compiler. Anyway, there's no advantage to winelib as a build environment compared to MSVC or the Platform SDK, assuming you are able to use one of those, except for the ability to port to architectures other than x86, x86_64, and arm. >>> 2) implement Windows APIs in terms of Linux as much as possible -- to keep those >>> CreateFileWs going, to avoid changing every single 'Sleep' to 'sleep' >>> "just because". >> >> Winelib doesn't do that. It uses the same implementation of the >> Windows API that is in Wine. > > Sleep and CreateFileW are Windows APIs. I want them implemented > for my C code to link to. Internally, they call into libc or Linux syscalls. > How is Winelib not what I want? Wine's CreateFileW does path mapping to simulate a Windows filesystem, regardless of whether you're using winelib. It's not a thin wrapper around Linux API's; it's exactly the same wrapper you get if you run a normal Windows program. Because it's the same API implementation, it doesn't offer any advantage over running the same code compiled with Microsoft's C/C++ compiler (which according to rumor is faster and has a better optimizer), while there is a significant disadvantage in the form of the work it takes to make that code build correctly.

July 31, 2012

Re: "Complimentary" msvcrt?

by Ilya Konstantinov

On Tue, Jul 31, 2012 at 11:15 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >> Winelib is there to: >> 1) provide Windows headers, to keep those DWORDs etc. defined > > Yes, but so does MSVC. MSVC as in Microsoft Visual C++? It only provides a C/C++ runtime. The headers come from the Platform SDK. In any case, here Winelib provides them, probably slightly altered so they'd built better on gcc. >> 2) implement Windows APIs in terms of Linux as much as possible -- to keep those >> CreateFileWs going, to avoid changing every single 'Sleep' to 'sleep' >> "just because". > > Winelib doesn't do that. It uses the same implementation of the > Windows API that is in Wine. Sleep and CreateFileW are Windows APIs. I want them implemented for my C code to link to. Internally, they call into libc or Linux syscalls. How is Winelib not what I want? > Perhaps the io-layer aka libwapi library in Mono is closer to what you > describe, but that is very limited and only intended for internal use > in Mono. Interesting. I'll check it out to see what they've been up to.

July 31, 2012

Re: "Complimentary" msvcrt?

by Vincent Povirk

> Winelib is there to: > 1) provide Windows headers, to keep those DWORDs etc. defined Yes, but so does MSVC. > 2) implement Windows APIs in terms of Linux as much as possible -- to keep those > CreateFileWs going, to avoid changing every single 'Sleep' to 'sleep' > "just because". Winelib doesn't do that. It uses the same implementation of the Windows API that is in Wine. Perhaps the io-layer aka libwapi library in Mono is closer to what you describe, but that is very limited and only intended for internal use in Mono.

July 31, 2012

Re: "Complimentary" msvcrt?

by Ilya Konstantinov

On Tue, Jul 31, 2012 at 10:42 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > Winelib is not a useful intermediate step in porting an existing > application to Linux, as most of the work involved in porting to > winelib will not help you with a native Linux port. At some point you > have to make a clean break from Windows, and winelib doesn't change > that. It just provides a way to delay that painful step, while doing > little to reduce the pain when it comes. Why not use Winelib as an abstraction layer? Keep in mind my users are enterprise and they do not mind the perceived "unsexy-ness" of a non-native port. I'm not going to present them with fugly non-native GUI anyway. I have a big bulk of "headless" code coming from Windows CE, that was ported to Windows without much difficulty, and now its heading to Linux as well. Winelib is there to: 1) provide Windows headers, to keep those DWORDs etc. defined 2) implement Windows APIs in terms of Linux as much as possible -- to keep those CreateFileWs going, to avoid changing every single 'Sleep' to 'sleep' "just because". The code will keep running on Windows too. Why can't Winelib keep serving as a rudimentary abstraction layer, as funny as that might sound? Our use of Windows is pretty basic. I don't believe we use a single function whose signature you don't already know by heart. (Except, maybe, for CryptoAPI, but I don't rule out re-implementing that chunk.) The code is full of MSC-isms and MSVCRT-isms but it's nothing too bad. So, then, why not?

July 31, 2012

Re: "Complimentary" msvcrt?

by Vincent Povirk

I have to wonder if you're using winelib in a way that's not appropriate. Winelib is not a useful intermediate step in porting an existing application to Linux, as most of the work involved in porting to winelib will not help you with a native Linux port. At some point you have to make a clean break from Windows, and winelib doesn't change that. It just provides a way to delay that painful step, while doing little to reduce the pain when it comes. Nor is there typically any advantage to running existing Windows code with winelib compared to running a Windows exe or dll in Wine. While it's true that winelib can be used to port Windows code to a new CPU architecture not targeted by MSVC, there's not much demand for this. Most people who think they want to use winelib want to do one of those things and don't realize that winelib doesn't solve any of their problems. Almost no one has a real use case for building existing Windows code with winelib. Given that, improving winelib's Windows source compatibility doesn't make it much more useful, and it probably isn't worth anyone's time. Winelib works best to support a limited amount of new code (a single .dll.so or .exe.so) that acts as a bridge between Linux and Windows code.

July 31, 2012

"Complimentary" msvcrt?

by Ilya Konstantinov

Hey, I apologize for the flood of "newbie" questions coming from me lately :-) At the very least, I'll be giving Winelib a decent challenge, and perhaps we could improve it a bit... Now, I've seen that Wine re-implements MSVCRT. However, this is a drop-in MSVCRT.DLL replacement, and it's incompatible with the rest of the GNU toolchain; for example, the GNU libstdc++ barfs on trying to include its own <wchar.h> and ending up including the msvcrt/wchar.h instead. I'm looking for something more humble -- a library for easy porting, implementing those functions not implemented by glibc itself -- e.g. _wfopen, _wgetenv. In fact, many MSVCRT functions can be made available by simply #define-ing them to their glibc counterparts. (Of course, this should be done carefully.) The main goal of this library should be source-level compatibility. Does such a thing exist? P.S. I know "real men" port their code to "real glibc", but I believe in taking small steps for bringing Linux into our codebase, thus decreasing friction with the rest of the developers.

July 31, 2012

Re: [2/2] msi: Try the registered install location first when resolving the target directory.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > --- > dlls/msi/action.c | 18 +++++++++++++++--- > dlls/msi/msipriv.h | 1 + > 2 files changed, 16 insertions(+), 3 deletions(-) It doesn't work here: ../../../../wine/tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so ../../../../wine/dlls/msi/tests/package.c && touch package.ok wine: Unhandled page fault on read access to 0x20006308e at address 0x2b39152590cf (thread 002c), starting debugger... Unhandled exception: page fault on read access to 0x20006308e in 64-bit code (0x00002b39152590cf). Register dump: rip:00002b39152590cf rsp:000000000022f700 rbp:0000000000000001 eflags:00010246 ( R- -- I Z- -P- ) rax:0000000000063090 rbx:0000000000000002 rcx:00000000000666c2 rdx:0000000000000000 rsi:0000000000000000 rdi:0000000000000001 r8:0000000000000010 r9:000000000022f790 r10:000000000022f740 r11:000000020006308e r12:0000000000062f10 r13:0000000000000000 r14:000000000005f1f8 r15:00002b39136f0d90 Stack dump: 0x000000000022f700: 0000000000000000 0000000000000000 0x000000000022f710: 0000000000000000 0000000000000000 0x000000000022f720: 0000000000000000 0000000000000008 0x000000000022f730: 000000000022f790 000000000022f740 0x000000000022f740: 00002b39136f0d90 00000000000666c0 0x000000000022f750: 00000000000658e0 0000000000063042 0x000000000022f760: 0000000000000054 000000000005f228 0x000000000022f770: 0000000000000000 0000000000065810 0x000000000022f780: 000000000005f190 00002b391525ae9c 0x000000000022f790: 0000000000000000 0000000000000000 0x000000000022f7a0: 00002b39136f0d90 00002b391528a1fc 0x000000000022f7b0: 0000000000064f00 0000000000000030 Backtrace: =>0 0x00002b39152590cf msi_build_directory_name+0x25f(count=0x2) [/home/julliard/wine/build/obj-elf64/dlls/msi/../../../wine/dlls/msi/action.c:2157] in msi (0x0000000000000001) 1 0x00002b391525ae9c ACTION_CostFinalize+0x35b(package=0x5f190) [/home/julliard/wine/build/obj-elf64/dlls/msi/../../../wine/dlls/msi/action.c:2179] in msi (0x000000000005f190) 2 0x00002b391524e45b ACTION_HandleStandardAction+0xba(package=0x5f190, action="CostFinalize", rc=0x22f85c) [/home/julliard/wine/build/obj-elf64/dlls/msi/../../../wine/dlls/msi/action.c:7397] in msi (0x000000000022f85c) 3 0x00002b391525d877 ACTION_PerformUIAction+0x46(package=0x5f190, action="CostFinalize", script=0xffffffff) [/home/julliard/wine/build/obj-elf64/dlls/msi/../../../wine/dlls/msi/action.c:7448] in msi (0x0000000000059f20) 4 0x00002b391528b1d3 MsiDoActionW+0xc2(hInstall=0x2, szAction="CostFinalize") [/home/julliard/wine/build/obj-elf64/dlls/msi/../../../wine/dlls/msi/install.c:108] in msi (0x0000000000000057) 5 0x00002b391528b436 MsiDoActionA+0x105(hInstall=0x2, szAction="CostFinalize") [/home/julliard/wine/build/obj-elf64/dlls/msi/../../../wine/dlls/msi/install.c:56] in msi (0x00002b3914b9af00) 6 0x00002b3914b5fabe func_package+0x45cd() [/home/julliard/wine/build/obj-elf64/dlls/msi/tests/../../../../wine/dlls/msi/tests/package.c:3017] in msi_test (0x000000000022fadc) 7 0x00002b3914a922aa main+0x2c9(argc=<internal error>, argv=<internal error>) [/home/julliard/wine/build/obj-elf64/dlls/msi/tests/../../../../wine/include/wine/test.h:557] in msi_test (0x00002b3914dc2fe0) 8 0x00002b3914b7b1b2 __wine_spec_exe_entry+0xa1(peb=<internal error>) [/home/julliard/wine/build/obj-elf64/dlls/winecrt0/../../../wine/dlls/winecrt0/exe_entry.c:36] in msi_test (0x00002b39131238f0) 9 0x000000007b873391 start_process+0xb0(peb=0x7fffffbef000) [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1052] in kernel32 (0x00002b3914b7b110) 10 0x00002b39139889de call_thread_func+0x6d(entry=0x7b8732e0, arg=0x7fffffbef000, frame=<internal error>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/signal_x86_64.c:3230] in ntdll (0x00007fff5dbb09f0) 11 0x00002b39139820ca call_thread_entry_point+0x29() in ntdll (0x00007fff5dbb09f0) 12 0x00002b39139549d6 start_process+0x15(kernel_start=<internal error>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2653] in ntdll (0x00007fff5dbb09f0) 13 0x00002b3912dfd283 wine_call_on_stack+0x12() in libwine.so.1 (0x00007fff5dbb09f0) 14 0x00002b3912dfd2d9 wine_switch_to_stack+0x8(func=<internal error>, arg=<internal error>, stack=<internal error>) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/port.c:59] in libwine.so.1 (0x00007fffffbef000) 15 0x00002b391395a480 LdrInitializeThunk+0x45f(kernel_start=0x7b8732e0, unknown2=<internal error>, unknown3=<internal error>, unknown4=<internal error>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2709] in ntdll (0x00007fffffbef000) 16 0x000000007b8797ed __wine_kernel_init+0x91c() [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1255] in kernel32 (0x00002b3913bea620) 17 0x00002b391395acf4 __wine_process_init+0x143() [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2918] in ntdll (0x00007fff5dbb1ca0) 18 0x00002b3912dfb488 wine_init+0x297(argc=0x3, argv=0x7fff5dbb2198, error="", error_size=0x400) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/loader.c:831] in libwine.so.1 (0x00007fff5dbb1ca0) 19 0x000000007bf00da2 main+0x71(argc=0x3, argv=0x7fff5dbb2198) [/home/julliard/wine/build/obj-elf64/loader/../../wine/loader/main.c:230] in <wine-loader> (0x00007fff5dbb2198) 20 0x00002b391338dead __libc_start_main+0xfc(main=<is not available>, argc=<is not available>, ubp_av=<is not available>, init=<is not available>, fini=<is not available>, rtld_fini=<is not available>, stack_end=0x7fff5dbb2188) [/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:228] in libc.so.6 (0x0000000000000000) 21 0x000000007bf00e9d _start+0x28() in <wine-loader> (0x0000000000000000) 0x00002b39152590cf msi_build_directory_name+0x25f [/home/julliard/wine/build/obj-elf64/dlls/msi/../../../wine/dlls/msi/action.c:2157] in msi: cmpw $5c,(%r11) 2157 if ( i + 1 != count && dir[strlenW( dir ) - 1] != '\\') strcatW( dir, szBackSlash ); -- Alexandre Julliard julliard(a)winehq.org

July 31, 2012

Re: Error 123

by Alex Henrie

To use serial ports on Linux, your user must be a member of the "dialout" group. -Alex

July 31, 2012