Playing videos is a mess. winegstreamer relies on the system's gstreamer1.0, but, even after installing plugin-(good,ugly,bad), I couldn't make it work. wmv crashed, mpeg1 failed, mpeg4 was garbage. Various tricks are necessary: enabling devenum and quartz through winecfg, disabling winegstreamer, converting video formats, installing ffdshow through winetricks or externals codecs...
The console log was hardly useful when wine crashed. For example, a fatal error in msvcrt90 was caused by a missing font, but the default log made no mention of fonts, and even the `warn+all` level of logs was not clear. Fixing this and other problems took hours, and my final result was far from perfect. `winetricks` for fonts declares font substitution in Wine's registry, though Wine's changelog mentions using fontconfig, so I did not understand how fonts are handled (it's already hard to grasp in Linux, adding a layer won't make it simpler).
Overall, Wine is impressive, but, for some applications that are not documented for Wine and not packaged with PlayOnLinux, it may be hard to run them under Wine.
Not sure you really meant "mitigated" here, perhaps "mixed" is what you meant?
“Diminished” would be a more suitable synonym, but “mixed” appears to match the intent of the whole post.
(Of course there is Proton tricks too... and some games do require special settings)
I feel that the momentum around wine is building. Hopefully the issues you are mentioning will improve.
If you like what wine has become, don't forget to thank Codweavers!
Yes! I'm sure they appreciate kind words, but I thanked them by buying Crossover.
Is Proton just a fork of Wine? And if so, do patches flow in both directions?
Also 9 and 10, FYI. DXVK targeted 10/11 initially, and merged in D9VK (a separate but similar project covering DX9) about a month ago.
Proton also has a branch that bundles in VKD3D (Vulkan layer for DX12), but that's still experimental at this point.
A bit off topic, yet does anyone have experience running Adobe CC products (Illustrator, Photoshop mainly) with Wine? The following page has stats for older versions, yet if anyone's tried CC2020 I'd love to hear about it.
Photoshop CC2020 compatibility is rated "Garbage". https://appdb.winehq.org/objectManager.php?sClass=version&iI...
[Edited to hopefully be clearer]
You can downgrade to MacOS with proper 32-bit support, purchase Crossover 19, or ask Apple to put the libraries back in so tons of software people paid for continues to work.
Reversing course on this would be very against Apple's longstanding m.o. of breaking backwards compatibility with every new OS version. Looking forward is how they make the rest of the world advance at the expense of a lot of bloodied bodies left on the floor.
High level overview of how it works: https://www.codeweavers.com/about/blogs/jschmid/2019/9/10/so...
This thread has the technical details: https://www.winehq.org/pipermail/wine-devel/2019-December/15...
> WS11WineCX19.0.1 & WS11WineCX64Bit19.0.1 include wine32on64 and can function on macOS Catalina but these have not been signed or notarized so to make use of these you need to disable SIP in order for wine32on64 to set the kernal flag to allow 32Bit code execution.
I don't believe this is in the release version of Crossover atm?
32-on-64 support on macOS, you mean? I assure you, it is. https://www.codeweavers.com/about/blogs/jwhite/2019/12/10/ce...
That's a really short list. Hopefully there are no regressions on other games to cancel out the progress.
That said, I've been pretty happy with Proton. More games work than don't, although if the game you like is kind of obscure the chances of it working do drop off. Also some games outright check if they're running under Wine and refuse to run, like Roblox.
I thought WINE stood for Wine Is Not an Emulator - has that changed?
WSL1 did the same thing in reverse, though WSL2 abandoned that course and does in fact use virtualization.
WSL is what could be saved from the Astoria subsystem to run Android apps on Windows 10 Mobile, with the ARM virtualization story being nonexistent at the time for shipping smartphone SoCs.
IMO (this is just a guess, and might be completely wrong) but I have a feeling that originally WINE stood for WINdows Emulator.
When Wine runs an application or game, that program is executing directly on the computer's CPU, so it is not an emulator.
Think of it like when you have a Qt/KDE or Gtk/Gnome application and run that on the other platform, or on Windows or Mac. You have the APIs the application is calling (Qt or Gtk) which are the same regardless of the platform they are running on; for Wine these are the Windows APIs. The libraries then map the library APIs to the platform APIs, like how Wine is mapping the Windows APIs to Linux/Mac/etc.
Since you mentioned Amiga, there was an MacOS emulator called ShapeShifter, it didn't emulate CPU since at the time MacOS used the same CPU as Amiga, but it still referred itself as an emulator. Actually I remember that MacOS run even faster on Amiga + ShapeShifter than original Mac with similar hardware.
If you are not convinced, what about FreeBSD capability to emulate Linux ABI allowing to run linux binaries as if they were native. This also doesn't emulate the CPU and other hardware. And I suppose it is even closer to what WINE does.
Also in this case (unlike word "hacker") the word isn't used incorrectly. It's just more broad than most people think. It's only WINE that claims itself to not be emulator, despite in early FAQ calling itself Windows Emulator.
These two things are largely orthogonal. WINE also provides Winelib, which lets you compile a Windows application into a Linux ELF binary--doing the second thing without the first one.
There are actually game console emulators that do transpilling as well.
Anyway WINE originally stood for WINdows Emulator, which was reflected by the old FAQ still referring to it by that name.
Whomever came with backronym "WINE Is Not an Emulator" was simply wrong, and current FAQ actually tries to defend it, but then ultimately at the end states that more accurately it should be "WINE Is Not just an Emulator", because it does more than just emulating (for example it comes with Windows components, that you could even run on original windows).
I suppose they wanted to distance themselves from the notion that an emulator has to be slower, but this is not true. The ShapeShifter for Amiga was actually faster than MacOS with comparable hardware. Similarly all modern VMs now utilize hardware support so you're getting a native speed.
 not sure if this is the right word, since transpilling typically is used with source code, and I believe we are talking about translating machine code to another machine code.
The best solution is to use a GUI manager and you can have each game with it's own wine copy with different versions and configurations.
However like the sibling says, if you're doing something automated I'd recommend just using VapourSynth. QTGMC was ported to it ages ago and it will work better. I only continue to use AviSynth because the AvsPMod interface is still much better than the VSEdit equivalent, IMO.
So far, every not-free-open-source app I have seen which is not on the Mac App Store has caused problems:
- Spotify: does weird things to start at login and hide it from your system's start-at-login settings
- Dropbox: phishes you to get your root password
- Panic Transmit and Coda: exfiltrates your ~/.ssh/id_rsa file while not clearly documenting this
For 399 USD, I had hoped Bitwig could manage to get its app set up with sandboxing and into the store.
And don't forget wonderful dxvk project as well, which made DX9-DX11 games playable with great performance on Linux.
You might also be interested in Playonlinux (.com) which is a GUI frontend to WINE which helps in installing games and other software.
You can check here: