In the (distant) future, will we support building Wine with both 64 bit and 32 bit libraries, and then the same Wine installation will run both 64 bit and 32 bit apps? As I understand it, this is the way Windows does in its 64 bit versions.
I ask because there's a question of how to name the Wine packages for the 64 bit distribution - there's a standard of naming 32 bit packages something like "wine32", but if we're eventually going to have a unified multiarch package then we can still go with just keeping it as "wine"
Thanks, Scott Ritchie
On 5/2/07, Scott Ritchie scott@open-vote.org wrote:
In the (distant) future, will we support building Wine with both 64 bit and 32 bit libraries, and then the same Wine installation will run both 64 bit and 32 bit apps? As I understand it, this is the way Windows does in its 64 bit versions.
I ask because there's a question of how to name the Wine packages for the 64 bit distribution - there's a standard of naming 32 bit packages something like "wine32", but if we're eventually going to have a unified multiarch package then we can still go with just keeping it as "wine"
Its an interesting question. Do we rebuild everything twice and package it once? What if you've got a 64bit app that expects to be able to CreateProcess on a win32 application for legacy purposes and let the Windows loader figure it out? How is wineserver going to handle that? I agree with making separate packages like wine32 and wine64 as we try very hard to emulate mingw32 when it comes to source porting so it makes since to have the package name and platform names follow the same standard.
On Wed, 2007-05-02 at 21:54 -0400, Steven Edwards wrote:
On 5/2/07, Scott Ritchie scott@open-vote.org wrote:
In the (distant) future, will we support building Wine with both 64 bit and 32 bit libraries, and then the same Wine installation will run both 64 bit and 32 bit apps? As I understand it, this is the way Windows does in its 64 bit versions.
I ask because there's a question of how to name the Wine packages for the 64 bit distribution - there's a standard of naming 32 bit packages something like "wine32", but if we're eventually going to have a unified multiarch package then we can still go with just keeping it as "wine"
Its an interesting question. Do we rebuild everything twice and package it once? What if you've got a 64bit app that expects to be able to CreateProcess on a win32 application for legacy purposes and let the Windows loader figure it out? How is wineserver going to handle that? I agree with making separate packages like wine32 and wine64 as we try very hard to emulate mingw32 when it comes to source porting so it makes since to have the package name and platform names follow the same standard.
But why have separate packages if the problem lies in wineserver? Once we figure out how to make wineserver intelligently handle the issue, then we can package the apps together. Until then, we're best off packaging just the 32 bit version, since we can't have two wineservers for two different packages.
Thanks, Scott Ritchie
Scott Ritchie scott@open-vote.org writes:
But why have separate packages if the problem lies in wineserver? Once we figure out how to make wineserver intelligently handle the issue, then we can package the apps together. Until then, we're best off packaging just the 32 bit version, since we can't have two wineservers for two different packages.
At the Wine level there's no specific requirement, it should support either one package or two, that's really up to you and to the packaging guidelines for the target platform. All Wine will need is to know where the files are, so the loader and tools know where to find the 32-bit libraries, and the 32-bit loader knows where to find the 64-bit wineserver.
-
Alexandre Julliard -
Scott Ritchie -
Steven Edwards