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?
How the hell are we supposed to know what that means?! I would've named it Beer.
--- We need more Ron Paul!
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.
...Cygwin? Hah! Tricked you!
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.
Not that impressive, unless all you want to do is game. If adding an application to its compatibility list is just a popularity contest, and it seems that is all that it is, of course the fan boys interested in games will vote the most. Others will just use the 'other' operating system to run applications that they need to use in order to make a living (since they won't be able to outvote fanatic gamers). Linux/Gnu has to relax more, not less, in order to allow people to NOT have to rely on some emulator or flaky reverse engineering to make business tools work. Relax on APIs so that it is easier to port business applications over to Linux. Until that time there will never be a 'year of the Linux desk top'. People just want to use their tools, not build them.
-- I ignore anonymous replies to my comments and postings.
Sounds more like 'expectedly' to me....
So you think you can messss with /. ?
Don't hold your breath, because WINE Is Not an Emulator. Unless you've got some PPC Windows programs around, that is. It doesn't emulate the x86, just intercepts the OS and library calls.
-- Alastair
It looks as though Linux users will have native 64-bit Windows applications before most Windows users.
Getting Wine to run on a processor architecture not native to Windows would require emulating an x86 processor. Say it with me: Wine Is Not an Emulator.
You can use Wine's libraries to recompile Windows applications to run on other architectures, such as PowerPC. But you can't use it to run unmodified Windows binaries on those, since they are native x86 code and an x86-emulator is beyond the scope of WINE. It's chiefly is focused on implementing the APIs.
most apps will run on most platforms without extra work. Or so I hope (desktop or notebook, don't see a way to make a destop app fit on a phone w/o work). They'll have an interpreted code, like lisp, which gets compiled (once, not at runtime) for whatever specific platform it's actually running on. It can be fast, doesn't have to be slow this way.
So it won't actually be like a script. Java tried to be this universal gateway, but it just never really took off for real apps like a language should. Various libraries like QT attempted to overcome the problem. Then there is the POSIX standard, which wouldn't be bad if it was really followed.
I just feel it's ridiculous in this day and age being tied to windows/unix/os x/some operating system because of an app made for it. It seems backwards. It's like being tied to route 66 because that's the only road your car will drive on.
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.
Every time I read about Wine, I shrug and/or roll my eyes. I've tried many times to use it, but it simply does not work for the handful of Windows apps I actually need. I gave it another try just a few months ago, and I was again left high and dry, so I turned yet again to virtual machines. At this point, I have stopped caring about the project.
For the inevitable flamers among you, here's the short list of Windows apps I need, that Wine fails to support:
- Photoshop CS3
- Office 2007
- MSIE 6/7
IE6 runs, sure, but leaks memory like there's no tomorrow, so I have to kill -9 it after a few minutes lest I face a swap-spiral of doom. And don't try to tell me to use The Gimp and OO.o, I don't need "A photo editor" and "An office suite", I need those specific apps because those are the formats my peers and clients use. If it were just me in my little bubble, I'd be quite happy with unbranded alternatives, but my rent doesn't pay itself.
Now one would think that these major apps would be high on the priority list, as I'm hopefully not the only (commercial) web guy trying to use Linux as a serious desktop, and getting them to run perfectly would effectively make Windows redundant for a large number of people, not just web devs. I find it puzzling that Wine can run something like World of Warcraft, but not MS Outlook. Don't get me wrong, I loves me some Warcrack, but it doesn't pay my bills.
-Billco, Fnarg.com
I don't agree w/ Eric on this one. The shift from 32-bit to 64-bit systems has been darn near seamless as compared to previous transitions. That's a far cry from the 8-to-16 jump or the 16-to-32 jump.
Honestly, most people can't tell that they've shifted from 32-bit to 64-bit. If there wasn't a dialog box or a sticker that told them they'd switched, they wouldn't know.
Now this wouldn't be /. without a bad car analogy. Going from 8-bit to 16-bit was like going from horse-drawn buggies to the early Model Ts--a big change. Going from 16-bit to 32-bit was like going from these early, slow cars to the more recognizable cars of the 30s onward. Cars that actually had starters and drove at reasonable speeds. Each step provided a noticeable difference in the travel experience and it brought with it a whole new round of infrastructure requirements.
Going from 32-bit to 64-bit is like going from a gasoline engine to a hybrid. Sure, it's a change in the underlying mechanism, but it doesn't fundamentally change the driving experience all that much.
Program Intellivision!
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
You're looking for the Darwine project: http://sourceforge.net/projects/darwine/
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
The highest voted productivity app was Flash.
Not to far down was Microsoft Money 2004 plus a whole bunch of (Installer Only) entries.
Think of the leaps forward Linux would be if the developers of Wine realized how pointless Wine is (should have figured it out about 8 years ago when VMware came out) and spent their skill developing programs that could compete with mainstream applications.
For asking about something which you are unfamiliar.
Such an attitude is refreshing, usually you just run into folks like the AC below who are a-holes.
However the link provided down below in this thread is a great place to start reading. Have fun!
I am very small, utmostly microscopic.
Which supports all of the above for a small cost.
Any dollar NOT spent on Microsoft makes the world a better place.
you had me at #!
Games don't need >4GB memory addressing most of the time.
Most don't, but some do. By default, Windows uses a 2GB/2GB split. That means that an application can't use more than 2GB of RAM before it gets into trouble.
Supreme Commander is an RTS game that is rather CPU intensive. It does a lot of simulation that a lot of other games don't bother with (such as doing actual 3D hit detection on every single bullet fired by every single unit). It'll fully saturate even a decently powerful dual core processor. And it also is a heck of a RAM hog.
When Supreme Commander hits that 2GB limit, it crashes. This actually became a rather large problem, especially under Vista. Now, for Vista, it turned out that Windows was allocating the virtual VRAM out of the application's 2GB allotment, often bringing the actual available memory down to 1.5GB or less (which caused frequent failures in most larger games).
Anandtech actually did an article on that, and Microsoft eventually released an update for Windows that moved the virtual VRAM out of the application's memory space to deal with the problem. However, that doesn't completely fix the issue; you've still got that 2GB limit.
And so, there are ultimately two solutions to the problem. One, is you tell Windows to switch the user/kernel split from 2/2 to 2.5/1.5 or something similar. That gives SupCom another gig to play with, which should resolve the issue in the majority of cases. Problem is, Windows doesn't always like that, so there can be side effects (BSoDs). Windows also won't boot at the 3/1 split used by Linux. This solution does require patching the SupCom EXE, though, to enable large addressing.
The other solution is to run SupCom on a 64-bit installation of Windows. There, a 32-bit application is allowed to use the full 4GB, which is enough to not run into the issue. The same modified executable as above can then be used.
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.
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!
Low memory prices started the rapid uptake of Vista 64 in about April. This trend has continued. 64-bit will be the default setup for ISVs by next year when Windows 7 comes out (though it will be available in both 32 and 64 bit versions). Windows 8 is said to be 64 bit only. Win7 will promote 64-bit during the transition.
Agree with the Win6.5 comment, though.
Put identity in the browser.
It's documentation is one of the bests among distros. They cover not only installation, but deep customization and administration too.
Every Linux/Unix admin should read/install this at least once.
- Human knowledge belongs to the world
f**k the committee, I'll fork my own sarcasm!
It has nothing to do with pins dude. The TLB on just about every AMD64/IA64 chip can do a full 64 bits. The OSs are just written by people with no vision. 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. That's 50 bits we're up to. How about assigning a different address to every bit in secondary storage? Them Google folks have 200 petabytes of storage space right? That's about 58 bits of address space. It's not hard to imagine that doubling every 12 months for 8 years..
How we know is more important than what we know.
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!