Re: wineapploader in wine64
Le jeudi 16 février 2012 21:27:37, Austin English a écrit : Most people use `wineserver -k` for that. Woops, missed your reply. The problem with wineserver is, with debian packages, that it's not available through PATH (http://packages.debian.org/sid/amd64/libwine-unstable/filelist : /usr/lib32/wine-unstable/wineserver). But I take note anyway, as I usually build wine myself than use distro packages. -- Vincent Pelletier
wineapploader in wine64
Hi, Any explanation for why the wineapploader script doesn't use 'wine64' instead of 'wine' in a 64bit Linux with 64bit wine? That's the script that is used to build /usr/bin/wineboot and /usr/bin/regedit, for instance. In Fedora 15 with wine 1.3.24, the upshot is that the 'wineboot' command doesn't work. /usr/lib/wine/wineboot.exe.so is not installed; only /usr/lib64/wineboot.exe.so is. Since the /usr/bin/wineboot is running 'wine' instead of 'wine64' it is looking for the 32bit /usr/lib/wine/wineboot.exe.so. It can't be found since it isn't installed so the loader gives up. $ wineboot wine: cannot find LC:\\windows\\system32\\wineboot.exe If it used wine64 instead, it would work. There must be a reason that wine64 is starting 32bit apps, but I haven't been able to glean anything from the web. Thanks for any info, -- Michael Ost
Re: wineapploader in wine64
Michael Ost m...@museresearch.com writes: In Fedora 15 with wine 1.3.24, the upshot is that the 'wineboot' command doesn't work. /usr/lib/wine/wineboot.exe.so is not installed; only /usr/lib64/wineboot.exe.so is. Since the /usr/bin/wineboot is running 'wine' instead of 'wine64' it is looking for the 32bit /usr/lib/wine/wineboot.exe.so. It can't be found since it isn't installed so the loader gives up. It could be considered it a bug, but 64-bit-only setups are not really supported. You need to have the 32-bit side, if only to create a valid prefix (besides, there shouldn't be any reason to run wineboot by hand). -- Alexandre Julliard julli...@winehq.org
Re: wineapploader in wine64
Le jeudi 16 février 2012 20:57:10, Alexandre Julliard a écrit : (besides, there shouldn't be any reason to run wineboot by hand). FWIW, on wine (32bits) I use wineboot -ks to get rid of a crashing app (stuck eating cpu, or just willing to stay). -- Vincent Pelletier
Re: wineapploader in wine64
On Thu, Feb 16, 2012 at 14:21, Vincent Pelletier plr.vinc...@gmail.com wrote: Le jeudi 16 février 2012 20:57:10, Alexandre Julliard a écrit : (besides, there shouldn't be any reason to run wineboot by hand). FWIW, on wine (32bits) I use wineboot -ks to get rid of a crashing app (stuck eating cpu, or just willing to stay). Most people use `wineserver -k` for that. -- -Austin
Re: wineapploader in wine64
On 02/16/2012 11:57 AM, Alexandre Julliard wrote: prefix (besides, there shouldn't be any reason to run wineboot by hand). We use it with --shutdown to cleanly terminate (as in WM_CLOSE, not kill) all wine apps from a hardware button press. Is there a preferred way? Thanks! -- Michael Ost
Re: wineapploader in wine64
Michael Ost m...@museresearch.com writes: On 02/16/2012 11:57 AM, Alexandre Julliard wrote: prefix (besides, there shouldn't be any reason to run wineboot by hand). We use it with --shutdown to cleanly terminate (as in WM_CLOSE, not kill) all wine apps from a hardware button press. Is there a preferred way? No that's OK, though in general I'd suggest using 'wine64 wineboot' in scripts so that you don't depend on the /usr/bin wrapper scripts. -- Alexandre Julliard julli...@winehq.org
Re: __CxxFrameHandler unsupported on wine64?
On Fri, 8 Apr 2011, Peter Urbanec wrote: [...] So, I had a quick look at the wine source and found a comment in dlls/msvcrt/cppexcept.c that says: /* CxxFrameHandler is not supported on non-i386 */ I don't think that this is quite right, given that Microsoft's MFC80.DLL attempts to call __CxxFrameHandler. Is it more likely that wine only provides an i386 implementation? I read this comment as: Wine does not support CxxFrameHandler on non-i386. This seems to match what you think happens. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
__CxxFrameHandler unsupported on wine64?
I have an application that requires MFC80.DLL. When I install only the MFC80.DLL file from the vcredist package, I end up with the following errors: wine: Call from 0x7fd606a3148b to unimplemented function MSVCR80.dll.__CxxFrameHandler, aborting So, I had a quick look at the wine source and found a comment in dlls/msvcrt/cppexcept.c that says: /* CxxFrameHandler is not supported on non-i386 */ I don't think that this is quite right, given that Microsoft's MFC80.DLL attempts to call __CxxFrameHandler. Is it more likely that wine only provides an i386 implementation? If so, is there any chance that someone may be able to provide x86_64 implementation in the near future? It's way over my head :-( Best regards, Peter Urbanec
wine64 issues in dlls/msvcr90/tests/msvcr90.c
As of a few days ago, I'm seeing the following errors when building wine64 with gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 dlls/msvcr90/tests/msvcr90.c:137:14: warning: 'do_call_func1' defined but not used dlls/msvcr90/tests/msvcr90.c:147:14: warning: 'do_call_func2' defined but not used dlls/msvcr90/tests/msvcr90.c: Assembler messages: dlls/msvcr90/tests/msvcr90.c:150: Error: invalid instruction suffix for `push' When building wine32, there seem to be no problems. Is anyone else seeing this when building wine64?
wiki work, wine64 portability issues
Hi all, I was just cleaning up some Janitorial sections on wine wiki. Now several questions arise: Just for interest I looked for a kind of wine64 portability guide to link to the http://wiki.winehq.org/PortabilityFixes . Are there any documents with source patterns which have been fixed to get Wine 64-bit ready? I think some of the listed janitorial tasks are already finished. E.g. there weren't any commits for 16bit separation for a longer time (Alexandre?). I don't have any overview if this tasks are really finished or if there are still some sections remaining? As a proposal to be discussed for the wiki people: I would like to make a category CategoryAbout to collect the wiki articles which are (should) directly linked from the about page on the winheq.org site. I think this would be a good first way to solve the still existing old/duplicated pages between wiki and winheq.org pages. What do you think? Thanks in advance, Thomas
Re: Wine64 debugger
the assertion `addr-Mode == AddrModeFlat' failed is likely an address returned by dbghelp which is not properly initialized. Could you send me off line the .exe (and associated DLL if any) so that I can check it TIA 2010/8/17 Peter Urbanec winehq@urbanec.net Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as ./wine Test1.exe. When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr-Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x7fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec -- -- Eric Pouech
Re: Wine64 debugger
On 18/08/10 01:51, Marcus Meissner wrote: On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote: I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. Check if your code uses int in its FindNextFile or findfirst things. I had a good look at the wine source code as well as those parts of the application source code that I can get access to and it all looks good as far as correctly using HANDLE type to store HANDLE values. Unfortunately, the application in question also makes use of FLEXlm libraries from Macrovision and these binary blobs appear to be buggy. All the symptoms point to the FLEXlm code storing the 64-bit HANDLE value in a 32-bit int - this is evidenced by sign extension on some of the values. Of course, the initial cause and the issues with the debugger are essentially unrelated. I have sent some sample test binaries to Eric, to reproduce the debugger issue. The buggy Win64 application is another story. It looks like Win64 must most of the time return HANDLE values that fit within 31 bits, because from what I hear, Windows users go through thousands of invocations of this app without seeing any issues. I wonder if there is a way of making wine allocate the memory for the object pointed to by the HANDLE somewhere in the lower part of the address space. That ought to mitigate this particular application bug and bring the compatibility a little closer to what's observed under Win64.
Wine64 debugger
Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as ./wine Test1.exe. When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr-Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x7fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec
Re: Wine64 debugger
On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote: Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. Check if your code uses int in its FindNextFile or findfirst things. I fixed ioquake3 for this for instance. The Wine code is correct as-is, but perhaps the Windows win64 code generates only handles with 32bit. Ciao, Marcus
Re: Wine64 debugger
On Tue, Aug 17, 2010 at 05:51:55PM +0200, Marcus Meissner wrote: The Wine code is correct as-is, but perhaps the Windows win64 code generates only handles with 32bit. That it very likely. There are windows #defines/inline functions that convert HANDLE = long. Remember there are some functions that return handles as long (not void *) Also, when the windows kernel generates a HANDLE it is unlikely to know whether the app is 32bit or 64bit - so will only generate 32bit values. I also remember reading somewhere that the kernel handle table is limited to 2^24 entries - even in 64bit mode. David -- David Laight: da...@l8s.co.uk
Re: [PATCH] atl: Do not fail on Wine64
On Mon, Jun 14, 2010 at 03:07:39AM +0200, Maarten Lankhorst wrote: Hi Marcus, 2010/6/13 Marcus Meissner mar...@jet.franken.de: Hi, The size is 248 on Wine64 ... (expected 240), so we miss perhaps a pointer or some alignment. Its not fully clear what. It at least does not crash when ignoring the size change. Seems wrong to me, does it allow size 240 on 64-bits, or does it allow 248 only? It seems to input 248 in my case. Probably it will not get 240, but _ATL_MODULEW (or better, the ATL_MODULE C++ class) has some other difference. Question is really how to find out more, as atl.dll is written in C++ and documentation scarce. - so for starters I just would suggest to ignore failure. ciao, Marcus
Re: [PATCH] atl: Do not fail on Wine64
Marcus Meissner mar...@jet.franken.de writes: It seems to input 248 in my case. Probably it will not get 240, but _ATL_MODULEW (or better, the ATL_MODULE C++ class) has some other difference. Question is really how to find out more, as atl.dll is written in C++ and documentation scarce. - so for starters I just would suggest to ignore failure. It wouldn't be hard to write a test to at least determine which sizes are accepted. We need the correct value for ATLVer1Size too. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] atl: Do not fail on Wine64
Hi Marcus, 2010/6/13 Marcus Meissner mar...@jet.franken.de: Hi, The size is 248 on Wine64 ... (expected 240), so we miss perhaps a pointer or some alignment. Its not fully clear what. It at least does not crash when ignoring the size change. Seems wrong to me, does it allow size 240 on 64-bits, or does it allow 248 only? ~Maarten
Re: configure: Refuse to build wine64 with buggy gcc
Maarten Lankhorst wrote: --- ;D As there is no fixed gcc out there I'd rather see configure warn here instead of aborting. We do want to make it easy for people to compile Wine64. bye michael
Re: configure: Refuse to build wine64 with buggy gcc
Do we want useless bug reports / wine test results? I agree that we want as much people to compile wine64 though. Perhaps an acceptable solution for now would be to mention that the current gcc is buggy and let configure link to some easy to use script which can build a proper compiler. Roderick On Mon, Apr 26, 2010 at 10:40 AM, Michael Stefaniuc mstef...@redhat.com wrote: Maarten Lankhorst wrote: --- ;D As there is no fixed gcc out there I'd rather see configure warn here instead of aborting. We do want to make it easy for people to compile Wine64. bye michael
Re: configure: Refuse to build wine64 with buggy gcc
Hi Michael, 2010/4/26 Michael Stefaniuc mstef...@redhat.com: Maarten Lankhorst wrote: --- ;D As there is no fixed gcc out there I'd rather see configure warn here instead of aborting. We do want to make it easy for people to compile Wine64. Any bug report would be useless on 64-bits with a broken gcc. For example the gdiplus tests fail, so any app that would use gdiplus would potentially be broken badly, as can be witnessed by the failing tests. I believe it's better to downward refuse to build there, than to trace down bugs that don't really exist. If that requires patching and rebuilding gcc for wine only so be it. I'll try to get the gcc guys to accept the patch in the meantime. :) Cheers, Maarten
Re: Understanding 64bit implications and wine64
On Mon, Feb 08, 2010 at 11:27:07AM +0100, joerg-cyril.hoe...@t-systems.com wrote: The wine64 challenge seems to let 32bit MS-windows apps work even though the UNIX side has to manage pointer addresses 2^32, i.e. above the lower 4GB address range. Is there some address translation involved or only mmap'ing? What must the Wine developer know to write correct code for wine64? A 32bit (i386) windows application binary can only run in a 32bit Unix application [1]. In which case the Unix kernel will handle the system call emulation and ensure that the only user-space virtual addresses the application sees are 32bit (it may be able to give the app almost 4G of user address space - instead of the usual 3G). Wine may allow both 32bit and 64bit clients to talk to its server process - and that may need care so that only fixed-size types are used. David [1] The instruction sets are different - the single byte opcodes for inc/dec register are reallocated for other uses. So you cannot just load 32bit code into a 64bit binary and expect anything sane to happen. -- David Laight: da...@l8s.co.uk
Re: Understanding 64bit implications and wine64
On 9 February 2010 18:16, David Laight da...@l8s.co.uk wrote: A 32bit (i386) windows application binary can only run in a 32bit Unix application [1]. In which case the Unix kernel will handle the system call emulation and ensure that the only user-space virtual addresses the application sees are 32bit (it may be able to give the app almost 4G of user address space - instead of the usual 3G). So the Wine on my 64-bit Ubuntu (which works perfectly well) is actually a 32-bit app? I didn't know that! - d.
Re: Understanding 64bit implications and wine64
On 10 February 2010 09:11, David Gerard dger...@gmail.com wrote: On 9 February 2010 18:16, David Laight da...@l8s.co.uk wrote: A 32bit (i386) windows application binary can only run in a 32bit Unix application [1]. In which case the Unix kernel will handle the system call emulation and ensure that the only user-space virtual addresses the application sees are 32bit (it may be able to give the app almost 4G of user address space - instead of the usual 3G). So the Wine on my 64-bit Ubuntu (which works perfectly well) is actually a 32-bit app? I didn't know that! Yup. If Wine runs win32 apps (which most Windows apps are), then it's 32bit. WoW64 for the win64+win32 wine is not ready, afaik.
Understanding 64bit implications and wine64
Hi, I've trouble understanding some of the 64bit issues. Lacking a 64bit machine, I'm left asking questions ;-) My understanding is that wine64 is the effort to make Wine work on 64bit UNIX systems, i.e. pointer size = 64bit, isn't it? DWORD_PTR is 64 bit wide on a wine64 system, 32 bit otherwise, correct? A priori, this has nothing to do with MS-Windows' LARGE_ADDRESS_SPACE_AWARE(sp?) API, which I believe allows 32bit apps to nevertheless make use of more than 1,5/2/4GBof RAM, isn't it? The wine64 challenge seems to let 32bit MS-windows apps work even though the UNIX side has to manage pointer addresses 2^32, i.e. above the lower 4GB address range. Is there some address translation involved or only mmap'ing? What must the Wine developer know to write correct code for wine64? For instance, I fail to understand Erich Pouech's recent commit 5cab72bc95ec2d864e19952fff2df99610ba7537 winmm: For MCI parsing, use 64bit compatible variables. If you look closely at the definitions of MCI_xyz_PARMS in MMSYSTEM.H, you'll notice that (at least on 32bit systems), despite the different types (DWORD, LPSTR, UINT) these structures are originally an array of 32bit values. This regular structure is essential, because the MCI command parser has very limited means to know about different sizes. All it knows is MCI_INTEGER, MCI_STRING, MCI_CONSTANT. An app that sends an MCI_xyz command sends a pointer to such an array, decorated as MCI_xyz_PARMSA/W for nicer access. Alternatively, when using mciSendString, the MCI parser builds this array of DWORD elements, then calls the MCI command. In recent Wine, this has become an array of DWORD_PTR instead. wine-tests may work because Wine is cnosistent with itself, but How can this possibly work without breaking binary compatibility? Thanks for your help, Jörg Höhle
Re: Understanding 64bit implications and wine64
joerg-cyril.hoe...@t-systems.com wrote: Hi, I've trouble understanding some of the 64bit issues. Lacking a 64bit machine, I'm left asking questions ;-) My understanding is that wine64 is the effort to make Wine work on 64bit UNIX systems, i.e. pointer size = 64bit, isn't it? DWORD_PTR is 64 bit wide on a wine64 system, 32 bit otherwise, correct? A priori, this has nothing to do with MS-Windows' LARGE_ADDRESS_SPACE_AWARE(sp?) API, which I believe allows 32bit apps to nevertheless make use of more than 1,5/2/4GBof RAM, isn't it? The wine64 challenge seems to let 32bit MS-windows apps work even though the UNIX side has to manage pointer addresses 2^32, i.e. above Not at all. Wine64 is to let Win64 bit apps on Wine too; of course Wine running on a 64bit host. Win32 apps will work on Wine64 too through WoW64. the lower 4GB address range. Is there some address translation involved or only mmap'ing? What must the Wine developer know to write correct code for wine64? For instance, I fail to understand Erich Pouech's recent commit 5cab72bc95ec2d864e19952fff2df99610ba7537 winmm: For MCI parsing, use 64bit compatible variables. If you look closely at the definitions of MCI_xyz_PARMS in MMSYSTEM.H, you'll notice that (at least on 32bit systems), despite the different types (DWORD, LPSTR, UINT) these structures are originally an array of 32bit values. This regular structure is essential, because the MCI command parser has very limited means to know about different sizes. All it knows is MCI_INTEGER, MCI_STRING, MCI_CONSTANT. An app that sends an MCI_xyz command sends a pointer to such an array, And pointers on 64bit Windows are 64bit. Thus the variable that holds that pointer needs to be 64bit too on Wine64. That's achieved by changing from DWORD to DWORD_PTR. decorated as MCI_xyz_PARMSA/W for nicer access. Alternatively, when using mciSendString, the MCI parser builds this array of DWORD elements, then calls the MCI command. In recent Wine, this has become an array of DWORD_PTR instead. wine-tests may work because Wine is cnosistent with itself, but How can this possibly work without breaking binary compatibility? DWORD_PTR has the size of a void pointer which is 32bit on 32bit Wine. Aka DWORD and DWORD_PTR have the same size on Wine32 and thus binary compatibility is still there. bye michael
Re: Understanding 64bit implications and wine64
If you look closely at the definitions of MCI_xyz_PARMS in MMSYSTEM.H, you'll notice that (at least on 32bit systems), despite the different types (DWORD, LPSTR, UINT) these structures are originally an array of 32bit values. This regular structure is essential, because the MCI command parser has very limited means to know about different sizes. All it knows is MCI_INTEGER, MCI_STRING, MCI_CONSTANT. actually, this patch is still broken I originally assumed that the MCI structs were 8-byte aligned on WIN64, which is wrong actually, it's 4 byte aligned, meaning that we need some more work on MCI string parser to take care of this An app that sends an MCI_xyz command sends a pointer to such an array, decorated as MCI_xyz_PARMSA/W for nicer access. Alternatively, when using mciSendString, the MCI parser builds this array of DWORD elements, then calls the MCI command. In recent Wine, this has become an array of DWORD_PTR instead. wine-tests may work because Wine is cnosistent with itself, but How can this possibly work without breaking binary compatibility? in that case, we (likely) need to write integral values as DWORD (on both 32 and 64 bit systems) and strings pointers as DWORD_PTR A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Understanding 64bit implications and wine64
All about 64-bit programming: http://www.viva64.com/articles/64-bit-development/ Articles , http://www.viva64.com/links/64-bit-development/ Articles Reviews , http://www.viva64.com/blog/en/tag/64-bits/ Blog . -- View this message in context: http://old.nabble.com/Understanding-64bit-implications-and-wine64-tp27497865p27510882.html Sent from the Wine - Devel mailing list archive at Nabble.com.
Re: Understanding 64bit implications and wine64
Andrey_Karpov kar...@viva64.com wrote: All about 64-bit programming: http://www.viva64.com/articles/64-bit-development/ Articles , http://www.viva64.com/links/64-bit-development/ Articles Reviews , http://www.viva64.com/blog/en/tag/64-bits/ Blog . To be honest it would be better to start with http://wiki.winehq.org/Wine64 and referring first to Microsoft's Programming Guide for 64-bit Windows http://msdn.microsoft.com/en-us/library/bb427430%28VS.85%29.aspx instead of plugging your own guides (regardless how useful they are). -- Dmitry.
How does --with-wine64 work?
Vincent asked me to get add a --with-wine64 option to my build script.
I was testing around, and can't seem to get it to work:
$ mkdir - p $HOME/wine{32,64}
$ cd $HOME/wine64
$ ~/wine-git/configure --enable-win64
$ make -j4
$ cd $HOME/wine32
$ ~/wine-git/configure --with-wine64=~/wine64
...
checking for the directory containing the Wine tools... configure: error:
could not find Wine tools in ~/wine64/
~/wine-git/configure --with-wine64=~/wine64/tools/
...
checking for the directory containing the Wine tools... configure:
error: could not find Wine tools in ~/wine64/tools/
What am I missing? Perhaps it needs to be installed somewhere first?
--
-Austin
Re: How does --with-wine64 work?
On Mon, Dec 7, 2009 at 7:44 PM, Austin English austinengl...@gmail.com wrote: checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/ ~/wine-git/configure --with-wine64=~/wine64/tools/ ... checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/tools/ What am I missing? Perhaps it needs to be installed somewhere first? This looks similar to the cross-compile build for mingw where you need a checkout with the normal tools built for your host and then another checkout for your target. You then run and point the target configure at the host wine path to get the host tools. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: How does --with-wine64 work?
On Mon, Dec 7, 2009 at 9:30 PM, Steven Edwards winehac...@gmail.com wrote: This looks similar to the cross-compile build for mingw where you need a checkout with the normal tools built for your host and then another checkout for your target. You then run and point the target configure at the host wine path to get the host tools. Doh I read that wrong. You had it right if it follows the same structure as the mingw port. No idea, I'll try a build here in a bit -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: How does --with-wine64 work?
Austin English schreef:
Vincent asked me to get add a --with-wine64 option to my build script.
I was testing around, and can't seem to get it to work:
$ mkdir - p $HOME/wine{32,64}
$ cd $HOME/wine64
$ ~/wine-git/configure --enable-win64
$ make -j4
$ cd $HOME/wine32
$ ~/wine-git/configure --with-wine64=~/wine64
...
checking for the directory containing the Wine tools... configure: error: could
not find Wine tools in ~/wine64/
~/wine-git/configure --with-wine64=~/wine64/tools/
...
checking for the directory containing the Wine tools... configure:
error: could not find Wine tools in ~/wine64/tools/
What am I missing? Perhaps it needs to be installed somewhere first?
Try --with-wine64=$HOME/wine64
The ~ doesn't get expanded
Re: How does --with-wine64 work?
On Tue, Dec 8, 2009 at 1:01 AM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
Austin English schreef:
Vincent asked me to get add a --with-wine64 option to my build script.
I was testing around, and can't seem to get it to work:
$ mkdir - p $HOME/wine{32,64}
$ cd $HOME/wine64
$ ~/wine-git/configure --enable-win64
$ make -j4
$ cd $HOME/wine32
$ ~/wine-git/configure --with-wine64=~/wine64
...
checking for the directory containing the Wine tools... configure: error:
could not find Wine tools in ~/wine64/
~/wine-git/configure --with-wine64=~/wine64/tools/
...
checking for the directory containing the Wine tools... configure:
error: could not find Wine tools in ~/wine64/tools/
What am I missing? Perhaps it needs to be installed somewhere first?
Try --with-wine64=$HOME/wine64
The ~ doesn't get expanded
I feel silly...I could have sworn I tried that. Thanks Maarten!
--
-Austin
Wine64: Down to 68 test failures!
For those of you that don't follow http://test.winehq.org/, AJ and others 64-bit work has brought down the failures to 68: http://test.winehq.org/data/fb0275dd3148a098967f5959adb57ebe41a4383e/index_Wine.html Down quite a bit from over 100 about 6 months ago. There's still a lot of work to do, of course. If you've got a 64-bit machine, give your favorite area of the wine tree a try in 64-bit mode and fix some test failures/compiler warnings. -- -Austin
Wine64 and other test failures
Howdy, For those of y'all not monitoring http://test.winehq.org/data, I've begun submitting daily test results for Wine64. There are also test results for regular 32-bit wine, wine in a virtual desktop, and with WINEDEBUG=+heap. Regular wine is passing a majority of the time (Ubuntu Jaunty 64-bit, Nvidia 9800 GTX). Virtual desktop has a couple failures in gdi32 (bug 12768) and some user32 tests, otherwise passes. +heap has a few failures: winmm/mci - http://bugs.winehq.org/show_bug.cgi?id=17518 mshtml/dom - http://bugs.winehq.org/show_bug.cgi?id=17520 oleaut32/tmarshal - http://bugs.winehq.org/show_bug.cgi?id=17412 netapi32/access - http://bugs.winehq.org/show_bug.cgi?id=17530 There were a few other bugs in crypt32, jscript, msi and user32, but AJ, Juan, and Jacek fixed those. Couple other related bugs: +relay qmgr/qmgr - http://bugs.winehq.org/show_bug.cgi?id=17521 +message comctl32/datetime - http://bugs.winehq.org/show_bug.cgi?id=17431 I had to find some way to keep y'all busy, since 32-bit winetest is passing now :-). -- -Austin
Re: Wine64 - msvcrt dll test fix
this was commited already today. :) http://source.winehq.org/git/wine.git/?a=shortlog 2009/2/18 Juan M. Navarro juan.m.nava...@gmail.com Resending as plain text. Thanks, Juan On Tue, Feb 17, 2009 at 12:19 PM, Juan M. Navarro juan.m.nava...@gmail.com wrote: Hello all! This is my first patch ever, and first open source contribution ever. The strlen function returns a size_t that represents an unsigned int in 32-bit environments, and an unsigned long in 64-bit environments. The strlen function call has been changed to an lstrlen function call, which always returns an integer. I am a grad student at UCLA that has just started working on porting Wine to 64-bit environments. I attest to not having seen any Microsoft source, or dissasembling Microsoft's DLL's. Thanks, Juan
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
On Wed, 2009-02-11 at 23:34 +0100, Alexandre Julliard wrote: Not really, you'll of course still need to build a full 32-bit version of Wine, the 64-bit Wine will never be able to run 32-bit apps. What needs to be improved is that the 64-bit loader should be able to forward automatically to the 32-bit one when encountering a 32-bit app. So there's no plans for implementing a clone of WoW64? smime.p7s Description: S/MIME cryptographic signature
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
Erik de Castro Lopo mle+...@mega-nerd.com writes: So there will need to be two executables wine and wine64 and if either is started with the wrong kind of binary, it will need to run the binary with the other version? Would it not be possible to have a single light weight binary that has just enough code to detect i386 vs amd64 and then execs either wine32 or wine64? sure, that would be possible. I don't know yet how it will be done, but that's a minor implementation detail. -- Alexandre Julliard julli...@winehq.org
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
2009/2/12 Joel Holdsworth j...@airwebreathe.org.uk: On Wed, 2009-02-11 at 23:34 +0100, Alexandre Julliard wrote: Not really, you'll of course still need to build a full 32-bit version of Wine, the 64-bit Wine will never be able to run 32-bit apps. What needs to be improved is that the 64-bit loader should be able to forward automatically to the 32-bit one when encountering a 32-bit app. So there's no plans for implementing a clone of WoW64? I would imagine that the end goal is to implement a side-by-side 64bit and 32bit wine, with some sort of wrapper to send the app to the appropriate version. From what I understand, this is what a WoW64 clone would look like anyway. See David's comment: 2009/2/12 David Gerard dger...@gmail.com: 2009/2/11 Erik de Castro Lopo mle+...@mega-nerd.com: I realise that the Win64 stuff is experimental but I'm curions, in the longer term is it expected that one executable will be able to run both Win32 and Win64 executables? Not yet. You're welcome to write it though ;-)
Wine64 : Trying to load PE image for unsupported architecture (I386)
Hi all, I build Wine64 using the instructions here: http://wiki.winehq.org/Wine64 While I expected it to not work with my Win64 program I was a little surprised that when running a WIn32 program I got: Trying to load PE image for unsupported architecture (I386) I realise that the Win64 stuff is experimental but I'm curions, in the longer term is it expected that one executable will be able to run both Win32 and Win64 executables? Cheers, Erik -- - Erik de Castro Lopo - J. Headley: God, root, what is difference ? G. Haverland: God can change the byte order on the CPU, root can't.
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
On Wed, Feb 11, 2009 at 3:00 PM, Erik de Castro Lopo mle+...@mega-nerd.com wrote: Hi all, I build Wine64 using the instructions here: http://wiki.winehq.org/Wine64 While I expected it to not work with my Win64 program I was a little surprised that when running a WIn32 program I got: Trying to load PE image for unsupported architecture (I386) I realise that the Win64 stuff is experimental but I'm curions, in the longer term is it expected that one executable will be able to run both Win32 and Win64 executables? Cheers, Erik -- - Erik de Castro Lopo - J. Headley: God, root, what is difference ? G. Haverland: God can change the byte order on the CPU, root can't. That functionality has not yet been implemented. Build 32bit wine for that. -- -Austin
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
2009/2/11 Erik de Castro Lopo mle+...@mega-nerd.com: I realise that the Win64 stuff is experimental but I'm curions, in the longer term is it expected that one executable will be able to run both Win32 and Win64 executables? Not yet. You're welcome to write it though ;-) - d.
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
Erik de Castro Lopo mle+...@mega-nerd.com writes: While I expected it to not work with my Win64 program I was a little surprised that when running a WIn32 program I got: Trying to load PE image for unsupported architecture (I386) I realise that the Win64 stuff is experimental but I'm curions, in the longer term is it expected that one executable will be able to run both Win32 and Win64 executables? Not really, you'll of course still need to build a full 32-bit version of Wine, the 64-bit Wine will never be able to run 32-bit apps. What needs to be improved is that the 64-bit loader should be able to forward automatically to the 32-bit one when encountering a 32-bit app. -- Alexandre Julliard julli...@winehq.org
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
Alexandre Julliard wrote: Not really, you'll of course still need to build a full 32-bit version of Wine, the 64-bit Wine will never be able to run 32-bit apps. Ok. What needs to be improved is that the 64-bit loader should be able to forward automatically to the 32-bit one when encountering a 32-bit app. So there will need to be two executables wine and wine64 and if either is started with the wrong kind of binary, it will need to run the binary with the other version? Would it not be possible to have a single light weight binary that has just enough code to detect i386 vs amd64 and then execs either wine32 or wine64? Erik -- - Erik de Castro Lopo - To iterate is human, to recurse divine. -- L. Peter Deutsch
Updated wine64 page
I updated http://wiki.winehq.org/Wine64 to no longer recommend pulling from Maarten's tree, since doing so made the instructions more complex, and the main tree does just about as good at passing conformance tests (maybe modulo a hang or two). - Dan
Re: Wine64 hello world app runs!
Hi Zach, Zachary Goldberg schreef: 2008/12/5 Maarten Lankhorst m.b.lankho...@gmail.com: ... So 9 days, a WWN article, and a Slashdot article this story's gotten a lot of press. I know we've talked a bit offline Maarten about this but would you perhaps have any other updates for readers at large? I know you've been mentioning a bit about getting +relay to work and messing with some intricacies in the AMD64 instructions. Kai Tietz and I have been working on squashing all gcc related bugs. Now that they are gone I'm moving on to other stuff. Right now I want to have +relay working so that debugging will be a bit easier to do. If this works then I will need to work on exception handling and moving menus to wineserver. I will also need to talk with AJ some more about what he exactly wants from wineserver for 64-bits compatibility. There's enough to do without even worrying about the WoW64 stuff, so more help is of course welcome. :) Cheers, Maarten.
Re: Wine64 hello world app runs!
2008/12/5 Maarten Lankhorst m.b.lankho...@gmail.com: Hi guys, I can finally report success on the first ever win64 program running on wine. The program was a textbook classic, but to make it work gcc had to be changed a lot. This was done by Kai Tietz, who has put a lot of effort in the task of making gcc accept the calling convention. There are still a lot of things which should be done before this will be able to get into mainline though. My repository is at http://repo.or.cz/w/wine/wine64.git , but in order to actually get it working you need gcc checked out from subversion with some experimental patches. They are expected to get merged soon, so until then it is not recommended to even try. :) There are a bunch of things in my tree which are not merged with mainline. A few of them are hacks (disabling SEGV handling for example). There are also some changes which should be accepted, but still need some work. For example wineserver, AJ wants something with regards to fd handling, but I didn't find him clear on what exactly. va_list also is incompatible, and should be replaced with ms_va_list where appropiate. Once again, thanks to Kai Tietz for making this possible. Cheers, Maarten. So 9 days, a WWN article, and a Slashdot article this story's gotten a lot of press. I know we've talked a bit offline Maarten about this but would you perhaps have any other updates for readers at large? I know you've been mentioning a bit about getting +relay to work and messing with some intricacies in the AMD64 instructions.
Wine64 hello world app runs!
Hi guys, I can finally report success on the first ever win64 program running on wine. The program was a textbook classic, but to make it work gcc had to be changed a lot. This was done by Kai Tietz, who has put a lot of effort in the task of making gcc accept the calling convention. There are still a lot of things which should be done before this will be able to get into mainline though. My repository is at http://repo.or.cz/w/wine/wine64.git , but in order to actually get it working you need gcc checked out from subversion with some experimental patches. They are expected to get merged soon, so until then it is not recommended to even try. :) There are a bunch of things in my tree which are not merged with mainline. A few of them are hacks (disabling SEGV handling for example). There are also some changes which should be accepted, but still need some work. For example wineserver, AJ wants something with regards to fd handling, but I didn't find him clear on what exactly. va_list also is incompatible, and should be replaced with ms_va_list where appropiate. Once again, thanks to Kai Tietz for making this possible. Cheers, Maarten.
Re: Wine64?
Roderick Colenbrander wrote: Maarten wrote: A lot of the lowest level stuff is currently missing. If you don't mind x64 assembly it's not impossible to do. We would need support from gcc for the windows calling convention, and making it possible to mix linux calling convention with windows calling convention. If you are up to it just make it ignore the error for now, even if it causes errors. A proof of concept Hello, world! would be a great accomplishment at this point. These days there is a 64bit version of mingw (mingw64 or so it is called). They must have patches to add the calling convention to gcc now. I'm not sure what the status is on merging the changes back but I think nothing forbids you from building gcc from their sources. I have no idea whether having the calling convention is enough for Wine. The changes have been applied to gcc trunk, about a year ago IIRC. Regarding mixing conventions, I had the following discussion with the developer who implemented the convention in gcc (I didn't pursue the matter further, though): Kai Tietz wrote: Anssi Hannula [EMAIL PROTECTED] wrote on 26.05.2007 13:03:38: However, as the Wine project needs to support running win64 binaries on x86_64 Linux platforms, we need to able to specify MS ABI in per-function basis as we call linux functions as well. I.e. we'd need something like __attribute__(__msvccall__) to specify the functions that need to have MS ABI calling convention, even when the gcc target is not x86_64 mingw. Do you think this is possible and/or if it would hard to implement? This shouldn't be very hard to do. In i386.c, where the ABI specific calling conventions are done, it can be introduced easily by using an attribute modifier to choose between the different calling conventions AFAICS. -- Anssi Hannula
Re: Wine64?
Hello Erik, 2008/4/21, Erik de Castro Lopo [EMAIL PROTECTED]: Hi all, I'm interested in the current state of work towards Wine64, ie running Win64 binaries on x86_64 Linux machines. My needs are actually really simple and hence may be a good base functionality to work towards. I just need to run Win64 binaries that read stdin, write stdout/stderr and do file I/O using the standard windows CreateFile/ReadFile/WriteFile/CloseHandle/ SetFilePointer etc functions. I have found and read this: http://wiki.winehq.org/Wine64 but some of that stuff seems rather out-of-date. When I configure with --enable-win64 it configures fine but then errors out in widl generated code because of things like this: #if !defined(__RPC_WIN32__) #error Currently only Wine and WIN32 are supported. #endif So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list? Any way for me to get involved? A lot of the lowest level stuff is currently missing. If you don't mind x64 assembly it's not impossible to do. We would need support from gcc for the windows calling convention, and making it possible to mix linux calling convention with windows calling convention. If you are up to it just make it ignore the error for now, even if it causes errors. A proof of concept Hello, world! would be a great accomplishment at this point. Cheers, Maarten. These days there is a 64bit version of mingw (mingw64 or so it is called). They must have patches to add the calling convention to gcc now. I'm not sure what the status is on merging the changes back but I think nothing forbids you from building gcc from their sources. I have no idea whether having the calling convention is enough for Wine. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Wine64 : initializer element is not computable at load time?
Hi all,
I'm compiling wine on x86-64 after configuring with --enable-win64
and I get the error:
irotp.c:54: error: initializer element is not computable at load time
irotp.c:54: error: (near initialization for 'critsect_debug.Spare[0]')
on this this code:
51: static CRITICAL_SECTION_DEBUG critsect_debug =
52: {
53:0, 0, csRunningObjectTable,
53:{ critsect_debug.ProcessLocksList, critsect_debug.ProcessLocksList
},
54: 0, 0, { (DWORD_PTR)(__FILE__ : csRunningObjectTable) }
55: };
Anybody understand why?
Cheers,
Erik
--
-
Erik de Castro Lopo
-
I'm not even an atheist so much as I am an antitheist; I not
only maintain that all religions are versions of the same
untruth, but I hold that the influence of churches, and the
effect of religious belief, is positively harmful.
-- Christopher Hitchens in Letters to a Young Contrarian 2001
Re: Wine64 : initializer element is not computable at load time?
Erik de Castro Lopo skrev: Anybody understand why? You could look up the definition of RTL_CRITICAL_SECTION_DEBUG in include/winnt.h. Then realize that __WINESRC__ is only defined for stuff in dlls/, not for stuff in programs/, which should make the type mismatch clear.
Re: Wine64 : initializer element is not computable at load time?
Ove Kaaven wrote:
Erik de Castro Lopo skrev:
Anybody understand why?
You could look up the definition of RTL_CRITICAL_SECTION_DEBUG in
include/winnt.h. Then realize that __WINESRC__ is only defined for stuff
in dlls/, not for stuff in programs/, which should make the type
mismatch clear.
The error message says nothing about a type mismatch its complaining
about something not being compulatble a load time.
In include/winnt.h we have:
#ifdef __WINESRC__ /* in Wine we store the name here */
DWORD_PTR Spare[8/sizeof(DWORD_PTR)];
#else
DWORD Spare[ 2 ];
#endif
and the code tries to initialize Spare with this:
{ (DWORD_PTR)(__FILE__ : csRunningObjectTable) }
That makes me suspect that the non __WINESRC__ definition
is wrong and that the whole #ifdef above could be replaced
with
DWORD_PTR Spare[8/sizeof(DWORD_PTR)];
Is that right?
Erik
--
-
Erik de Castro Lopo
-
Copyrighting allows people to benefit from their labours,
but software patents allow the companies with the largest
legal departments to benefit from everyone else's work.
-- Andrew Brown
(http://www.guardian.co.uk/online/comment/story/0,12449,1387575,00.html)
Re: Wine64 : initializer element is not computable at load time?
Erik de Castro Lopo skrev: Ove Kaaven wrote: Erik de Castro Lopo skrev: Anybody understand why? You could look up the definition of RTL_CRITICAL_SECTION_DEBUG in include/winnt.h. Then realize that __WINESRC__ is only defined for stuff in dlls/, not for stuff in programs/, which should make the type mismatch clear. The error message says nothing about a type mismatch its complaining about something not being compulatble a load time. Yes, I said type mismatch to clarify the error. It's not possible to fit a 64-bit pointer value into a static 32-bit DWORD at load time (probably means relocation time). The types aren't compatible. That makes me suspect that the non __WINESRC__ definition is wrong and that the whole #ifdef above could be replaced with DWORD_PTR Spare[8/sizeof(DWORD_PTR)]; Is that right? No, in the case of Winelib apps, every Wine definition should match the Windows definition exactly. And here, DWORD_PTR would be 64-bit and DWORD would be 32-bit, so it's not exactly a perfect match. But I'm not proposing any particular solution, I just said what's wrong.
Wine64?
Hi all, I'm interested in the current state of work towards Wine64, ie running Win64 binaries on x86_64 Linux machines. My needs are actually really simple and hence may be a good base functionality to work towards. I just need to run Win64 binaries that read stdin, write stdout/stderr and do file I/O using the standard windows CreateFile/ReadFile/WriteFile/CloseHandle/ SetFilePointer etc functions. I have found and read this: http://wiki.winehq.org/Wine64 but some of that stuff seems rather out-of-date. When I configure with --enable-win64 it configures fine but then errors out in widl generated code because of things like this: #if !defined(__RPC_WIN32__) #error Currently only Wine and WIN32 are supported. #endif So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list? Any way for me to get involved? Cheers, Erik -- - Erik de Castro Lopo - If you have one apple and I have one apple, if we exchange, each will have one apple. If you have one idea and i have one idea, if we exchange them, each will have two ideas! -- Attributed to George Bernard Shaw
Re: Wine64?
Hello Erik, 2008/4/21, Erik de Castro Lopo [EMAIL PROTECTED]: Hi all, I'm interested in the current state of work towards Wine64, ie running Win64 binaries on x86_64 Linux machines. My needs are actually really simple and hence may be a good base functionality to work towards. I just need to run Win64 binaries that read stdin, write stdout/stderr and do file I/O using the standard windows CreateFile/ReadFile/WriteFile/CloseHandle/ SetFilePointer etc functions. I have found and read this: http://wiki.winehq.org/Wine64 but some of that stuff seems rather out-of-date. When I configure with --enable-win64 it configures fine but then errors out in widl generated code because of things like this: #if !defined(__RPC_WIN32__) #error Currently only Wine and WIN32 are supported. #endif So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list? Any way for me to get involved? A lot of the lowest level stuff is currently missing. If you don't mind x64 assembly it's not impossible to do. We would need support from gcc for the windows calling convention, and making it possible to mix linux calling convention with windows calling convention. If you are up to it just make it ignore the error for now, even if it causes errors. A proof of concept Hello, world! would be a great accomplishment at this point. Cheers, Maarten.
