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."
Support for Microsoft's ABI no doubt.
How we know is more important than what we know.
Judging from this post, it looks like the changes involved support for mixed Windows/Linux calling conventions on x86-64 (i.e. specifying on a per-function basis whether to use the Windows or Linux calling convention).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
http://en.wikipedia.org/wiki/X86_calling_conventions
See "Microsoft x64 calling convention"
How we know is more important than what we know.
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
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.
Meh. You can use unmodified Windows libs in WINE too..
Yes. Thank you for stating the obvious. However, like anyone who would fine Wine useful, Artem obviously cares just as much about speed and compatibility as he would being able to run a program without genuine libraries. As he stated, the overhead is a problem. From my experience, a 4+ second delay launching a single executable is simply not acceptable.
"When you see a unixer brainwashed beyond saving, kick him out of the door." - Xah Lee
Really, A 4+ second delay?
Wine is easy to setup now (winecfg is gui based.) Maybe you should check your setting.
Programs usually open as quick or quicker than running it in windows (comparing from work and virtual box but I would notice a 4 second wait on apps.)
ReactOS
The general idea is similar to what you are looking for. It's nowhere near finished and they have been working on for god knows how long, but who knows. Someday perhaps.
Gone!
Why would you want that? If you want something that is like Windows then go for ReactOS, rather than taking a UNIX-like kernel and strapping WINE on top and avoiding all of the UNIX userland. I believe all of the software you listed runs unmodified on ReactOS, and so do a lot of Windows drivers.
I am TheRaven on Soylent News
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.
Now that's funny.
Program Intellivision!
The solution to the ventrilo issue is called ventriloctrl and can be found at http://ubuntuforums.org/showpost.php?p=2662867&postcount=83 . Getting push-to-talk working is not really the hurdle here, the problem is that when the Wow window has focus, there's no way for Vent to know you hit the key, which is how most people would be using vent+Wow. The post is outdated but the README that comes with the zip file explains what to do.
Oops, nevermind. That info pertains to x86, not x86-64.
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 #!
It's what Lindows was until MS sued them into the ground, they changed their name to Linspire and went very very quiet about running windows apps.
It's good to be the king!
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Why would you need to run MSIE 7 or even 6 and Office 2007 when you have wonderfull Open Source apps that do the same and far better !
I respect Photoshop because some people really base they work on it and it has no FOS replacement, but I really think GIMP is better just for supporting Python xcrypts.
4 - A robot may not masturbate, except where such action would conflict with the Second Law.
Or, if you don't like compiling things for days, start with Ubuntu-minimal or Debian, and add packages you need. It will start barely bootable, and it's up to you to install the rest.
Don't thank God, thank a doctor!
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.
Then again, I guess nvidia & fglrx alone will be enough to make a majority of users.
We're working on that, by the way.
~ C.
And should you not like Wine (the non-native look puts me off), there's always K9Copy, which IMHO is a worthy alternative to DVDShrink.
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
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.
Um, winelib and GTK are both LGPL. You can port a proprietary Windows app to Linux using wine, or you can port it to Linux by changing it to GTK. You can even pay Nokia (Trolltech) and buy a Qt license and port your software to use that. Then it would work on Windows, Mac and Linux, using the same toolkit.
If you pay Nokia, you get support for Qt with an extremely good track record of fixing critical bugs - much better than the turnaround for MS to fix API bugs.
What nonsense. GPL doesn't have any restrictions on use.
Stop your bullshit.
Actually, the leader of the project has already stated that they have no intention of fully "emulating" (for lack of a better word) Win32.