Slashdot Mirror
Wine Goes 64-Bit With Wine64
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."
Hmm, it required changes to GCC.
Anyone know why?
Wine introduces quite a big overhead when running memory intensive applications so I think Linux Unified Kernel is what really needs attention. With this project you can use unmodified core Windows libraries thus getting the best possible compatibility.
I was going to joke that a game I've wanted to work in Wine for a long time, Astral Masters, 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.
...Cygwin? Hah! Tricked you!
As a matter of fact it did in 2002, might still be the case.
If you can't mod them join them.
As explained by other /.ers, running Wine on non-x86 architectures would require an additional emulator.
Darwine - 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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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. :)
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
You can run wine through qemu. I tried it on an old G4 mac. It was slow.
Never eat more than you can lift -- Miss Piggy
That's like escaping from prison and then spending all your time in a small basement apartment.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
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.
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? :-)
Program Intellivision!
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). 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.
Program Intellivision!