Wine 1.4 Released 168
vinn writes "Wine 1.4 was released today and includes support for a wide range of applications, including Office 2010. There are some major architectural changes, including a built-in DIB engine for better graphics display and a new audio stack designed around the newer Vista / Win 7 system and integrated into the native audio system. Almost every other subsystem received substantial updates, including Direct3D, the Gecko-based web browsing components, and better internationalization. The release notes contain more detail and you can download the source code now, or wait for packages to appear soon."
Comment removed (Score:5, Informative)
Re:Blast from the past (Score:5, Informative)
Those need a Windows license. Wine doesn't.
Re:Blast from the past (Score:2, Informative)
It's truthfully been ages since I've thought about Wine.
Question directed at Wine users - how does it stack up against VMware, Virtualbox or the other virtual machine servers?
Depends. If you need something that "just works" most of the time, you're probably going to want to do a virtual machine. The problems though can be extensive, namely in terms of performance. Games, for example, typically run like boiled crap in a VM. However, some stuff works okay that way, even if it's a rather ham-fisted way to do it (why virtualize an entire machine if all I need is Outlook?).
Wine still has its quriks but the performance it gives is substantially better (quick bench: World of Warcraft in a VM versus Wine...wine hands-down, every single day of the week for years on end). It's also rather nice these days with quite a few things either working out of the box or requiring fairly simple tweaks to make work. And if you're lazy Codeweavers' CrossOver line is still fantastic.
Great, sometimes (Score:5, Informative)
When Wine works well, it is far superior to running the app in a VM, for a number of reasons
- Performance - When an app runs well under Wine, it runs as fast as it does under Windows on the same machine, or sometimes it runs even faster. Running under a VM is never as fast as running native on the same hardware.
- Desktop integration - When an app is installed under Wine, it automatically integrates with your GNOME/KDE desktop... the application is available in the menu, same window manager, etc. Yes there are solutions for this under VMs like VMWare Fusion, but it is not as clean and frankly usually is buggy as all get out.
When an app runs in Wine well, I prefer to run it that way over a VM. VMs are much better though to be sure the app is running the exact way it was meant to run.
Re:Sadly the Debian bins are still at rc3 (Score:5, Informative)
Debian hasn't packaged 1.2 yet, these are third-party packages.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585409 [debian.org]
Apparently one of the issues why the newer versions can't be packaged is that the maintainer wants to package and upload all versions between the last one and 1.4 in order. Since nobody has the time to do so, there isn't any progress towards packaging the newer ones.
Wine is $200 cheaper (Score:5, Informative)
With fast machines, loads of ram and virtual machines I am not sure what the point of wine is anymore.
You still to buy a $200 copy of retail Windows for the Mac or home-built desktop PC on which you run Windows inside a virtual machine. Xubuntu + Wine is cheaper than Windows, and Mac OS X + Wine is cheaper than Mac OS X + Windows.
Re:Blast from the past (Score:4, Informative)
VirtualBox and VMware emulators are a type called pass-through emulation, which actually only emulates a small amount of functionality of the system (mainly drivers) and the rest is all native, so the performance hit is generally trivial. At most you should see about a 20% hit in CPU here (as long as you aren't memory bound - WINE shouldn't chew up as much memory as a VM, generally). If the GPU is hardware accelerated and properly passed through, there should be almost no hit unless the drivers for that platform are particularly bad.
WINE is a native implementation of the Windows APIs, so if an API isn't implemented, it crashes and burns. Also it actually has the same problem as VMs in regards to devices - they need to be implemented or they won't work and in the case of WINE, very few are. OTOH, WINE can use all graphics memory if used with DX or OpenGL and most VMs share an amount of it (VirtualBox I think is up to 256M now, but my card has 1GB). Likewise emulators usually are assigned some of your CPUs and WINE can use all of them.
When I have VirtualBox properly set up, I get two frames less in Linux running in the emulator than I did in native Windows, so I suspect your VM isn't running with hardware accelerated drivers. With VirtualBox you also need to turn off the native mouse pointer to use OpenGL with hardware acceleration or you spin like crazy (or it will start driving for you in 2D), so if you have the native pointer on and aren't spinning, you aren't in native OpenGL, which requires installing the VirtualBox extensions and the native hardware driver. If your hardware acceleration was properly set up, how much video memory did the OpenGL program consume?
Code sharing (Score:5, Informative)
The ReactOS and the Wine project share a lot of code [reactos.org] (most of the userspace libraries. Consider ReactOS as a Wine userland + WinNT-like kernel). So therefore, the day ReactOS is actually a complete OS that can run 100% of windows software, is also the day that Wine can run all the Windows software too.
Re:Which apps? (Score:4, Informative)
The following are the apps that I run under Wine (just to give you an idea):
- World of Warcraft
- Audible
- Goldwave Pro (to un-DRM the Audible files)
My wife also uses some website's proprietary software to assemble photo albums, which are then uploaded, printed, bound, and shipped to her.