Wine Goes 64-Bit With Wine64 385
G3ckoG33k writes "Wine (Wine Is Not an Emulator) is a popular way to run Windows programs on Linux, and it has an impressive compatibility list. After 15 years of development it reached version 1.0 a few months ago. Now, Wine developer Maarten Lankhorst has succeeded in running 'Hello World' in 64-bit, natively! The 64-bit variety is unexpectedly named Wine64."
GCC changes (Score:5, Interesting)
Hmm, it required changes to GCC.
Anyone know why?
LUK (Score:3, Interesting)
Huzah! (Score:5, Interesting)
I was going to joke that a game I've wanted to work in Wine for a long time, Astral Masters [astralmasters.com], will still not work, but in a more glorious way.
But that joke felt petty. The truth is, these guys have pulled of something pretty amazing. Congrats, guys.
Re:GCC changes (Score:5, Interesting)
What are the Windows and Linux calling conventions?
bad move (Score:1, Interesting)
Wine development continues its streak of bad decisions. Well, bad for people who want to see Free Software becoming more mainstream.
I do not usually agree with ESR, but in this case I do: they should concentrate their efforts to support win32 better, not win64:
http://catb.org/esr/writings/world-domination/world-domination-201.html [catb.org]
By being serious about win32 application support, wine could be the biggest opportunity for the free software community to migrate many Windows users to free alternatives.
Being serious about win32 app support means considering all applications important, in order to get a functional win32 layer for most of the huge amount of applications out there. Their current strategy of getting the new "cool" app supported while breaking old *working* apps is doomed.
Doomed for our goal, of course. For codeweavers, who nowadays pulls the strings of the wine project, a semi-working-but-not-just-working layer is just what they need to be able to keep win32 around forever, and keep selling support.
Re:LUK (Score:4, Interesting)
you know what would be really cool? a linux distro that focused *only* on wine, and windows programs.
i mean the absolute minimum you could possibly have to get a usable wine session - no underlying desktop environment, no python, no perl, no bsh/zsh/csh, no headers, just the kernel, wine, and popular windows freeware like 7-zip, utorrent, ffdshow, media player classic, dvdshrink, firefox.. a complete replacement for windows that actually runs software that people want and are already familiar with.
no, i don't want to install a 4.5gb distro. i want linux without all the bloat from crap i'll never ever want nor need to run the windows programs i like, and not the painfully different and bizarrely bloated linux versions.
i'd run this in a heartbeat.
how sad and hilarious, right now i use nothing but open source software on windows, and my footprint is MUCH less than linux to do the same. i tried to install the smallest linux distro i could and still get a usable wine session.. 1gb worth of software later i'm up to the point that xp can do with 250mb.
Re:LUK (Score:3, Interesting)
Recent development versions (1.1.8 and 1.1.9) had some improvements to memory management. Do you know if there still is "quite a big" amount of overhead?
Re:Does it run (Score:5, Interesting)
...Cygwin? Hah! Tricked you!
As a matter of fact it did [slashdot.org] in 2002, might still be the case.
Darwine : Wine for PPC (Score:3, Interesting)
As explained by other /.ers, running Wine on non-x86 architectures would require an additional emulator.
Darwine [sourceforge.net] - a port of Wine to darwin/mac OS X, does indeed feature such an additional layer :
it uses a special mode of QEMU initially designed to run linux-on-linux (i.e.: not emulating a complete virtual machine with a full OS running on it, but just run a program alone inside the emulator and pass it calls to the actual OS outside).
The only problem is that now that Apple have moved to Intel hardware, the main incentive for Darwine has disappeared, and I don't know if there enough motivated owners of PS3 to keep the project alive or if the development has stalled.
Thank God. (Score:3, Interesting)
This is the only reason I gave up on Ubuntu 64. There was a strange bug in Wine to do with application focus that was causing WoW to lose sound occasionally. There was also a patch (which I had no problems applying), but of course I needed to cross-compile to get it to work. I'm really not versed in that enough and so I had no end of problems getting it compiling. My only choice was to wait until the next version of Wine was released and an awesome person would throw it in the Debian repository.
I may give it another shot now if I can ever get push-to-talk working with Ventrilo. :)
Re:PowerPC arch? PlayStation 3? (Score:3, Interesting)
Re:Who really uses it though ? (Score:3, Interesting)
That's like escaping from prison and then spending all your time in a small basement apartment.
Re:PowerPC arch? PlayStation 3? (Score:3, Interesting)
I believe that this is also how Executor worked. It's a (now opensourced) Macintosh emulator that worked by translating Mac toolbox and quickdraw calls into native calls, and emulated the Mac's MC680x0 processor for the rest.
In that regard, it's very similar to QuickTransit (Rosetta) or Darwine. While compatibility wasn't perfect, it was enormously faster than Basilisk II.
Executor was eventually largely made irrelevant both by the continuing switch of the Mac to the PowerPC platform, and by the fact that advances in processing power rapidly made it possible to provide faster-than-real-time full-system emulation of a 68k Mac without the compatibility issues that Executor suffered from. Nonetheless, it was terribly impressive back in the day.
Re:LUK (Score:3, Interesting)
Not really. They made "Windows applications compatible" a major advertising point before the very first release, but it certainly didn't mean what GP described (i.e. not running any Linux UI applications at all); and, as I recall, they abandoned the idea very quickly (Wine was much less usable back then).
Re: impressive compatibility list (Score:3, Interesting)
Oh, really?
Here's an idea for a Slashdot poll: "how many binary closed-source Linux drivers do you use?"
Then again, I guess nvidia & fglrx alone will be enough to make a majority of users.
Re:LUK (Score:4, Interesting)
I run Linux at home and Windows at work, and seem to spend an increasingly large portion of my time on either platform in Firefox. Firefox works better on Windows than Linux. Embedded media that's automatic on Windows gives me a "plug-in needed" notification and a link to a page with nothing useful on it on Linux. I haven't had to do it for a while, but last I remember helper application selection was done in a way that made absolutely no sense on Linux.
Lots of programs have quirky GUI layout and proportion issues on Linux but not on Windows... I think a lot of that has to do with font rendering, which is largely out of the programs' control. But to some degree it's harder in X because there's a better chance that the DPI will be set to what it actually is instead of fixed to one of two allowed artificial values.
Windows GUIs are getting harder to make, though, because the programming style suggested by current VS versions and languages (as compared to old-school VB) is getting more and more complicated, and forcing more stuff into programmers' minds at once instead of less. Not to mention that you have to worry about more imperative concerns now while laying out forms, which really ought to be a declarative process (and mostly is in old VB... more accurately, you don't have to worry about your code being executed in design mode unless you really want it to). I should note that I don't have tons of GUI programming experience, these are just impressions formed from working with a few VB5 projects and a few VS projects at work.
Re:bad move (Score:3, Interesting)
I actually wouldn't be surprised if user space stayed 32 bit (or mostly 32 bit) for a very long time. The one thing Intel got right with the 386 is that its protected mode allowed for a mixture of 16-bit and 32-bit program contexts. AMD continued this tradition with x86-64. It's possible to have a 64-bit kernel with 32-bit user space applications. (Indeed, I've been tempted to set up a Linux machine that way in the past--put a 64-bit kernel under a 32-bit install.)
See, it seems reasonable that a 32-bit OS kernel will not handle more than a few gigabytes of RAM as efficiently as a 64-bit OS kernel. By default, 32-bit Linux puts memory over the 960MB mark into a "highmem" pool that's less efficient. It wouldn't surprise me if Windows does something similar. I'm less familiar with its VM and its limitations, although I recall hearing rumblings about XP and a 2GB limit. (Note: I haven't looked into it and could be talking out of my ass there about XP.)
So, to utilize gobs of RAM efficiently, it seems like you at least ought to have a 64-bit kernel. But what about user space?
It's the rare application that needs even a gigabyte mapped directly into its own process space. (That's different than needing a machine with 1GB installed.) Rather, a large amount of RAM goes to gobs of disk buffering, supporting parallel processes (eye candy for the display, virus scanners, the desktop GUI, etc), and so on. Unless you're doing video editing or some other sort of heavy media application, you're mostly just using the RAM to enable multitasking with lots of disk buffering. That means that apps can stay 32-bit for quite awhile, but still benefit from a 64-bit system. It's similar to how 16-bit Windows apps benefited from 386 Enhanced mode in Windows 3.x.
I suspect that'll be the key characteristic of the 32-bit to 64-bit shift. Most apps will remain 32-bit for quite some time. For many, this is the most efficient choice. Databases and media editing applications will make the jump first, once the kernel's stable. Everything else will trickle in over the next decade.
I predict that the single biggest improvement the 64-bit OS will bring to the desktop is editing one's home movies. Other than that, I don't expect much "wow." We've come a long way from an Amiga, a Video Toaster and a VCR. Or have we? :-)
Re:GCC changes (Score:3, Interesting)
Linux (and other OSes) uses the calling convention as specified and standardized in the original AMD64 design documents by AMD. Microsoft decided to invent their own instead, as usual. Which is a real pity, as the original intent (I believe) was to have a single unified calling convention for the platform from the very beginning.
Re:bad move (Score:3, Interesting)
Bull. The AMD64 TLB only gives you 48 bits for now, partitioned into half for the OS (0xFFFF800000000000 to 0xFFFFFFFFFFFFFFFF), and half for user (0x0000000000000000 to 0x00007FFFFFFFFFFF). [wikipedia.org] And I quote:
On to your next point...
And I'm failing to see the relevance. This thread, when it started, was about 64-bit desktops.
Now, you're right in the server and high-end compute space. I recall reading some of the Linux kernel guys (either Ingo Molnar or Andi Kleen, IIRC) saying that 48 bits will only hold us for around a decade, if that. Large Altix boxes are already pushing on the 48-bit mark. But that's for the very high-end server stuff. In the home space, I think you'll see the compute capacity level off for most things, and the devices will start to shrink. The only exception might be home media servers, and there it's more a matter of disk space, not RAM.