[aur-general] moving winw-wow64 into community
The package-magician heftig managed to put together a wine-wow64 package which is currently in AUR and enables users to not only run 32bit Windows application on x86_64 Arch like bin32-wine but also 64bit Windows applications. Basically, it contains a 32bit and 64bit Windows environment to do this, a lot like native 64bit Windows installations do, in fact. We'd like to see this package replace bin32-wine in community. It is currently rather untested and before moving we'd like to ask the Arch community to test it first. Before we ask for the test though we first wanted to hear the dear opinions of this mailing list's fine gentlemen. Sadly, using it also implies moving a bunch of lib32s and the cross32 chain into community. This will be a problem for some people. To summarize: wine-wow64 is like bin32-wine but with the ability to run 64bit applications. -- Sven-Hendrik
On Sat, Jul 17, 2010 at 5:54 PM, Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
Great, more windows bloat in the community.
I hate any kind of lib32-* package and moving more to community will just make me grr.
To summarize: wine-wow64 is like bin32-wine but with the ability to run 64bit applications.
Aren't windows applications almost all 32bit? I remember reading somewhere that most applications for 64 bit windows are still 32 bit.
-- Sven-Hendrik
It's not you, it's wine-wow64 :P
On Sat, Jul 17, 2010 at 17:17, Thomas Dziedzic <gostrc@gmail.com> wrote:
Well, consider it from this perspective: The purposed wine-wow64 would (if it proves to reliably serve all purposes the other did) replace bin32-wine, which is now in [community]. And while you may dislike it, it's certainly better than a bin32-*!
On 07/17/10 18:54, Sven-Hendrik Haase wrote:
Can the magic used by heftig to make "wine-wow64" also alternatively be used to improve* the "bin32-wine" pkgbuild's functionality without adding the 64bit functionality? Just curious. *Since the 'improvement' would depend on a bunch of lib32s/cross32, some would think it's not an improvement. I don't personally mind having those things in community (I don't think all the packages in [community] have to represent a unified philosophy, as long as they don't break each other! These packages don't stop you from having a chroot, and neither do they force you to install them if you don't want anything 32bit on your system.)
To summarize: wine-wow64 is like bin32-wine but with the ability to run 64bit applications.
Why is it called "wow64"? Why not something descriptive like "wine-32-and-64" or "wine" ? In particular does it have anything fundamentally to do with "wow" (I guess that's "world of warcraft"?) -Isaac
On Sat, Jul 17, 2010 at 20:49, Isaac Dupree <ml@isaac.cedarswampstudios.org> wrote:
http://en.wikipedia.org/wiki/WoW64 :) -- Ranguvar [Devin Cofer]
On 07/18/10 01:26, Ranguvar wrote:
...wow. (a bad pun to express how I feel about that naming. But:) Thanks for that link, it actually explains what wine-wow64 is doing a bit better than I was able to make sense of from the original message... this wine-wow64 is copying some particular oddity of Windows 64! (I wonder, Maybe it could still be called just "wine" though..I haven't been tracking upstream Wine closely enough to see what their thoughts on 64-bit have been recently. But, not if "wine" refers to a wholly different package in Arch Linux (i686 only - which I can't find out much about because I've never had an i686 Arch system but I thought something fishy was going on - normally packages are equally available on all two arches)) oh, so more info at http://wiki.winehq.org/Wine64 , it says 64bits version "is not yet fully functional", and for 32bit part of WoW64 "The 32-bit side of such a Wow64 build is in theory supposed to work identically to a stand-alone 32-bit build. Currently this is not quite the case, any help is welcome." so... it may not be ready to replace bin32-wine if the upstream wiki-page is up-to-date (last edit this April..so maybe it is)
On 18.07.2010 09:10, Isaac Dupree wrote:
though. I suggested we have the community test these first and I stepped ahead and made a forums post (https://bbs.archlinux.org/viewtopic.php?pid=793962#p793962), too. I'd say that if testing evidence shows that it is indeed too immature then the decision should be a quick one. However, if it turns out to be working quite well, the only thing holding this back is inclusion of the dependencies which we are also discussing on this list. -- Sven-Hendrik
participants (4)
-
Isaac Dupree
-
Ranguvar
-
Sven-Hendrik Haase
-
Thomas Dziedzic