I've been the Ubuntu developer responsible for Wine's packages for almost a decade now.
Over the years I've encountered a lot of skepticism about Wine, with some people even wondering if we'd be better off without it existing. I've never been convinced.
I hear an incredible number of stories about people who wanted to use Ubuntu, but couldn't because of one Windows app. Increasingly, I hear the inverse -- people who are happily using Ubuntu now because Wine works well enough.
Data is hard to come by, but my best estimates put Wine's install base at something on the order of 10-25% of Ubuntu users. That means millions of users of my packages. Most are running games. Some use it for some sort of critical business function like a legacy app.
I've contracted with a good number of companies who use Wine for critical business purposes. Wine is quickly becoming the porting tool of choice for making Mac and Linux versions of Windows software -- often times the game will work without modification, and when it doesn't these days it is dramatically cheaper to improve Wine than to rewrite applications.
I do understand some of the skepticism though. A single bug can render an application completely unusable, so from a user's perspective it's very hard to tell whether Wine is 99% done or 5% done. But in the future, you won't even know you're using Wine -- it'll silently be powering your steam games.
>I've been the Ubuntu developer responsible for Wine's packages for almost a decade now.
Many thanks! +40 or so machines run LTSpice (and other apps) via WINE in my lab. A good portion of my students install and run Linux on their personal computers, then using WINE for Windows application support.
Thanks for your great effort. I've used Wine quite a bit, and have benefited so much from it that I bought CrossOver, just to support it.
I've been a fan on Wine since I tried it, but I think this article on OS/2 from Arstechnica argues very well, on a historical basis, for why Wine unfortunately won't be helping getting people to use Linux on a large scale.
"OS/2 ran Windows apps really well out of the box, so they could just write a Windows app and both platforms would be able to run that app. On the other hand, writing a native OS/2 application was a lot of work for Windows developers."
"The second lesson of OS/2—to not be too compatible out of the box with rival operating systems—is a lesson that today’s phone and tablet makers should take seriously. Blackberry once touted that you could easily run Android apps on its BB10 operating system, but that ended up not helping the company at all. Alternative phone operating system vendors should think very carefully before building in Android app compatibility, lest they suffer the same fate as OS/2."
I've heard this claim a lot. The reason I think it's hogwash is that, application compatibility being equal, people would actually prefer to run Linux over Windows. That absolutely wasn't the case with OS2 and Blackberry.
Linux is free. OS/2 was strictly more expensive than Windows, and required you to buy a copy of Windows to run the Windows apps.
Like it or not, Linux was effectively second to the party. We faced a chicken and egg problem, and had no first-mover advantage. We simply weren't strong enough to cajole users into defaulting with us because we could hold all their favorite apps hostage if they didn't. We had no apps, legacy or otherwise.
We tried to get people to want to migrate badly enough by excelling in other areas (like being free). But our biggest problem was that they couldn't come even when they wanted to: 80% never heard of us, 80% of those left had hardware issues, 80% of those who remained had an application with no native equivalent. 20% of 20% of 20% is 0.8%, which incidentally is the exact market share we had.
But we're solving those issues now. People are becoming more aware of the viability of the platform. Distributions with commercial backing and their hardware partners have been solving the hardware issues. But there's still that application barrier for migration. Wine is a huge part of the solution to that.
Exactly. OS/2 was compatible only in the sense that with a vastly more expensive computer you could run windows, dos and os/2 apps.
There were lots of DOS apps. A few windows apps. And no OS/2 apps.
Windows always had compatibility AND reasonable system demands. On a windows 3.0 supporting machine you could not run OS/2. On a windows 3.1 machine you could -badly- run OS/2, but not OS/2 2.0. And on a windows 95 supporting machine you could maybe run OS/2 2.1.
OS/2 is an example of why design by committee loses out to a technical person really controlling the development of an application. OS/2's code, I'm betting, is far more flexible than the windows code, and has support for all sorts of weird features that no-one but academics care about, and massively increase demands on hardware. They also constantly require rewrites to actually make use of these features.
OS/2's failure had nothing to do with application support. If anything that was one of OS/2's redeeming features.
I like to think that the first thing you should do to make something succeed is to make it possible for said thing to succeed. OS/2 did not make it possible for itself to succeed, because nobody could run it. Somebody should have stopped the software architects and forced them to change until that happened. Nobody did.
The academic community was really proud. They even pushed it into the huge IT environments, like banks. No-one ran OS/2 for fun, because that was a $5k proposition. Running a windows 95 was a $500 proposition, that also got you access to duke nukem 3d and loads of other games.
Vastly more expensive? I think it run well on a 386 with 8MB of RAM, and if you got rid of the Workplace Shell as the original MS OS/2 2.0 SDK betas from 1990 did, it would run well in 4MB.
If we're going to quote official hardware requirements, then I'd say that Windows 3.0, the version that imho is comparable to OS/2 2.0) ran on a 286 with 384 kb of ram. Windows 3.1 ran on a 286 with 1 megabyte of ram.
Both ran well enough to run wordperfect on a 286 with 1 meg of ram. OS/2 wouldn't even boot under 4 megabytes of ram, or with a 286 processor.
So yes, vastly more expensive hardware requirements is certainly a valid criticism. In 1992 nobody had 386 machines. Some even say IBM purposefully designed it like that, to sell more machines. But if they did indeed intend that, why not release the OS for free ?
In 1992? I think this was after for example the infamous AMD 386DX-40 was released. Granted there probably still were a lot of 286s out there back then of course, which is one of the reasons why I never suggested abandoning DOS/Win3.x immediately. Of course, as mentioned before this would cause some pain for application developers, but this would last only a few years, and even PX00307 mentioned "Porthole" (aka WLO).
Seems like Wine will actually be even more relevant if increasing Steambox support allows more people to ditch windows (I still have a windows gaming only box).
Thoughts on integration? Wine can run steam but I wonder how far this could be taken in having a clean dual installation of native and wine based.
I would really like it if Wine steam and Linux steam played better together. At the moment you have to log out of Linux steam, open Wine steam, and then launch a Windows game. It would be much more straightforward to just have the Linux steam be aware of the Wine install of the Windows game.
One solution is to just port all the old apps with Wine wrappers so that Windows steam isn't needed. Another solution is to just have both steams open together (Valve has promised multiple simultaneous login support in the near future, as it's a requirement of home streaming).
Another option would be to have full-on support for detecting Wine within Linux steam and offering to run your windows games using community-derived Wine settings (akin to playonlinux or winetricks). That would be kind of radical, but I don't think they'd be gutsy enough to go that route.
Yet another option would be to simply endorse porting with Wine and tell developers how easy it is and how much money they could make by porting the back catalog. Last time I asked Valve didn't want to endorse a particular porting technology, but perhaps they'd change their minds if one was good enough and it meant developers would be more willing to port games with it.
I wish wine could do a bit on the visual integration side - enabling themes makes it quite slow, maybe you could have a word with Mr Shuttleworth and get him to bundle and ubuntu wine theme, and fund the last bit of work to get themes rendering quickly.
Including a proper wine theme (and matching it to the system themes) is something that's been on my todo list for the greater part of 5 years now. Hah.
Trying (and failing) to get my own mp3s playing consistently on the radio in the mac appstore version of GTA SA, I had occasion to peek in the installed directory structure.
I was pretty surprised to see a familiar-looking wine style layout there.
I didn't really look into it, so I don't know what the exact situation is, but looks like the future might have already happened in that case.
Yes, this is what I meant. Cider does suck, because Cider is based on a proprietary fork of a 7 year old branch of the Wine code and couldn't keep pace with the open source version. There's a reason Transgaming abandoned Cedega as a consumer product, and it's been that free Wine has been vastly superior for a while.
Codeweavers has already moved into the porting space using their expertise around free Wine, and perhaps not surprisingly Transgaming has begun to pivot into completely different areas.
Honest question: What do people use Wine for? The only thing I ever tried under it was games, and for that it was... meh. I'm assuming my experience was sub-par because my expectations were unreasonable.
But I'd really like to know whether people are actually effectively using things like Office with Wine or whether there's some Door Number Three that I'm just not seeing.
An open source project I contribute to uses wine in a pretty cool way I think. Actually it's mentioned in these wine release notes - LMMS.
It's a music production studio, and one of the features that it offers is to use a VST instrument. A VST instrument is a .dll file which provides a virtual instrument for the user to use in their music project. So here we have this native linux app but it is able to take advantage of .dll plugins using wine.
Qt file picker, I think. (The sidebar stuff doesn't work either, I suspect for the same reason.) All the code is open source, just needs someone looking at what's happening.
I use MS Office 2010 under Wine. There are tutorials on the Internet that make it really easy to set up. It needs a specific version of Wine to work (some 1.5.x release), so I'm using it on a PlayOnLinux virtual drive (that way I can easily have multiple Wine versions and configs on my system, tailored to each software). The hardest part was making the file associations work correctly (because that was not explained in the tutorial, but it was easy to figure out). Word, Excel and PowerPoint work fine. VBA does not work (not something I need).
It suffers from some graphic bugs (mostly in the properties dialog, for objects in PowerPoint for example; usually you can fix it by reloading the dialog), also, TrueType doesn't look perfect. I can't remember having it crash heavily.
I needed MS Office because while Open/LibreOffice is good enough for most things, and is actually more than sufficient if you write your materials from beginning to end in them and never export to proprietary formats (i.e., always keep saving in ODF), the compatibility layer with MS Office is not perfect and is not sufficient for more advanced things (such as the fancy 3D-and-the-like styling options my colleagues insist on using). The imperfections* of the document compatibility layer become a problem when working on the same document with people who use MS Office.
Using a virtual machine would probably work, too... if I had an infinite amount of Windows licenses. I can't use the license from my real-hardware install, as I still need Windows-on-real-hardware for a few things (to do with drivers and device flashing).
Using Office was the main reason why I had to reboot into Windows, and so I couldn't be happier with this setup. My productivity has increased a lot (no need to wait for reboots). Besides Office, I also use Wine to run the emulator of a platform for which I develop software (the emulator is not open source, and are not available for any Unix but OS X, which I don't have access too). So Wine does a really great job for me, doing things that I think can be called "effective usage" (in fact, I don't run any games under Wine).
* MS Office import/export is actually quite good for a FOSS piece of software, and while the "imperfections" are being perfected as new versions are released, Microsoft too keeps releasing new Office versions with more shiny features, so I understand the difficulty on keeping up with the compatibility on closed formats.
If it worked in a 1.5.x version of Wine, it's probable that it works in the stable 1.6 version of Wine. Most Wine releases (like the one in the article link) are basically snapshots of the beta tree, and while we do have extensive test-driven-development there are still regressions. Stable releases, however, pretty much have a no-regression policy.
As far as Wine "catching up" to the newest stuff Microsoft releases being an ongoing game, the news is a bit better for Wine than for Libre Office. Wine only needs to implement the crazy new APIs Microsoft creates when they're actually being used by applications. At the very least this gives us considerable time leeway -- not having a Direct3D 10 implementation didn't hurt Wine much when every game kept having a Direct3D 9 fallback for a few years.
Is there a way that you can package up Microsoft Office versions (with all relevant patches updated) into .deb/rpm ? I would still need to buy an Office key.
I would pay for such a packaging (separately from the key). What this gives me, is the latest compatible Microsoft Office in lockstep with a wine release. I would'nt even mind you charging a few bucks for every incremental packaging.
I daresay that this is a large enough pain point and people would'nt mind paying a few bucks. I would also argue that this would substantially improve the sell of Linux to enterprise customers who can have a decently working Excel at a click as opposed to the seriously cumbersome install on Windows.
You are more or less describing the exact niche the Crossover product from Codeweavers fills (originally called Crossover Office because Office was the main supported application). I'd give the free trial a try. You're paying for support, and it's free Wine underneath - the proprietary part is the Crossover UI which basically just speeds installation of Office and other supported apps.
The state of libreoffice is quite good in general, but for academic papers with references it tends to butcher them. I haven't tried wine for MS office, I run in a VM instead because someone else told me that their version of office didn't run well in wine. I guess it's not a very good reason and I should give it a try.
Yes, games. Works quite well for me. Not only for some old ones, also recent ones work very well. For some games, the trick is to use Wine's "desktop" windowed mode to make them work nicely.
Some games have a Linux binary as well (and unfortunately no source code), and yet the Wine one will work better. The Linux binary will be like "old-version-of-some-library.so not found" or "could not connect to X server", while Wine acts as a rock-solid stable graphics and gaming API!
The only sad thing is that relevant versions of Internet Explorer don't work in it, that would be very handy for testing something in multiple browsers.
My bank has a small business ebank site which is IE only (and you need to put IE11 in compatibility mode). It might suck but my income is in USD and I live in Canada and via this web app I have access to the FX trading desk from my home. That access literally pays enough to put up with IE.
I only use it for SketchUp and Netflix now. I used it a lot when I first switched to Linux (iTunes, Office, Steam), but it's become less necessary as I've learned how to avoid Windows applications and more applications have ported to Linux.
I mainly use Mac OS and Linux, and the application the Tax Office in my country makes for you to file your tax return for many years only ran on Windows. Only last year they brought out a Mac version, but still you need Wine for Linux.
I know that gog.com has been packaging up games for OSX with it. It works pretty well for that jump. One person configures it once and ships the app with its own wineskin and it just works.
I used to work in television. Sky TV in the UK uses a platform called OpenTV, which like anything with "open" in the name is a proprietary vertical-market app that charges thousands of dollars per seat per year. One part of the content chain is a compiler that's supplied as a Windows binary. That bit ran immaculately under Wine 0.9.something on CentOS, saving us a few Windows licenses.
tl;dr Wine is usable for production work, anyone who claims it isn't is simply incorrect.
I use it to run AnalogX's PCalc (programmer's calculator). I haven't found a match for it on Linux or Mac. Python/IPython REPL is better for the history, functions, and variables but I haven't figured out a good way to replicate C arithmetic rules when it comes to overflow/underflow/finite bit limits. It would be neat if I could somehow "type" variables/literals to C types in Python.
People in the console video game modding community sometimes release Windows-only small computer programs that help you with one step of modifying your console. If the program doesn’t require complicated interaction, it’s easier for me to open it in Wine than to exit OS X and boot into Windows just to use it.
One Windows-only modding program is Lunar IPS (http://www.romhacking.net/utilities/240/), which patches ROM files using a custom patch format for GameBoy Advance games. Another program was Wii Code Manager (which now has a cross-platform replacement in Java), which let you select a subset of cheats from a database in a text file, then compiled those cheats into a GCT file so they could be applied to a game.
I’ve also used Wine to try out very small games, such those created in game jams. I wouldn’t want to play a game permanently like that, because the game saves might be locked into the Wine version and Wine might turn out to be too slow, but Wine is fine for trying out the game to figure out if I want to play it, or playing a simple game that doesn’t save.
Two things. Games, which is hit and miss but I'm still deeply impressed by the wine devs. Civ V runs amazingly well and it seems smother than the native OS X version, though that impression might be influenced by the wine version on Linux supporting mods, unlike the OS X version.
Secondly to compile Python projects to .exe files using Pyinstaller. Wouldn't use this for paid projects but for fun side-projects it's great.
As a student, I've gotten a lot of mileage out of it for e-book readers. My university library has a bunch of books available on Adobe Digital Editions, and Amazon lets you rent Kindle books for a user-specified amount of time. Both Digital Editions and Kindle for PC work very well on WINE.
If you find a reproducible import/export fidelity bug, ideally with a minimal test case, file a bug. They jump on those like attack dogs, and you can be reasonably sure it'll be fixed next version.
I use Windows 7 in VirtualBox under OSX quite a lot. It's just more convenient than rebooting into Bootcamp for things that work that way.
Of course, as a heavy Windows user, I want Aero. It just looks wrong to me without it. I also want my Windows to be as fast as it would be if booted natively, and I even occasionally play games inside VMs. To achieve this, VirtualBox translates the DirectX calls in the VM into OpenGL calls on the host. Rather than reinvent the wheel, VirtualBox uses libraries developed by/for WINE.
I also use WINE to run the odd Windows application or game under OSX or Linux. You can look up compatibility ratings of games on the Wine website, and for many it works absolutely perfectly. (For those where it doesn't, I sigh and reboot into Windows)
My use case: I used Wine to let our advertising representatives use a PDF markup tool wit some specific capabilities they wanted that turned out to be Windows-only. It took less time to set up than it would have to even find a good alternative.
On Mac OS X I use it to play the original Baldur's Gate and might use it to play Baldur's Gate 2 as well.
I think it's a great solution for playing old games or games that were never released for Mac OS in the first place. I used to play League of Legends using Wine until Riot released a native Mac OS X version.
OS X Wine skins for many games can be found at sites like Paul The Tall: http://paulthetall.com
I used Wine quite a bit, but it's usually to get data out of obscure formats saved by obscure software. I've recently needed Wine for the following:
1) Read files saved by thermal imaging camera (no Linux or Mac software available)
2) Extract data from OriginPro worksheet (no viewer for Linux)
3) Run Bloch solver for neutron precession in magnetic fields
A big, complicated in-house windows executable was blowing up with some memory errors. I tried to run it under valgrind with wine and it just worked! I was able to use valgrind to debug the issues.
I use Wine on and off, so much that I bought the CrossOver app that's built on Wine.. I use it on Mac to run windows-only programs for work like Microsoft Project, Microsoft Visio and a small desktop tool we wrote a Lon time ago. I think Wine is amazing but must admit that one day it's use will probably be obsolete (there are alternatives to the Microsoft programs that are more or less "good enough").
I think that when Wine was originally started, the goal must have been for it to be obsolete one day. That day is still very far away, and regardless, Wine is a technical marvel.
Congratulations! Wine's existence continues to be superior to its nonexistence. I can't say it's ever been convenient to use, but switching operating systems has always been at least slightly worse.
I look at the list of bug fixes, and I can't help but think that this is a losing battle, and that there are much more worthy projects that the concerted efforts of these undeniably skilled developers could be building.
Enough people need Crossover that they employ several people to work on it and Wine full time. Others find it very useful, so they help out. What's the problem?
It's probably a project that is helping at least hundreds of thousands of people (maybe even millions), and it is getting quite mature, so I don't see any reason not to do it.
I have to agree. I think it's a great, and much needed, project but I discovered that just beefing up my hardware a little and running Windows on VirtualBox was cheaper in the end. Many applications don't work out of the box, and require all sorts of twists and turns to get them working, if at all possible.
Time and money are not seamlessly convertible at all, so, if this was the intended meaning of the comment, I think "cheaper" is misleading in comparison with e.g. "faster", "easier", "more efficient", "less time-consuming"...
I see the list of bug fixes and see great promise. It is likely that most bugs affected more than one particular program. Assuming the bug fixes themselves aren't introducing too much new code (which will inevitably contain bugs itself), I see Wine as stabilizing, not losing the battle.
Roger that. I use Ubuntu for all my dev work and for media manipulation work...If only these efforts would be dispensed on making the utility software on Linux user friendly. Have yet to find a screencast maker that just works :)
At this stage working on something like wine seems like a misguided effort. I use windows as my primary desktop OS and it works well. For non-windows users, a vm solution would be way better than a kluge like wine.
I use Ubuntu as my primary desktop OS and it works well -- and I can say that it does in part because when I get an occasional itch to play a game, wine works for me more often than not (most recently: Hearthstone).
If I still used Windows as my primary desktop OS, I wouldn't care about wine either, but then again I wouldn't be the target market, now would I?
You are right, I am not the target audience. The point is that the effort required to keep a project like Wine going could be better spent on doing other things that make the overall Linux experience much more appealing.
I used Ubuntu as my primary Desktop during the stone age of Vista and even then, using Wine was a painful experience compared to just switching to Windows.
With virtualbox and its alternatives it's really hard for me to find a reason to use Wine, and yes I do not play games under Linux.
Anyone can list some main usages for Wine?
Over the years I've encountered a lot of skepticism about Wine, with some people even wondering if we'd be better off without it existing. I've never been convinced.
I hear an incredible number of stories about people who wanted to use Ubuntu, but couldn't because of one Windows app. Increasingly, I hear the inverse -- people who are happily using Ubuntu now because Wine works well enough.
Data is hard to come by, but my best estimates put Wine's install base at something on the order of 10-25% of Ubuntu users. That means millions of users of my packages. Most are running games. Some use it for some sort of critical business function like a legacy app.
I've contracted with a good number of companies who use Wine for critical business purposes. Wine is quickly becoming the porting tool of choice for making Mac and Linux versions of Windows software -- often times the game will work without modification, and when it doesn't these days it is dramatically cheaper to improve Wine than to rewrite applications.
I do understand some of the skepticism though. A single bug can render an application completely unusable, so from a user's perspective it's very hard to tell whether Wine is 99% done or 5% done. But in the future, you won't even know you're using Wine -- it'll silently be powering your steam games.