Wine 2.0 released
winehq.org
winehq.org
Grats to the Wine team, this is great!
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).
here FTFY.
We've come a long way since Loki ports.
Can you elaborate on this? My intuition is that running an application in a VM provides more security than in wine.
Given the context, I don't believe mark-r was talking about using a Windows host for the Linux VM.
[1] https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...
I don't know how much sandboxing Wine provides, so it might not be necessary to do this.
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.
[1] This is of course much harder than it sounds.
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...
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.
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.
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.
So worth every penny for the good cause.
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.
(Sources: https://en.wikipedia.org/wiki/Wine_(software)#History https://www.winehq.org/pipermail/wine-devel/2002-February/00...)
CodeWeaver's Wine variant still seems to be proprietary according to Wikipedia -- I wonder what made the relationship between CodeWeavers and Wine evolve.
Wine switched to LGPL due to other proprietary forks.
[1] https://www.codeweavers.com/products/more-information/source
Specifically, WineX aka Cedega
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).
[1] https://groups.google.com/forum/#!original/comp.os.linux.mis...
[2] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...
[3] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...
[4] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...
https://en.wikipedia.org/wiki/High-level_emulation
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.
You're either crazy fast with your research, or you have really looked into this in some depth. Great write-up, thank you.
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.
My very nerdy dream has always been to try to contribute to it somehow. How hard is it to get in to the community?
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.
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.
Maybe the policy about rejecting debian reports came way before they setup the repository.
I run it on top of Debian testing.
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)
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?
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.
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!
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.)
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.
Also I like to run HeidiSQL in Wine because there's not really an equivalent swiss-army-knife kind of tool that I've found that I like better.
[1] http://www.softpointer.com/tr.htm
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 :)
For something much simpler I recommend EasyTAG: https://wiki.gnome.org/Apps/EasyTAG
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] http://www.mp3tag.de/en/index.html
[2] https://appdb.winehq.org/objectManager.php?sClass=applicatio...
Though none of these are current day, they are not old games.
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 only issue is that on exit to desktop the game hangs and needs to be manually killed.
The new DX11-only re-release doesn't work though.
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.
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.
https://github.com/abique/vst-bridge https://github.com/phantom-code/airwave
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:
$ sudo add-apt-repository ppa:wine/wine-builds
$ sudo apt-get install --install-recommends winehq-devel
$ wine ~/Downloads/1Password-4.6.1.617.exe
<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-\.
1. sudo apt-get install wine 2. wine ~/Downloads/1passwod-blah.exec
On first launch wine configures itself and default configuration IMO works fine for running 1Password.
Last piece of puzzle is, making sure Password agent starts automatically when you login to dekstop so I have little .desktop file in ~/.config/autostart - https://gist.github.com/gnufied/c0615a8a90d21a8d575590b5001f...
https://discussions.agilebits.com/discussion/71733/where-did...
I've been using 1Password 4, which works fine: https://app-updates.agilebits.com/download/OPW4
Unfortunately I can't seem to make the 1Password 6 beta (which may or may not be the UWP app? Unclear to me) work with Wine 2.0.
https://discussions.agilebits.com/discussion/2846/new-produc...
Myself I find Libreoffice to be better than MS Office.
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.
tl;dr when PoL works it's great.
I have some minor apps I run like Zone Five Software's "Sports Tracks" (exercise logger), gaming helper utilities, etc.
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).
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.
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!
Thanks Wine team!
- Photoshop
- Accessing their DRM protected ebooks
So I use wine64 to run their command-line tools on FreeBSD, it works like a charm. :D
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.
Gaming on Linux using Windows games is a widely common use case. Wine works very well for most DX9 games already, but DX11 support is still quite WIP.
> if you've got virtualization support, and pcie pass-through support, why not just run this stuff through a Windows VM?
Because you don't want to run Windows? There can be multiple reasons for the later.
Today most DirecX 9 games work flawlessly out of the box (including one click install from steam, also running under wine).
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.
If I try to start up a VM with XP I've got to worry about XP's security situation.
"But does it run Cygwin?"
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.
This was in 1993.
This made me chuckle. Better late than never I suppose.
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.
The old installable still exists and many features only exists in that version. The offline version has also become a lot easier to install.
The web app version is lacking in a number of ways and was buggy last I tried.
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).
I haven't needed to do anything complicated, but I can open a document that someone's used "Track Changes" on, and modify it etc.
Although the late 80s Word and Excel for Mac would do perfectly well for 95% of today's users.
I've seen multiple sources claiming that CoD2 and WoW run with better FPS on Wine for example.
https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_see...
Also before it changed its name for the current retro acronym WINE used to mean WINdows Emulator: http://www.faqs.org/faqs/windows-emulation/wine-faq/
However, Wine is not an emulator in any way like the way that word is used in technology.
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.
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.
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.
-> Returns https://appdb.winehq.org/objectManager.php?sClass=applicatio... , which says it's currently classified "Garbage" as of 2.0-rc2.
But there was a screenshot of the main menu on Wine! Maybe it was some experimental branch of Wine or something.
1) Says it doesn't work when it works fine on default settings
2) Says it works and I spend hours and hours messing with settings trying to get it to work before giving up.
3) Only reports a version of my application that is so out of date that I don't care.
Granted I mostly use applications, not games, so perhaps it's better with games.
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.
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.
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 know its not, but sometimes Wine still seems like magic.
What is it used for?
Please correct me if I am wrong.
*you're
Should be merged within 24 hours or so.
It's apparently unusable. But the DRM comment made me question using TurboTax at all even on a Windows machine.
Good work Wine team.