Wine 1.2 Release Candidate Announced
An anonymous reader writes "After evolving over 15 years to get to 1.0, a mere 2 years later and Wine 1.2 is just about here. There have been many many improvements and plenty of new features added. Listing just a few (doing no justice to the complete change set):
many new toolbar icons; support for alpha blending in image lists; much more complete shader assembler; support for Arabic font shaping and joining, and a number of fixes for video rendering; font anti-aliasing configuration through fontconfig; and improved handling of desktop link files. Win64 support is the milestone that marks this release. Please test your favorite applications for problems and regressions and let the Wine team know so fixes can be made before the final release. Find the release candidate here."
I'm actually quite surprised with the more recent movement of Wine though. I remember assuming nothing was going to work. Now I can assume that it might work, which is a serious improvement, IMHO. Previously I never attempted to run something unless I looked it up in the App DB and now I just run the apps and see what happens.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Native software is fine, but a compatibility layer won't hurt. In fact, WINE is great for running legacy, closed-source software whose development is long dead with no native build going to be made.
Colorless green Cthulhu waits dreaming furiously.
It's even funnier if you consider the option of running WINE on Windows: http://wiki.winehq.org/WineOnWindows
Colorless green Cthulhu waits dreaming furiously.
About five years ago my employer introduced a web app for time sheets which would only work in IE. The new version works fine in generic web browsers and our thinking on this is that enough users wanted it on the mac that they were forced to fix their application.
A lot of development is now happening for iPhone and Android platforms which are sort of BSD and Linux respectively so I think Microsoft is losing slowly, but there is no one winner, which is probably good too.
http://michaelsmith.id.au
I remember 16 years ago on the Wine mailing list saying that spending time supporting Win16 was a total waste of time, and they need to concentrate on Win32 as by the time they supported either in a meaningfull wa, nobody would care about Win16 anymore.
Of course I was shouted down and flamed for my entirely accurate predicition. So of course huge amounts of time where wasted in the early days concentrating doing a really good Win16 emulation, that nobody could care less about for a decade now.
Mono is implementing an (half-)open standard in a platform specific way. Wine developers are emulating the Win32 API by reverse-engineering it and replacing it with a minimally understood code equivalent that simulates the original intent. I don't know what to say about GTK and Qt, as these are cross-platform APIs that bear no similarity to either.
In summary, I don't know what to call Wine. It's not an implementation (an impl. requires an open interface or spec)., and it's not an emulator.
Linux already extinguished mainstream BSD. It did as much to kill SCO as the lawsuit. It killed HURD. Face it: Linux got critical mass first, and wiped out a lot of the open-source competition. By Android, it's likely to kill a bunch of cellphone OSs, maybe even Palm, possibly even iPhoneOS.
Which is not, in fact, a bad thing. If anything, we need to unify Linux even more, so it can start killing some commercial systems. I'd love to see it wipe out the commercial Unices. Hell, I wouldn't cry over it killing OS X. And I've already planned the party for when it kills Windows.
Apps are faster in Wine than VMWare. I tested Eve Online in both and it was noticeably faster in WINE. Both paled in comparison to running natively under WinXP on the same platform however.
I care about Win16. The one thing I use Wine for is to run a 16-bit Windows application.
The real "Libtards" are the Libertarians!
One of the easiest ways to manage Wine versions and installing games: http://www.playonlinux.com/en/
M$ is doing that to try to force the few people who had useful 16 bit software to throw it away so they'd finally spend money on newer stuff. There is no reason why they couldn't do something like Dosbox to keep 16 bit apps running on Win7 64. Dosbox already ran dos-era apps better in 32 bits windows than the native cmd.exe did.
It is an adaptor that makes one set of APIs (POSIX + X11) appear like another (Win32). In most of computer science, we call that an emulator. It is not a CPU emulator (which makes one CPU appear like another), or a full system emulator (which makes one complete set of hardware appear like another), but it is an emulator. Oh, and it doesn't just reimplement the APIs, it also provides a run time loader and ABI compatibility. *NIX systems can't natively load Windows PE files...
I am TheRaven on Soylent News