Took the words out of my mouth. It's saved me from having to install complex or insecure VMs or additional machines so many times I can't count. I also enjoy using it to bundle applications usable on Linux and MacOS that otherwise were locked in to windows.
It's also a godsend for gaming on Linux. As long as you take a peek at the wine appdb page for the game you're trying to run beforehand, they usually work great and with pretty good performances.
Though granted the games I play tend not to be cutting edge (but for example, Skyrim with a large texture pack and a full, heavy mod conversion such as Enderal works perfectly and with CSMT, with performances roughly equal to Windows).
It doesn't really matter if they are though. It means we get "official support" - if something is broken, they are able (and I daresay, maybe even willing !) to look into it.
HumbleBundle games for linux have a history of being... suboptimal. Maybe they've improved over the past year, but HB doesn't really have a good method for fixing bugs in releases (unlike Steam).
I believe he's saying that gaming on Linux today goes far beyond Wine, given numerous high profile games have been ported to Linux recently (in a large part thanks to Unity and Valve's Steam OS push).
Not really far if you count games that sell 1 million+ copies. Right now I'm playing Titanfall 2, Battlefield 1, Forza Horizon 3 and Resident Evil 7. And Hearthstone. Haven't seen a game that I would enjoy released on linux in ages. Even new Doom didn't get a Linux release, id software gave up.
I get the impression they never had much interest in Linux ports in the first place, it was mostly just Carmack's interest in the platform that drove it. But now his attention is elsewhere, so they don't have to bother any more.
I believe they skipped Linux because Doom uses some Windows-specific DRM. Even the demo is protected by DRM, and it won't work under wine for that reason. So they lost my purchase.
Kind of negates the purpose of even using wine. If your running a windows machine to run a Linux VM then you might as well install straight to Windows and not deal with the underpowered VM
Also, last time I tried, the virtual graphics cards in the vm were much less powerful than a fully drivered up raw graphics card even on Linux, unless I was doing something wrong?
This has actually changed. A friend of mine plays all modern games with sometimes even better FPS using the PCI passthrough in QEMU[1], I have to say it's a pretty impressive setup and I've played Witcher 3 with Arch Linux + QEMU + Windows 7, solid 60fps with ultra graphics.
I was asking because the parent post seemed to be concerned about untrusted Windows binaries. A VM gives you the ultimate sandbox (even if it's not perfect).
With the exception that the Windows Subsystem for Linux can just rely on the opensource glibc et al. So, they basically 'only'[1] have to implement the syscall interface of the Linux kernel. They do not have to do any work to reimplement all the core Linux libraries in a compatible way.
Wine has a much harder task. Since the common Windows libraries are closed source and non-redistributable, the Wine project basically has to reimplement every API/ABI that Windows provides. This is a much larger and harder project.
It would be a nice gesture of Microsoft if they released some of the core Windows libraries as open source. But of course, that's not going to happen.
A few years ago, I'd have agreed with you. I used to be a card-carrying Microsoft hater for many years. And I still agree that the chances of that hapening are small, but given Microsofts changes over the last few years and the stream of open source releases, who knows any more...
Oh, I think it is extremely likely that, assuming no major leadership changes, Microsoft will open parts of Windows. But I think that they'd follow the macOS model - open the kernel and parts of the low-level user land. Enough to make small embedded systems in Windows, make developers happy with low-level profiling capabilities, and receiving more external contributions.
I don't think they will open source things Windows in a constellation where people could start making Windows distributions (which could lead to large incompatibilities) or run GUI apps on Linux or Windows.
everything they have open sourced has been developer oriented, nothing really in the realm of users applications and gaming. So I am doubtful, to say the least, that they will help wine in any shape or form in the foreseeable future.
Yes, the covered surface is much larger. Frankly I don't get why MS insists on keeping Windows closed source. I get why you'd want to keep something others might be able to easily reuse closed source, but I don't get why Windows developers don't get to see Windows source code. In fact, having worked with Linux extensively for the past decade, I don't think I'd be comfortable doing serious work on a system where I don't have source code for debugging and documentation.
Fantastic and very sympathetic small company which offers a next-next-finish installation of Wine. Excellent if you run a Linux desktop in a corporate environment that expects the ability to run Windows stuff.
The support of codeweavers is very good and fast as well, the two times I had to contact them.
The bottle system is amazing. It allows you to have multiple wine environments with different Windows versions seperated, so not just one Wine for all. Office 2003 runs on Windows XP, 2013 on a Vista env.
The bottles can be exported to RPM or DEB or shell installer for easy deployment as well. Plus the easy online database with appliations and profiles makes Crossover, for me at least, have a big advantage over bare Wine.
As far as I know, the "bottle" system is available in standard wine too (as wine prefixes), Codeweavers just provides a very fancy wrapper for the system and tools for managing the bottles. And that is definitely very handy if you want things to "just work" and dont want to fuss with prefixes yourself.
PlayOnLinux is a community application using WINE and with CrossOver you get full time employees working on the latest issues on Wine and first releasing their fixes into the application.
They then turn the code over to WINE downstream. So when you help CrossOver you financially help WINE and a person who will help you with your problem within 24 hours. Also CrossOver gives you their bottle system and a great website to get your stuff working.
Interestingly, CodeWeavers appears to be part of the reason in 2002 why Wine changed its license from MIT to LGPL. They were concerned about the fact that CodeWeaver's fork of Wine was proprietary.
CodeWeaver's Wine variant still seems to be proprietary according to Wikipedia -- I wonder what made the relationship between CodeWeavers and Wine evolve.
CodeWeavers's usage of Wine and other open-source projects has always been open-source. You can download our Wine fork source from our website[1]. We do use a small amount of closed-source glue to provide our installation magic and desktop integration.
Wine switched to LGPL due to other proprietary forks.
I believe it was actually that a different fork of Wine was not contributing back which caused the license change. I want to say it was Cedega but memories are hazy at this point (since I'm an outside observer).
Seems like a pretty perverse incentive to have the project largely funded by a commercial company offering a repackaging of the open source product with some added features that Wine couldn't add themselves least they compete with the benefactor directly and lose their funding.
It works pretty well for Chromium / Google Chrome, Fedora / Red Hat, Debian / Canonical, etc. Even the various Android skins (whatever you think of them) probably fall under this description.
Does anyone know how well Wine works with peripherals? I have a Windows device and driver+library that I would like to use with Linux. I am currently using a VM but would consider using Wine to simplify my install.
Depends on what kind of peripheral you're talking about. If the OS supports it, and we have code to use that kind of device (e.g. joysticks, storage devices), then it should "just work." If you need to install Windows-only drivers to get your device to work, then it likely won't.
We do have a guy working on getting raw HID support to underlie our device handling, which will improve things like USB device support and may even eventually allow installing some Windows-only drivers. But we're not there yet.
Thanks for the feedback. The device I am looking to connect required Windows-only drivers that were custom developed. I will shy away from Wine and stick to my VM.
I'm a loyal crossover user and can only confirm the very well done easy setup, handling and transparent support for all kinds of Windows apps, also bought a licence to support open wine development.
Wine is a great project, and truly 'is not an emulator'. It takes the main win32 APIs and they are reimplemented natively by posix means, GDI, USER32, ADVAPI, and so on. Time ago I run an experiment to port Wine to windows and run a notepad.exe on top of X11. After that I managed to wrap ActiveX components inside GTK2 bonobo components served on windows to insert them into Linux GTK apps so you could have UI-bound network transparent middleware components, and it worked. Sadly de Icaza changed the arch later.
> Wine is a great project, and truly 'is not an emulator'.
The Wine is not an emulator thing has an interesting history. It originally was officially called an emulator. The change was largely due to essentially marketing.
The first suggestion for the "Wine Is Not an Emulator" language was made in 1993, over concern that "Windows Emulator" might run into trademark problems with Microsoft. That suggestion was by Bob Amstadt [1] in a post where he also explained how the name "wine" came about. His original thought when he started the project was to name it "winemu", but didn't like that and shortened it to "wine", which led him to "whine" and "whinny". He liked "whine" but felt it was too long.
As far as I can tell, nothing ever came of that 1993 post. By 1997, though, the "not an emulator" meaning was in use as an alternative. According to the Wine FAQ from late 1997 [2]: "The word Wine stands for one of two things: WINdows Emulator, or Wine Is Not an Emulator. Both are right. Use whichever one you like best".
Calling Wine an emulator was dropped between releases 981108 and 981211. The 981108 release notes [3] say "This is release 981108 of Wine, the MS Windows emulator", and the 981211 release notes [4] say "This is release 981211 of Wine, a free implementation of Windows on Unix".
The dropping of calling Wine an emulator appears to have taken place for two reasons. One was that Wine could be used for more than just running Windows binaries on Unix. It could also be used as a library that could be linked with Windows source that was compiled on Unix in order to make a stand-alone Unix binary of a Windows program.
The other was that most users had only encountered emulators that emulated hardware (e.g., emulators that emulated old gaming systems or old 8-bit personal computers). Those emulators tended to be slow, which led most users to make the unjustified assumption that emulation necessarily implied slowness. If Wine was called an emulator many people would assume that programs running under Wine would be massively slower than those same programs running on a real Windows system. (I once had sources for the claims in this and the preceding paragraph but did not save them, and have not been able to rediscover them. They were probably posts in comp.emulators.ms-windows.wine in the late '90s if anyone with better search skills wants to have a go at it).
Interestingly that's how video game system console emulators after N64 got to be so fast, my understanding is the core concept is they just convert the machine instructions to x64 and do special linking to link the graphic calls to hardware-accelerated APIs.
Wine is at least distinct from emulators for recent consoles in that Wine is purely HLE techniques, without a low-level emulation component (although there was some work to integrate Wine and QEMU during the Mac Power PC days). Wine works on the level of the dynamic loader to handle a foreign object file format and intercept library calls, but all the machine code executes natively.
Use of Wine with QEMU was still a recurring topic even on Intel Macs (until this release) because 64-bit Windows binaries use a calling convention that isn't compatible with macOS.
It's also still a topic worth discussing in the context of ARM devices running Linux (be it on a smartphone or a netbook or a single-board PC). There's also the additional topic of whether or not Windows Mobile applications would be worth running via a native ARM->ARM variant of Wine.
Many years ago, probably around 2005 or so, I got tired of seeing threads on comp.os.linux.advocacy where someone would ask about the Linux equivalent to Windows program X, someone would mention that X works great under emulation with wine, and someone would jump in to say the Wine is not an emulator (and usually also manage to say "Windoze" or "Losedoze", refer to Microsoft as "M$" or "M$FT", and of course tell the first poster that it is "GNU/Linux", not "Linux").
I recalled that the people who actually wrote Wine had certainly called it an emulator, and so was curious why they had stopped. I researched it, wrote it up and probably posted it to to Usenet. Later, in 2009, I went to the "talk" page for the Wikipedia "Wine" article and added a note saying that there was some interesting history behind the interpretation of the project name that might be nice to try to work into the article, and gave the research and references so that if anyone wanted to have a go at it that could provide a starting point.
For the HN post, I just went to that talk page and grabbed my prior research.
The beauty is you can contribute in any way. If you're a web designer, you can help with their site. If you're a technical writer, you can help improve documentation. You don't need to contribute to the core codebase to contribute to the project at large.
Unless you run Debian stable (or probably any LTS distro), in which case they don't want your reports because "your software is too out of date".
I find this attitude odd, because there are (at least) tens of thousands of wine installs under Debian alone. Surely the information is relevant and useful to people, even if the version is no longer officially supported.
As a result, I've stopped wasting my time filing reports only to have them rejected.
The Debian upstream is crazy out of date for almost everything. I get why, I understand the thinking, but they have a point.
At some point vendors - especially open source vendors with limited (volunteer) resources have to call time on supporting older versions. If you're running an unsupported version, and the new version is free to download and install, why would they go out of their way to support you? Their thinking is quite reasonable: it's your choice to use a distro that doesn't track releases frequently, pull down and build a later version from them.
And looking at the release notes 6000+ changes have probably happened since your release. How can they possibly support you and a few thousand Debian users in that scenario with such a small team so focused on so much work?
Nowhere did I say that the WINE folks should support old versions.
I said that the information in the user report could be relevant and useful to people who still use that version, even if it's unsupported.
These are informational reports of "this app behaves this way under version x." So, and this is isn't about supporting an old version, this is about allowing or not allowing information about old versions in a database.
I don't think more information is harmful to the users, especially when it can help them make an informed decision about whether or not they must upgrade in order to be able to run a particular app.
Debian stable's Wine is often fairly old. I wish there was an easier way to get a newer Wine on stable.
They're rejecting your reports because the issues are often fixed in newer versions - someone would have to re-confirm your reports on a newer version.
> They're rejecting your reports because the issues are often fixed in newer versions
Sure, newer versions fix bugs from older versions. But they don't delete/archive the old reports after a new release, so the reports that are there are already a mix of supported and unsupported versions anyway.
So, I don't see the harm in accepting new reports against older versions, particularly when old versions are still found several major distros (particularly the LTS versions of those distros)
PlayOnLinux? It is a bit frowned upon and gaming oriented, but it offers one click install of any wine version, including unstable, with the ability of having multiple versions installed at the same time.
Hah, wonder when that was set up (wiki suggests Jan 2016). The last time I used Wine in earnest, you had to wget a whole lot of debs and manually install them. Kudos to the project for making it a whole lot easier to stay up to date.
Your best bet is to fire up a program you want to use under Wine with logging enabled. Look for functions that aren't implemented and submit patches, repeat!
Me too... I remember being excited when Solitare was running well under Linux.
One area where I've found Wine personally very useful over the years is understanding the Windows API. Without access to Windows source, access to the Wine source can be the next best thing to understand what a particular API should be doing. (Of course, it's been a while since I've written any Win32 code.)
Same here, I remember the very early days where even the most basic things hardly worked reliably when I played around with it. Back-then it seemed like a dead end to me, but that was 20 years ago or so... Glad to be proven wrong! :)
Cool. I have to admit I haven't thought about Wine in a while because I can't think of any software I use that doesn't have a Linux version. What are people's use-cases nowadays?
One I can think of right off the bat is gaming, especially old games that might never be ported to Linux (or, for that matter, remain compatible with newer versions of Windows). Also, for a while (before they DRM'd it) I ran the Reason DAW on a linux box. They didn't have windows 7 drivers for my MIDI keyboard at the time, but they did have Linux drivers somehow.
Some VSTs work flawlessly, others can be problematic and others do not work at all. You need to check them one by one, but surely a lot of them work.
(edit):
VSTs incompatibility doesn't just affect WINE but Windows itself from version to version. If you take a look at Reaper (reaper.fm), it has some options to run VSTs in various compatibility modes. This paired with WINE's ability to fake a different Windows version "emulation" should help with more problematic VSTs.
I really want to start using bitwig (it seems like Ableton, but better), but I can't afford it. In all honesty, I'm using a cracked version of Ableton that I found man years ago, but I can't really find (or securely test) bitwig cracks.
I am on Mac OS and the Mac OS version of Minetest seems to have some view movement issues--maybe it's a touchpad issue with that version, I dunno. So I tried running the Windows version in Wine and it's completely solved the problem, the game seems to run great.
Old games for instance :) I love this game from the late 90s called Thief: the dark project from Looking Glass Studios. I don't think there is any way to run it properly on a modern computer without wine or virtualization (which would require a copy of Windows 98).
Actually, you can still play it on modern versions of Windows. Thank GoG for that :)
1. Buy Thief Gold from GoG ($9.99) [1].
2. Install this [2] community patch to downgrade it to The Dark Project.
3. Enjoy!
Always look for any old games on GoG first. If you can't find a game there, you'll definitely find it on either retro gaming forums or private torrent trackers.
You can. At some point someone (probably one of the original devs) released anonymously a vastly updated version of the Dark Engine that Thief (and Thief 2 and System Shock 2) used that not only fixed any issues of the original but added several QoL improvements like antialiasing, raw mouse input, widescreen support, etc and since then he makes sporadic updates. Look for NewDark.
Sadly AFAIK he's still doing that anonymously through a french forum or something, probably because legally he shouldn't have the code. Despite that all modern re-releases of the games that used the Dark Engine (like those on Steam and GOG) are based on NewDark instead of the original engine.
And even games not all that old. I'm currently replaying Fallout 3 (from 2008) just fine under Wine. It really is amazingly smooth -- almost as if it were a native game.
2008 is literally 9 years old, all the current day titles I look up are basically rated "Garbage". I think this will improve though as the move to Vulcan and DX12 should make porting easier as the APIs are more similar I believe. The most recent big name thing I could find was WoW - which, while originally from 2003(?) is actively updated and has had some pretty substantial graphical improvements in more recent expansions.
How could miss the top 10 platinum ? it is literally on the landing page of the Wine applications database[1]. It has left 4 dead, Team Fortress 2, Civilization 4, etc. More recent than World of Warcraft which is only rated gold. Then the Gold list has starcraft 2 (Wings of Liberty, Heart of the Swarm, and Legacy of the Void), the sims 3, Final Fantasy XIV, Fallout 3,...
Though none of these are current day, they are not old games.
Yeah, those games are about as old or older than FO3.
WoW at least has had a recent update (including a basically total graphics engine rewrite last year, switching to a deferred pipeline, etc) and still runs well - I'd call it more recent, but maybe that's just me.
The rumour is that Blizard has a sort-of-unofficial support for wine for some of their applications and they at least try not to break it on each update.
Tag&Rename [1], a still maintained Windows-only shareware excellent at tagging music. Occasional use, Linux equivalents suck in various ways, it's perfectly configured to my needs, and works perfectly in Wine so why change it :)
EDIT: thanks for the Linux alternative suggestions everyone! I have (had) mostly the same complaints about ExFalso / Puddletag / EasyTAG as the ones I posted below about Picard (never tried Beets though). But most importantly, given this olde windows tool has been working fantastic for years, I don't see any reason to migrate my config and trust and habits :)
I've had mixed success with this before when it comes to organizing media. Is there any app which takes the middle ground of doing the work but letting the user confirm?
+1. Responded to the grandparent to say that I mainly use Wine for mp3tag. It's the first donationware software I've ever donated to! I bought him some CDs off his Amazon wishlist. It felt great to give back.
Thanks for that. I've recently switched to Linux and while puddletag is a decent replacement, I've got nearly a decade of experience with mp3tag I've been loath to turn my back on.
Last time I tried (which may be old): performance, opaqueness in what the musicbrainz magic is supposed/about to do to my files, lack of features and UX conveniences making it impossible to reproduce my stupidly picky tagging / filenaming scheme :)
I've heard that it is a magnificent game, but it is written with Direct3D 11, and although this Wine release notice states that "More Direct3D 10 and 11 features are implemented" and "Direct3D 11 feature levels are supported.", it doesn't seem to work yet (in "https://appdb.winehq.org/objectManager.php?sClass=version&iI... they state that it didn't work a month ago with Wine 2.0-rc1).
I have both linux and macos, but no windows computer apart from the work one - and this particular game doesn't seem to work in a VM (https://steamcommunity.com/app/210970/discussions/0/45860751...), with Wine, or in any other way except a native Windows installation.
In any case, Wine is superb work so I can't complain (except for John Blow's commercial decision). At least I have the hope that I will eventually be able to play without the need to buy a dedicated computer!
Usually my use case is connecting to either MSSQL or postgresql servers, but occasionally MySQL as well... I don't think Sequel Pro does anything other than MySQL, does it?
Windows 8 and onwards seemly have some bugs in DirectX9 or less, and although seemly there is Microsoft employees trying to fix those bugs, those bugs are years old and still exist.
Some games when using Wine, work correctly... For example on my Win 8.1 laptop Wine dlls were the only way to play "Arcanum: Of Steamworks and Magicka Obscura" (without the dlls, the game would render half of the screen black, and the other half flickering like crazy).
There are patches for Arcanum that make it work better on recent windows versions including ones for widescreen monitors. With those I can play it fine in windows 10.
Interestingly enough Arcanum was unusable under wine on linux and MacOS for me (it ran at about 1/10 the proper speed), so I now run it under qemu on windows 10.
It's pretty killer for running older / less demanding games. Lots of older games work better in Wine than they do in modern Windows, if at all. Also, for some indie games with half-assed Mac ports I've found it's often better to just run the Windows version in Wine.
I suppose it works with productive Windows apps too...
(1) You have to get Wine working, which can be kind of a hassle - there are a million different guides and ways to configure Wine especially wnen you factor in 32-bit versus 64-bit, winetricks, staging versus devel, etc.
It's hard to sort through all the potential ways and figure out the simplest thing to do, which is basically:
<Now launch 1Password via the .desktop launcher that should have been created for you>
(2) The password helper won't automatically start, so you have to choose "Restart 1Password Helper" from the Help menu after you start the main application.
Then assuming you want to use the browser extensions,
(3) You have to disable browser signature verification under Help->Advanced (while you're at it you might as well "tune for performance").
(4) The browser extension shortcut keys won't work, so you have to click the extension button instead of simply hitting Ctrl-\.
I see. Yeah only 1Password 6 works with the teams/subscription stuff and unfortunately they don't have any plans to support 1Password 6 on Linux (whether through Wine or other means):
1Password is awesome on Linux using wine. I use it with Vivaldi (and the chrome plugin in Vivaldi).
My other current use case is the original StarCraft.
I just read (on the appdb) that the 32bit version of Lightroom now works with wine, so I'll try that too - soon.
Now I am hoping for the "Affinity" tools (Designer, Photo), but they are still rated as "Garbage" in the appdb.
I did that for a while but then moved to doing things in command line imageMagick with 'eog' to see stuff. Then I moved to php imagick library as the command line tools were a bit 'high level' for what I needed to do.
Naturally I also moved away from Adobe vector editing tools to Inkscape and then to using vim to edit svg files.
Having discovered this 'convenient' way of working I am not enthused by the idea of installing some ppa to install Wine to install Adobe Creative Suite so I can get access to some version of Photoshop to then crack/hack it. Seems a lot of work to tweak the levels on an image.
Honestly since Steam came over I haven't really had an issue gaming. Though I'm pretty much exclusively an RTS player, and I know those are easier to port; FPS/action gamers may have different needs from mine.
I use Wine for MP3Tag (best tag editor I've ever used) and foobar2000.
Audacious is an excellent, excellent music player/frontend for whatever GStreamer backend you're using, but it can't handle in_vgm for Genesis/Megadrive files, the PSF plugin, and the ADPCM plugin for playing back Gamecube sound files.
Foobar absorbed all of the collective years of development effort to make Winamp play everything under the sun. That is slowly trickling into the Linux streamers, but they're not all there yet.
Wine is also great for random C# applets that people develop, like a HydrogenAudio tool I use to compare waveforms of FLACs and MP3s to see if the FLAC is a true FLAC or just an already-low-pass-filtered-MP3 converted to a FLAC.
Notepad++ - I once tried a bunch of Linux tools for editing a large text file (GBs), but none of them was performant and usable like N++ with Wine. This was a couple years ago, maybe things have changed since.
Evernote, sqlyog, MS Office (for compatibility or the more sophisticated functionality of Excel). Adobe stuff I run on virtualbox. I have to use Playonlinux and certain versions of the products to make everything work right.
Even with Play On Linux [1] I've found it a lot of hassle to try and run games through WINE.
For example I had a whole set of Tom Clancy games (Ghost Recon, Rainbow Five, etc.) running through WINE. Of course I noted how I got them running on the WINE Appdb. Then a couple of years later needed to reinstall - had upgraded OS, changed video card, etc. - and spent ages trying but ultimately failed. WINE's db had been cleaned and removed my reports, handy; and PoL just wouldn't work (possibly the APU??) despite reports to the contrary.
Sad, when ones knows these things can work. Even sadder with more modern games when the distributor/producers won't mess with WINE so the player doesn't have to.
Some versions like Office XP won't work but Office 2003 does. Office 2013 will install using PlayonLinux but won't activate or update or load templates from the Internet.
Myself I find Libreoffice to be better than MS Office.
Back before the demise of what.cd, I used Wine for Exact Audio Copy. As far as I know, there was still no "approved" cd ripper that would run natively on Linux.
I remember opening the thread shortly before WhatCD died. Whipper, a fork of Morituri had passed all the tests and was awaiting admin approval for at least 6 months.
WhatCD was a torrent tracker focusing on high quality and rare audio files. Your upload wouldn't be accepted if it wasn't made using an approved ripper.
Lots of professional software outside of software development is Windows-only. For a 3d hobbyist, lack of Photoshop and ZBrush makes Linux very hard to switch to.
I spent one evening trying to figure out why it was extremely slow (1fps) and why there were some rendering artefacts. Then I found out I was running with nouveau instead of the proprietary nvidia drivers (this was a new OS install on a new machine). After switching drivers it run extremely well.
I'm using wine to play Hearthstone. Also briefly tried to run Ableton Life but I gave up and went dual boot instead. Otherwise Linux has everything available I need.
Really, check out WPS Office on both Linux and Windows. It's a phenomenal MS-Office clone, 100x better than both OpenOffice and LibreOffice (because it actually acknowledges that MS-Office is a good piece of software).
I use Gnumeric and Abiword. I like the straightforward UI that doesn't try to be innovative or flashy and focuses on functionality. Do many people actually need a suite of several interconnected office apps? I just need to edit documents.
What is the technical use case for Wine these days? Are we basically talking running certain Windows applications on Linux, at reasonable framerates, using hardware that doesn't support full virtualization pass-through? In other words, if you've got virtualization support, and pcie pass-through support, why not just run this stuff through a Windows VM?
So I don't have to have the overhead of a full Windows virtual machine draining my laptop battery and filling my SSD with updates I didn't ask for to run the few windows-only applications I use.
I make extensive use of alt-tab. I have yet to find a smooth way to switch between applications running inside a VM and applications running outside the VM.
I also haven't found a way to achieve acceptable video performance inside a VM, short of dedicating a graphics card and doing a full PCI-E passthrough.
My one use case is that I have a legal copy of Photoshop 7.0 from the early 2000s that is my main image editing software that I'm still using on an almost weekly basis thanks to Wine.
It lets me run some of my favorite Window's programs like quickpar, winscp and windiff on my Mac without the bulk of a VM or requirement for a Windows license to run on that VM. I also don't have to maintain a Window's install.
A few years ago I was working on ReactOS and I found a bug in the list view control. After working hard on a patch, I submitted it and heard nothing about it. Have community relations improved since then?
I'm sorry to hear that. In order to avoid regressions, we have pretty rigorous requirements for patch submissions. Unfortunately this can result in dropped patches, especially in subsystems that no one in particular feels responsible for. We are trying to improve this, and we now ship a MAINTAINERS file that will hopefully help with this, and are also actively spreading patch review responsibilities around. I don't think we're significantly worse than most OSS projects, but that doesn't mean we can't improve.
In terms of getting a patch accepted, your best move is to include tests that prove your change is correct. Explaining how your change fixes an application will also help.
Will this be able to run Photoshop CC? I am desperately trying to move most of the production pipeline to linux, but Photoshop CC is the one product I can't seem to replace. I've mitigated part of this with 3D-Coat, but if I could have a native Photoshop CC on linux, it would be close to perfect.
I have photoshop CS6 working perfectly fine, just look around for a custom installer that doesn`t connect to the internet, you should find it in any pirate site
I have a lot of respect for the WINE developers.
It is a tremendous effort to implement an ABI to provide compatibility for a operating system such as Windows.
I still recall a fresh intern arriving in my office grinning and breathless one day, talking about Wine. We discussed it a little and I told him "it'll take a while before it achieves usable compatibility with major Windows applications".
you're falling for MS's marketing gimmick: "let's put the year in the product name so it will slowly shame and pressure people to give us more money for next years version (whose killer feature is a new splash screen with a year that is closer to now).
Maybe it's just the crotchety old man part of my personality but I don't like anything after Office 2003. The ribbon interface is a deal breaker for me.
Office 97 is the last version I ever bought or used. I used it for a decade, or so, to open those few files that didn't work quite right in OpenOffice (or AbiWord or KWord or whatever other program I was using back then on Linux). I'm glad I haven't had to open MS Office in about a decade. These days, I keep LibreOffice installed, but use it maybe a couple of times a year; Google Docs does everything I need.
You do realise 'let's put the year in the product name' is not MS' current strategy with Office though right? Office 365 is what is promoted most heavily now, for both business and home users.
It has web applications, but they do not replace the desktop ones feature-wise. When you buy Office 365 subscription, you get both web access and desktop apps.
If you use OneDrive, then you basically get just the web apps for documents stored in there (which is also the easiest way to check out).
There's a "light" version available online, but you must be thinking about Office 365.
Although the core product is still desktop based, they've been shifting to an optional subscription model where you pay $9/month or so for perpetual updates and 1tb of storage.
This model is great for me. It's very rare that I need to view or edit a document in an Office application but it does happen occasionally when the formatting is complex or something. Just install Office in a VM, pay $9 for 1 month of access, and unsub again when I'm done!
Microsoft Access is still used pretty heavily. As a developer, you may at some point be handed off an Access database. Additionally, Powerpoint still gets heavy usage, and switching to Google's version you're likely to lose a lot of design fidelity.
BTW if you find you need multiple versions of Wine for better compatibility with different apps (and probably even if you don't), PlayOnLinux is also a great tool.
Generally you should consider yourself lucky if you can run any old game. Even games that sold dozens of millions of copies and were released ten years ago are full of glitches, such as the early GTA series.
Wow, I never would have thought they could run better. I'm thinking of old titles, AoE II, Starcraft, etc. They have good ratings but I'm just wondering if it would be anywhere near as bad as when I used to run VMWare on my old Mac.
Both AoE II and Starcraft play totally fine now. But they used to run poorly on old wine releases from 6 years ago.
Any software that is around 15 years or older has a really good chance of running, I would say even more than Windows 10.
Newer DirectX 9 games, specially with the wine-staging patches, have a good chance of running, but nowhere near what current Windows can attain.
Anything newer with DirectX 10, 11 or 12 is pretty much a train-wreck. Unless the game runs OpenGL or Vulkan, like DOOM 2016, which after removing the DRM and some patching from devs runs like a dream.
> Anything newer with DirectX 10, 11 or 12 is pretty much a train-wreck. Unless the game runs OpenGL or Vulkan, like DOOM 2016, which after removing the DRM and some patching from devs runs like a dream.
Unless you run wine with the gallium-nine patches (which implements DirectX 9, 10, and parts of 11 natively on top of the gallium driver system, providing native DirectX performance on AMD and the open source nvidia drivers).
Sadly, the wine maintainers prefer their ugly hacks for their DirectX implementation, so it’ll likely never be merged.
VMWare has historically used emulation for kernel/privileged code when the host CPU doesn't allow for direct virtualization. VMWare also emulates peripheral hardware. Wine doesn't emulate any hardware.
As a general rule, assume that there will always be a performance penalty. It will be good enough to be playable, but you'll notice the difference, and you'll have to adjust the graphics down one or two notches (go down from "Max" graphics settings to "Medium" or similar). If you can live with this, you're fine.
Some games, in particular old games that don't rely much on 3D (I'm thinking of Age of Wonders right now), work really well, or well enough that you don't notice the difference.
I have some games that are unplayable, but thankfully those are rare (or I am just lucky). X3, for example, is glitchy as hell and the performance is very bad. Some games are also inexplicably slow: there are some PopCap games (very casual and "lightweight" games) that are just unplayable, for some reason.
However, with regards to being playable, I think that the graphical bugs will be the showstoppers, not performance.
Critically, WINE outperforms VirtualBox, especially if you account for starting up (or the overhead of constantly running) a virtual windows machine. Being able to run a few apps without switching off your dual boot machine or firing up a vm is nice.
On my laptop with an NVidia GTX 880m, under Windows 10 many DirectX 8 games run horrendously slow. Under wine these games run perfectly smooth as you would expect. It seems either Windows or NVIDIA did a lousy job of their DX8 compatibility.
This is perfect for gaming VM. Installing Windows in a VM requires an extra license. With Wine, I can install Linux in a VM and install Wine in it to run Windows games. Anything blows up in the VM can be rolled back.
Maintaining several wineprefixes is trivial too. The wineprefix describes where wine installs the "drive_c" and other stuff. So essentially it's the "chroot" of wine. It's of course more secure to do so in a VM but I run several wineprefixes locally for convenience.
Are you sure that's going to work? I don't think you'll be able to take full advantage of your graphics hardware that way. (Last I checked, Virtualbox and friends refused to allocate more than 256MB of VRAM... so I could play Duck Game and no more.)
I was thinking it'd be fun to benchmark an application running on Windows vs. that same application running on Wine running in the Ubuntu Userspace in Windows. I'd have to guess it'd be at least a few times slower.
That would make since, considering the overhead involved in translating the syscalls twice. It would be really interesting to see if/how the native Windows syscalls differed from the ones coming out of the Wine->WSL pipeline.
I have been wondering something for a long time. Why do some programs work better on specific versions of wine? I think that's what makes me feel iffy about the entire project. I know it's amazing work but I just don't get why that would happen.
We're rewriting an entire operating system. We have a pretty amazing regression test suite, but it's simply impossible to test everything all the time. Sometimes a change breaks something and it slips through the tests. If you find something that used to work and no longer does, please file a bug. We take regressions seriously; we even have a page dedicated specifically to tracking them: http://source.winehq.org/regressions
Wine has been good with the few Windows games that I play. (Dosbox with dos games is better, but it has been crashing way too often with certain titles.) Stuff works way better than in a VMWare box, games like Fallout, Jagged Alliance 2, GTA 3, VC, SA, even 4 at times, Fallout 3, New Vegas, Skyrim, Rise of Nations, most Needs for Speed.
Whatever glitches I get in Bethesda games, I google about them and quickly find out the same issues happen in Windows environments as well.
I also run many games that have native Linux ports in wine, because it handles sound better (pesky games these days presume I have a channel mixer set up)... like Faster Than Light.
I remember years ago (5?) Google was releasing Picasa for Linux, except the binaries were for Windows. Google had chosen to distribute it alongside a bundled Wine installer! Aside from the general distaste in bundling things, I was always impressed with how well Wine handled running applications. Otherwise, surely such a decision wouldn't have been made.
If I'm not mistaken Google also contributed patches to make Wine work better, but I don't know how critical the patches were.
I could't get my Windows 10 installation on my iMac to run the 2004 game Vampire the Masquerade Bloodlines. Tried it with Crossover for Mac (Wine based) - and it worked.
I use Wine to run the 64bit Windows client of GuildWars2 on my iMac. It is more stable than the current GuildWars2 Mac client. Graphics performance isn't upto par, but I need stability more for events and dungeons. ArenaNet is still building a proper Mac client after Transgaming was taking over by NVidia.
Wine saved my day to play my (Steam) games on Linux. It's not the same performance on Windows and there are many opportunities to improve, but just being able to play it's amazing.
Some Windows programs use the Internet Explorer API to display local HTML content or to provide an in-app browser. Gecko is used by the part of Wine that provides this API.
Grats to the Wine team, this is great!