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."

Comments

GCC changes

[JohnFluxx]

Hmm, it required changes to GCC.

Anyone know why?

Re:GCC changes

[Bromskloss]

What are the Windows and Linux calling conventions?

Re:GCC changes

[shutdown -p now]

What are the Windows and Linux calling conventions?

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.

LUK

[Artem S. Tashkinov]

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.

Re:LUK

[Anonymous Coward]

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

[Mitchell Mebane]

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:LUK

[shutdown -p now]

It's what Lindows was until MS sued them into the ground

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:LUK

[Al Dimond]

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.

Huzah!

[DoofusOfDeath]

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.

bad move

[Anonymous Coward]

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

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:bad move

[Mr Z]

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:bad move

[Mr Z]

It has nothing to do with pins dude. The TLB on just about every AMD64/IA64 chip can do a full 64 bits.

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:

AMD therefore decided that, in the first implementations of the architecture, only the least significant 48 bits of a virtual address would actually be used in address translation (page table lookup). However, bits 48 through 63 of any virtual address must be copies of bit 47 (in a manner akin to sign extension), or the processor will raise an exception. Addresses complying with this rule are referred to as "canonical form." Canonical form addresses run from 0 through 00007FFF`FFFFFFFF, and from FFFF8000`00000000 through FFFFFFFF`FFFFFFFF, for a total of 256 TB of usable virtual address space.

On to your next point...

It's not uncommon to address 1TB of physical memory on very high end servers. That's 40 bits right there. Now imagine you're building a nice big cluster of these machines. You want to assign a different address to every byte of physical memory. You may not be able to afford more than 1024 machines right now, but you'd sure like to in the future.

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.

Re:Does it run

[eihab]

...Cygwin? Hah! Tricked you!

As a matter of fact it did in 2002, might still be the case.

Darwine : Wine for PPC

[DrYak]

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.

Thank God.

[Samah]

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?

[canadiangoose]

You can run wine through qemu. I tried it on an old G4 mac. It was slow.

Re:Who really uses it though ?

[Hal_Porter]

That's like escaping from prison and then spending all your time in a small basement apartment.

Re:PowerPC arch? PlayStation 3?

[Guspaz]

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: impressive compatibility list

[shutdown -p now]

Besides, there are absolutely no ABI problems with open-source programs. And if you respond by saying that Linux needs this closed-source binaries then again, you would understand Linux wrong. We manage pretty good ourselves.

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.