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!
Sounds more like 'expectedly' to me....
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!
Because XP64 was so much trouble...
Seriously, though, what kind of Windows 64-bit compatibility is provided, XP or Vista?
^[:q!
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.
I hope they eventually get Wine working for the PowerPC processors, so I can run some Windows only programs on my PS3...
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.
It looks as though Linux users will have native 64-bit Windows applications before most Windows users.
I love the name. This reminds me of the good old nintendo 64 era and the hope I had... and lost...
Damn, I hate the name.
I hope wine (both 32 & 64) puts a dent in microsoft's revenue and userbase...
Politics is Treachery, Religion is Brainwashing
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.
FTA:
The author needs to get out more. If they'd wanted real unexpected, going for Wine9+4i would have been a true eye-opener. It's certainly going to be complex enough...
"Little does he know, but there is no 'I' in 'Idiot'!"
Consider developing cross platform software when you have a MS Windows based application as your starting point. There are some MS Windows applications that are written to make sure that they will also run with wine - for instance the geophysical program SeiSee. They didn't have to rewrite the whole thing for a linux etc version.
From that perspective it is a very good descision and it makes it a lot easier for individuals or small groups to put together software that will at least run on everything with an x86.
What's misleading? After all, it's not an emulator. It just intercepts system and library calls (see the above discussion on PPC).
Everybody knows the failure of Windows XP x64.
Most Vistas out there are still x86 only.
I have Vista x64 for gaming but guess what? Nobody cares.
So, what's the point of running 64bit PEs if the whole windows ecosystem is not interested in it at all?
i wasn't going to post till i read this..
THAT is exactly what a emulator does.
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
Maybe it should be named Whine.
You don't want Linux. You want an operating system which should be able to run Windows applications.
Give a try (in a VM, of course) to ReactOS
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.
Nice job! Thanks for your information.
------------------
I know some wow gold in wow, cheap wow gold farmed by man.
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 #!
GNU's Not Windows
ALINW as in "At Least It's Not Windows"
http://wiki.winehq.org/Wine64 http://wiki.winehq.org/WineOn64bit
Eh, I don't see anything impressive about having a popularity contest either. More interesting is the list of applications that are actually supported, e.g. the productivity applications that work without any flaws.
I don't know what you mean by "Relax on APIs". However WineLibs makes porting applications to Linux much easier. Wine is Not an Emulator, it is a reimplementation of the Win32 libraries. This means that it need not be slower, and even though Wine is not fully optimized it is already faster than Windows XP in some areas. If your app doesn't just instantly work in Wine then you have found a bug in Wine*, you just have to fix or workaround that bug. Otherwise you'd have to change every part of your program.
* or you have found a buffer overrun that just happens not to be detected by Windows. Congratulations. Also tweaking the GUI a bit would help so it would fit in better, but not strictly speaking essential
uh ... according to http://support.microsoft.com/kb/314865 you need at least 1.5GB of HD space for an XP install. I didn't check Vista requirements. I am assuming that you're not talking about "specialized" Windows installs like MicroXP or MiniXP, but how do you have a Windows install that is only 250MB?
on the flipside, have you tried puppylinux and the like that are have very small footprint -- HD space (100MB) and hardware reqs?
joe bloggs who just wants to play his computer game will go "wtf - this just worked when i had windows".
I bought this laptop from Dell. To be fair, it came with Ubuntu, but I then reformatted it with a 64-bit Kubuntu.
There were exactly two things which had to be tweaked for this to work: First, I had to install the gnome-bluetooth package in order to get Bluetooth working. Second, I had to tweak an obscure commandline boot option to make the trackpad work.
I recently installed XP. I had to install around 20 separate drivers, most of which were not available for download from their respective manufacturers' websites. The video card -- nvidia -- was something which Just Worked on Linux, yet could not even be downloaded from nvidia.com for XP.
Fine, so I have to download it from Dell.com, which has drivers for Vista, or Vista. Fuck me.
Finally got on a chat with a Dell support person, who fed me direct URLs to all the drivers.
And I'm not even going to get into the whole AHCI thing, or the activation. Just getting a usable OS was easily a weekend, whereas a Linux livecd pretty much just worked.
I feel that this is the biggest hindrance to widespread adoption of linux.
You'd think so, but it's actually solved -- just buy a Dell with Ubuntu preinstalled. Installing an OS is not a task for beginners, no matter what the OS. Running programs compiled for one OS on a completely different one is also not easy.
No, it turns out that no matter how easy it is to install, there are other, large problems, many of them not something the Linux community can solve by itself. For example: How do I stream Netflix movies on Linux? Whose fault is it that I can't?
Don't thank God, thank a doctor!
THAT is exactly what a emulator does.
No, it's not. An emulator intercepts calls and reconstructs ("translates") them for the target architecture. The translation part is what makes it emulation instead of mere dispatching. GCC is more of an emulator than Wine is -- by the time a binary has been built, the emulation has been done and the binary runs natively on the architecture.
It is as much of a Windows emulator as Windows 95+ is a Win16 emulator; mechanisms similar to the Windows "Thunking" process simply translate API calls from the Win16/32/64 calls to equivalent Linux calls.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
I've seen that benchmark often. Is there a newer version of that for Wine 1+?
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
I mainly used it for Maple V. When I had an nVidia card I also used it to play Team Fortress II with my windows friends.
One thing to consider: the applications you describe run fine in any virtualization software, where as 3D games do not. Even if your virtualization software supports 3D it might have a very heavy overhead. Apparently Hardware Lighting is 87% slower in Parallels 3. Thus it is reasonable that getting popular 3D intensive applications to run in Wine is a priority.
Also note that CrossOver Office is based on Wine, and that some software producers officially support Wine (e.g. Google supports running Picasa under wine). So, despite its problems I still like Wine... I also like Wine Is Not an Emulator ;)
If you run Office 2007 or MSIE 7 (or any other newer MS application) under Linux, it's illegal to use any of the fonts that is distributed with the applications or with Windows Vista (or any new fonts from MS). You can buy separate licenses for some of the fonts (MS license some of them from other sources), but they cost more then Windows in it self and usually miss some glyphs.
Without those fonts documents will never look the same on Linux as they do on Windows.
So unless you ask your clients to not use these MS fonts, you will not be able to work painlessly with their documents anyway. With the right fonts OO.o is close to perfect on viewing and editing Office 2007 documents, unless they include COM objects or some very odd VBScript.
There is a special exception for fonts being used in a printer when you print the document. But you are not allowed to cache the font in the printer (resulting in increased resource use and a delay between every document you print). All those print shops that use Macs break the license when they use "MS" fonts, unless they bought them separate and some of the fonts and glyphs are not available separate.
All fonts distributed with newer MS applications have licenses that only allow them to be used with MS Windows. Embedding is not allowed.
Those licenses include Segoe and other fonts used in the MS Windows UI. But thats a small problem compared to the lock-in on documents.
It's a perfect customer lock-in. I'm sure that MS will start to use it as a weapon when unaware people have created enough documents with those fonts.
It's not a compatibility list. If you click the "What does this screen mean?" link it becomes obvious it's a wish list. Inclusion on the list is no guarantee of usability, and if you click on any of the apps listed (which are mostly games, such are wish lists) you'll see lots of problems documented.
Anyone can put together an impressive wish list.
(eom)
hell, this century.
You know, that Microsoft system that changed things and one of them was VBA.
You didn't drop it, though, did you. You didn't change from VBA to something sane that wasn't tied to a peripheral system (Office), did you.
No, you put time and effort and a LOT of money to porting it.
I guess after getting raped that hard, you want to believe that you liked it and there's a good reason for staying but you can't explain it to me because I won't understand.
(captcha: mounted)
does it run Linux?
Meep.
No, I'm New Here
-1 flamebait? once again the open source community has spoken loud and clear! hehehehe!
As in Beer Empowered Engineering in Reverse.
This is far from good news. The article fails to mention the last part of the sentence, which reads as follows:
Hello World, We are the borg, We will add your biological and technological distinctiveness to our own. Your culture will adapt to service ours. Resistance is futile.
Return addresses are code just as much as call or jump addresses are code.
Variables should not be mixed with them, especially if they could contain data from potential attackers.
Mixing return addresses with variables means that it is easier for me to make a buggy program "return" to arbitrary code of my choice.
Whereas if the data stack was separate, while I can still do some damage by having the buggy program work on the wrong data, it is harder to get it to run arbitrary code of my choice. It may still be possible, but it's more work.
It's bad practice to keep putting shit (external data) next to food (code) and say "as long as people do things right it'll be safe", or say "hey it's their fault if they make mistakes".
Bad hygiene.
The page linked to from the summary is NOT a compatibility list, but a compatibility REQUEST list!
Please stop referring to Wine as a Linux-only program. It works fine on other POSIX OSs including Mac OS X.