Wine 8.5(winehq.org)
winehq.org
Wine 8.5
https://www.winehq.org/announce/8.5
92 comments
Wine (and Proton by extension) is a marvel.
Runs most of my windows software with little to no issue, and is more compatible with older games than Windows 10/11 itself!
Runs most of my windows software with little to no issue, and is more compatible with older games than Windows 10/11 itself!
Many people are still skeptical about wine and proton but in the future it will become the way to play Windows' existing game library. I always say that if you care about games preservation, you need to look at Linux & Proton. Even if a future version of wine/proton introduces some breaking changes, you can always use an older version for a particular game, much more comfortable than messing with Windows XP VMs and whatnot.
Wine and proton frontends are becoming so friendly too. Setting things up on e.g. steam deck is extremely easy, not just for wine but even for emulators (emudeck). Just click some buttons and you get everything set up for you and auto-updated.
Wine and proton frontends are becoming so friendly too. Setting things up on e.g. steam deck is extremely easy, not just for wine but even for emulators (emudeck). Just click some buttons and you get everything set up for you and auto-updated.
I couldn't agree more, with the addition of dosbox and PCem/86box.
There's a ton of titles from the late 90s onwards to ~2010 that don't work correctly on modern Windows - either very unreliable, have something fundamental broken, or don't start at all.
This especially applies to games from the from the pre-Vista era - things like DirectSound & DirectDraw being rewritten in Vista broke a lot. In addition, newer GPUs & drivers have broken older games - even big names like The Sims 2 have graphical artifacting - unless you use DXVK! I understand that sometimes this is due to the game doing something incorrect that happened to work okay at the time, but that's still unhelpful if I want to get something to run.
Running games from my childhood requires a mix of dosbox (for most classic DOS titles), PCem/86box (for really weird old titles that don't run on anything that isn't win95/98, or DOS titles that relied on 3dfx hardware).
Get a bit newer and it's dgVoodoo2 (for games that use old DirectX or Glide), DXVK (even on windows!), or I just give up and run them on Linux with Wine - which usually just works. The odd title still needs some patching (like eg Max Payne, but that's because of a CPU incompatibility with AMD Zen CPUs) - but it's nearly always less hassle than trying to run older titles on Windows 10 or 11.
There's a ton of titles from the late 90s onwards to ~2010 that don't work correctly on modern Windows - either very unreliable, have something fundamental broken, or don't start at all.
This especially applies to games from the from the pre-Vista era - things like DirectSound & DirectDraw being rewritten in Vista broke a lot. In addition, newer GPUs & drivers have broken older games - even big names like The Sims 2 have graphical artifacting - unless you use DXVK! I understand that sometimes this is due to the game doing something incorrect that happened to work okay at the time, but that's still unhelpful if I want to get something to run.
Running games from my childhood requires a mix of dosbox (for most classic DOS titles), PCem/86box (for really weird old titles that don't run on anything that isn't win95/98, or DOS titles that relied on 3dfx hardware).
Get a bit newer and it's dgVoodoo2 (for games that use old DirectX or Glide), DXVK (even on windows!), or I just give up and run them on Linux with Wine - which usually just works. The odd title still needs some patching (like eg Max Payne, but that's because of a CPU incompatibility with AMD Zen CPUs) - but it's nearly always less hassle than trying to run older titles on Windows 10 or 11.
I must be missing something, everytime I try to do something I end up wasting a day to get something to work unreliably. Seemingly simple apps that ought to only require the most common dependencies (such as dotnet/ie) are a nightmare to setup for me.
Every other time I try to do something the dependencies fails to download or there are bugs preventing stuff from installing.
What am I missing? Maybe games happens to bundle most they need themselves?
Every other time I try to do something the dependencies fails to download or there are bugs preventing stuff from installing.
What am I missing? Maybe games happens to bundle most they need themselves?
I wouldn't be surprised, if wine became a "compatibility layer" embedded into a wsl in Windows at some point
It is already a compatibility layer to run old windows software that Microsoft no longer supports. I use it for making music, and the number of 20+ years old VST plugins that work exceptionally well is astonishing. The only problem I encountered was some of their installers failing because they reported a negative available disk space, presumably because of a bigger new variable overflowing the older smaller one they use. Running them as a older Windows version didn't work, I suspect the only way to make them run would be to implement a WINE flag to pass the installers smaller variables with that data.
Aside that, I'm amazed at how good the compatibility is.
You could just create a smaller filesystem in a file, mount it and export is as a Windows drive in winecfg.
I did something similar: made a very small partition on a USB drive and assigned it a drive letter, then tried to install in there. It didn't work because it's the variable that is bigger, not its contents, so whatever value it contains it still overflows the one expected. Short of patching the relevant WINE code (which I don't even know where to start looking for) A XP VM might be the last resort. The software once installed works fine as I experienced by moving to Linux a very old XP install I had on a backup.
The fact that so many games work well with Wine is extremely impressive. I was playing Skyrim on my Linux laptop and it was a perfectly smooth experience.
What Windows software do you still need on Linux?
Anything 3D modeling related not covered by Blender, and software for 3D printing, just as an example.
The word "still" in your post suggests you expect F/OSS software to eventually become available for all fields of application. But that's not what I see happening; instead, there's no new desktop (as opposed to cloud) software being released at all, much less on Linux. So Wine is here to stay with us to (increasingly) run old Win software out of maintenance, and works surprisingly well. Of course, that's made possible by Win32 itself having excellent binary compatibility in the first place, as opposed to the Linux user land.
The word "still" in your post suggests you expect F/OSS software to eventually become available for all fields of application. But that's not what I see happening; instead, there's no new desktop (as opposed to cloud) software being released at all, much less on Linux. So Wine is here to stay with us to (increasingly) run old Win software out of maintenance, and works surprisingly well. Of course, that's made possible by Win32 itself having excellent binary compatibility in the first place, as opposed to the Linux user land.
So what we need is Wine in the browser.
A port exists, though it could use some more work on optimizing performance/browser integration: https://www.boxedwine.org/demo/
I use one fully open-source program (LMMS) which I've found a PITA to build reliably. But the Windows binary under WINE just works.
We have a stable binary format for Linux! It's Windows.
We have a stable binary format for Linux! It's Windows.
.. why would you build LMMS? you can just download the latest appimage and run it: https://github.com/LMMS/lmms/releases
or I could keep doing what's worked fine for me for years in a consistent setup, of course.
Use Guix, everything gets compiled fine, no matter what. If you need non-free because of $HARDWARE reasons, use nonguix, (or just a non-free kernel to avoid polluting the userland), but I won't help you on that.
Altough you can install guix on any GNU/Linux distro, on top:
https://guix.gnu.org/manual/en/html_node/System-Installation...
Then, run
Altough you can install guix on any GNU/Linux distro, on top:
https://guix.gnu.org/manual/en/html_node/System-Installation...
Then, run
guix pull
as a non root, and next,
guix package -i lmms
It sounds like WINE "just works" for their uses, "non-free" or not.
Audio latency under Wine would suck against a native binary from Guix.
the whole stack is free software, the API just originated at Microsoft.
or I could keep doing the thing that has worked in a consistent manner for me for years rather than gratuitously do something different, of course.
Well, Guix it's a universal solution over any distro, ensuring that whatever thing you install with it, it will get the correct dependencies with no dependency hell, ever. You can even have different library versions for different software. Guix will handle then in the background.
I'm glad this is not the default way of thinking for everyone, because if it were, we'd never see any progress.
I'm glad I have the choice not to follow desktop "innovation", because I was here for the history of GNOME 3, and Xfce's lack of ambition keeps proving correct. CADT is not, in fact, a good idea.
XFCE4 has been enhanced a lot.
and without pulling a GNOME 3
You can set up an XFCE desktop with ease from the Guix installer (Guix System,
as a standalone distro). I know, it's odd to setup compared to any other distro
, because the main recommended usage it's to pin a desktop/nm services
and such as system packages and the rest to be installed
with "guix package -i foo bar...", such as Firefox, Libreoffice...
But the rollback features from the Grub menu and ensuring no dependency hell, ever, can be golden for production cases and for reproducibility in science, for instance.
But the rollback features from the Grub menu and ensuring no dependency hell, ever, can be golden for production cases and for reproducibility in science, for instance.
you're coming across as having a much greater interest in wedging in a promotion for Guix than anything else
Winbox (Mikrotik configuration tool). Mikrotik seems to go out of their way to make sure it is compatible with Wine.
I suspect mikrotik devs to work on linux...
Can you compile code from within Linux to run on wine..?
I know clang supports Windows, but I haven't heard anyone have a crosscompilation setup like that (sounds handy!)
I know clang supports Windows, but I haven't heard anyone have a crosscompilation setup like that (sounds handy!)
The mingw toolchain is for cross compiling to target Windows. It is very mature and are used by many open source projects, especially desktop software which is popular on Windows but mostly developed by people running Linux.
In many cases you wouldn't even need cross compilation if you can run Windows tools directly on WINE. Years ago I installed Delphi 6 on a Linux machine with WINE, and although I didn't write any complex stuff or imported 3rd party components, it compiled every Delphi code I threw at it, producing native Windows code that ran flawlessly on Windows machines.
You could use Lazarus just fine.
Yes of course, I meant a native Windows compiler/IDE in general.
We actually run MSVC builds for Linux by running the VC++ toolchain in Wine, it works very well apart from process startup times, which have been getting a lot better.
Last time I used it was to configure two dual band ceiling access points and their PoE switch, and everything worked flawlessly, both on Debian (desktop) and Manjaro (this laptop). Happened roughly 2 months ago.
It goes even further: 64-bit wine works with Rosetta. I'm running Winbox, via Wine, on M1 Mac.
You got a tutorial for that? I tried to get wine working with rosetta a year ago and it didn’t go so well.
Agreed, that would be a great ''Show HN'' topic, vetinari
See the next sibling, https://news.ycombinator.com/item?id=35412055
vetinari, please do tell us how you did this
Not sure what is supposed to be complicated here:
1) install wine. Normally, you would do `brew install --cask --no-quarantine wine-stable`; however, if you managed to update to ventura 13.3, you will need wine 8.4 or newer, so `brew tap homebrew/cask-versions && brew install --cask --no-quarantine wine-staging`.
2) if you installed brew without `--no-quarantine`, try launching it now. The point is to appease Gatekeeper, so launching it in the future won't fail. It will also create a wineprefix, if you don't have one.
3) save your winbox64.exe binary somewhere. M1 doesn't support 32-bit mode (not even ARM one), so make sure it is 64-bit one.
4) launch it; wine64 /path/to/your/winbox64.exe. It will be handled by Rosetta automatically.
It should work now. In the past, with some older wine version, it failed, because some wine script called 32-bit binary somewhere down the chain; since I don't remember what version it was and what exactly it did, suffice to say that it was enough to add '64' in the script to the name of the binary called. With wine 8.0 and newer, it should not be a problem.
There are some fine details you can make it slightly better:
5) package it into MacOS app. Create the basic bundle structure (`mkdir -p WinBox.app/Contents/{MacOS,Resources}`), put:
Put winbox64.exe into `Contents/Resources`, some nice icon into `Contents/Resources/Icon.icns` (if you google, you can find winbox icon in the right format), and some basic metadata into `Contents/Info.plist`:
6) You will have a problem saving a session state. This is again gatekeeper; if I run winbox from a terminal with developer tools privilege, it will work. If I run it as the above app package, it will silently fail at saving. You can play around with granting privileges, but I prepared my sessions throught the terminal launch instead, and by running it via app package, they are read only, so I don't accidentally rearrange something.
1) install wine. Normally, you would do `brew install --cask --no-quarantine wine-stable`; however, if you managed to update to ventura 13.3, you will need wine 8.4 or newer, so `brew tap homebrew/cask-versions && brew install --cask --no-quarantine wine-staging`.
2) if you installed brew without `--no-quarantine`, try launching it now. The point is to appease Gatekeeper, so launching it in the future won't fail. It will also create a wineprefix, if you don't have one.
3) save your winbox64.exe binary somewhere. M1 doesn't support 32-bit mode (not even ARM one), so make sure it is 64-bit one.
4) launch it; wine64 /path/to/your/winbox64.exe. It will be handled by Rosetta automatically.
It should work now. In the past, with some older wine version, it failed, because some wine script called 32-bit binary somewhere down the chain; since I don't remember what version it was and what exactly it did, suffice to say that it was enough to add '64' in the script to the name of the binary called. With wine 8.0 and newer, it should not be a problem.
There are some fine details you can make it slightly better:
5) package it into MacOS app. Create the basic bundle structure (`mkdir -p WinBox.app/Contents/{MacOS,Resources}`), put:
#!/bin/bash
/Applications/Wine\ Staging.app/Contents/Resources/wine/bin/wine64 "$(dirname "$0")/../Resources/winbox64.exe
Put winbox64.exe into `Contents/Resources`, some nice icon into `Contents/Resources/Icon.icns` (if you google, you can find winbox icon in the right format), and some basic metadata into `Contents/Info.plist`:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>WineProgramPath</key>
<string>winbox64.exe</string>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>WinBox</string>
<key>NSHumanReadableCopyright</key>
<string>© MikroTik</string>
<key>CFBundleIdentifier</key>
<string>com.MikroTik.WinBox</string>
<key>CFBundleName</key>
<string>WinBox</string>
<key>CFBundleVersion</key>
<string>3.37.0</string>
<key>CFBundleShortVersionString</key>
<string>3.37.0</string>
<key>CFBundleIconFile</key>
<string>Icon.icns</string>
<key>LSApplicationCategoryType</key>
<string>public.app-category.utilities</string>
</dict>
</plist>
6) You will have a problem saving a session state. This is again gatekeeper; if I run winbox from a terminal with developer tools privilege, it will work. If I run it as the above app package, it will silently fail at saving. You can play around with granting privileges, but I prepared my sessions throught the terminal launch instead, and by running it via app package, they are read only, so I don't accidentally rearrange something.
Excel. Nothing comes close really
Interesting — I hear that repeated sometimes, but it always turns out that the person stating that opinion is an Excel expert and barely looked at anything else.
Having used Excel, Numbers, OpenOffice (since back when it was still StarOffice), and Google Sheets, I find it to be a mixed bag. For example, there are certain things which Numbers does way better (drag&drop rows to reorder them, for example) and I personally prefer it for my work. But most importantly, I haven't found Excel to be "way above the rest" at all.
Having used Excel, Numbers, OpenOffice (since back when it was still StarOffice), and Google Sheets, I find it to be a mixed bag. For example, there are certain things which Numbers does way better (drag&drop rows to reorder them, for example) and I personally prefer it for my work. But most importantly, I haven't found Excel to be "way above the rest" at all.
No offense but you clearly are not a spreadsheet power user (and to be clear you're starting off with what feels like a pretentious reply/generalization: always turns out that the person stating that opinion is an Excel expert and barely looked at anything else.) I have never heard anyone that has used both products deeply ever admit that Numbers comes close to the capabilities of Excel (and this includes a few former Numbers devs). They really aren't even in the same product category. For basic spreadsheet stuff that 90% of people do, sure, and Numbers does have some UI niceties - but the differences go well beyond drag and drop behavior. It's way harder if not impossible to use AppleScript like you can VBA. What is the Numbers equivalent of ODBC? How do you connect pivot tables to external sources? Excel has tremendously more builtin functions. Excel has far better performance, which can start to matter.
Meanwhile Numbers can have field types like star ratings. It uses a fundamentally different visual abstraction. Numbers focuses more on appearance and makes better looking graphs easily out of the box. At the limits of their feature sets though, these are really tools aimed at different audiences. For basic spreadsheet functionality, all of the major spreadsheet programs in the last 2 decades are serviceable.
Meanwhile Numbers can have field types like star ratings. It uses a fundamentally different visual abstraction. Numbers focuses more on appearance and makes better looking graphs easily out of the box. At the limits of their feature sets though, these are really tools aimed at different audiences. For basic spreadsheet functionality, all of the major spreadsheet programs in the last 2 decades are serviceable.
the major issue the parent eluded to was a sort of sunk cost fallacy that exists in the spreadsheet ecosystem.
Excel is great software, truly, what it enables people to do is impressive (and awful sometimes).
But once you have convinced yourself that its industry standard, why look as deeply into alternatives to even figure out if there are better tools? all of them will have quirks, some will certainly be more powerful in some areas (google docs has the ability to read data direct from bigquery for example).
Many already convinced themselves that excel is the one true format and there is no reason to look hard at anything else.
Others don't want their investment in learning to be wasted.
Theres a lot of people who are genuinely not incentivised to look at the ecosystem critically.
Excel is great software, truly, what it enables people to do is impressive (and awful sometimes).
But once you have convinced yourself that its industry standard, why look as deeply into alternatives to even figure out if there are better tools? all of them will have quirks, some will certainly be more powerful in some areas (google docs has the ability to read data direct from bigquery for example).
Many already convinced themselves that excel is the one true format and there is no reason to look hard at anything else.
Others don't want their investment in learning to be wasted.
Theres a lot of people who are genuinely not incentivised to look at the ecosystem critically.
> But once you have convinced yourself that its industry standard, why look as deeply into alternatives to even figure out if there are better tools?
I suppose that's true to an extent. However one of the reasons spreadsheets in general are so popular is their fluid accessibility. Just about anybody can get right to work even in Excel. Once you've gotten started in Excel there's little incentive to leave. That it offers a full blown powerful programming environment (which is definitely not the best in almost any area) erases much reason to seek alternatives. It's not a situation where Excel is meaningfully less accessible than the alternatives.
> Many already convinced themselves that excel is the one true format and there is no reason to look hard at anything else.
I mean this is sort of true. It's simple enough and good enough and actually insanely powerful on top of all that. What is the compelling reason to even seek an alternative? (saying this knowing full well that people often do, and usually it's Sheets).
And lack of external data sources is not a small potatoes feature (speaking in reference to Numbers here) - I think that alone puts Excel and Sheets way above Numbers. (And personally I can die happy not seeing another line of AppleScript for the rest of my days).
At least GSuite gives you browser accessibility - and even Excel to a large extent. Numbers ties you to the Mac desktop and iOS crowd. That seems like an already poor incentive to switch. It's great that it works for some people - but it's a niche product, where Excel simply isn't, period.
I suppose that's true to an extent. However one of the reasons spreadsheets in general are so popular is their fluid accessibility. Just about anybody can get right to work even in Excel. Once you've gotten started in Excel there's little incentive to leave. That it offers a full blown powerful programming environment (which is definitely not the best in almost any area) erases much reason to seek alternatives. It's not a situation where Excel is meaningfully less accessible than the alternatives.
> Many already convinced themselves that excel is the one true format and there is no reason to look hard at anything else.
I mean this is sort of true. It's simple enough and good enough and actually insanely powerful on top of all that. What is the compelling reason to even seek an alternative? (saying this knowing full well that people often do, and usually it's Sheets).
And lack of external data sources is not a small potatoes feature (speaking in reference to Numbers here) - I think that alone puts Excel and Sheets way above Numbers. (And personally I can die happy not seeing another line of AppleScript for the rest of my days).
At least GSuite gives you browser accessibility - and even Excel to a large extent. Numbers ties you to the Mac desktop and iOS crowd. That seems like an already poor incentive to switch. It's great that it works for some people - but it's a niche product, where Excel simply isn't, period.
To be completely fair though, Excel on MacOS is truly not the same software as Excel on Windows; which you will notice very quickly if you're a power-user.
Excel on Linux doesn't exist of course.
Excel on Linux doesn't exist of course.
I guess it depends how you define "power user". It's true that I don't write any VBA or use ODBC :-)
On the other hand, I do work (daily) on reasonably sized financial spreadsheets, with complex formulas, which also contain graphs, and use "pivot tables" (although I like the naming in Numbers much better, I never quite understood the name "pivot table"), things like conditional highlighting, etc.
I'm just saying that this isn't as clear-cut as some Excel users make it out to be.
On the other hand, I do work (daily) on reasonably sized financial spreadsheets, with complex formulas, which also contain graphs, and use "pivot tables" (although I like the naming in Numbers much better, I never quite understood the name "pivot table"), things like conditional highlighting, etc.
I'm just saying that this isn't as clear-cut as some Excel users make it out to be.
Is this because of compatibility and VBA macros?
In a vacuum, what Excel does is straightforward, and there's lots of free alternatives. Don't get me wrong -- I think it's a great program, but I don't see anything unique about it.
In a vacuum, what Excel does is straightforward, and there's lots of free alternatives. Don't get me wrong -- I think it's a great program, but I don't see anything unique about it.
> In a vacuum, what Excel does is straightforward, and there's lots of free alternatives.
That's true in theory, but Excel executes it so much better than Google Sheets or LibreOffice Calc.
That's true in theory, but Excel executes it so much better than Google Sheets or LibreOffice Calc.
Why? I occasionally use them* for taxes and whatnot, and they pretty much work identically. The differences seem at best marginal.
* - LO Calc and MS Excel.
* - LO Calc and MS Excel.
Similar to how databases are nearly identical superficially. Once you have a non trivial coupling the inertia kicks in. That said, depending on your use case (light usage minimial complex multi sheet macros) the differences are indeed minor.
An example would be helpful.
Do current versions of Excel actually fully work in Wine now?
That would be a big deal and if true embarrassing I didn’t know about it.
That would be a big deal and if true embarrassing I didn’t know about it.
mostly games for myself but I've also needed it for various weird programs that some professor decided we should use for some homework.
It's decent for games on MacOS now too. In particular I was looking at it for playing some FTL mods that are only shipped as windows binaries natively on MacOS a year or two ago (in the end I ended up using Codeweavers Crossover, but I think that the limitations that made me choose Crossover have since been fixed in Wine). I see that a Codeweavers dev is present in this thread (Hi guys, great product, thanks for helping make Wine what it is).
I think that there's still a ways to go for Wine on MacOS at least, like for instance I don't think playing No Man's Sky on MacOS via Wine is viable (or at least it wasn't when I tried a few years ago). I think that's more a limitation of the graphics API MacOS uses though. Supposedly a native port is on the way anyway.
I think that there's still a ways to go for Wine on MacOS at least, like for instance I don't think playing No Man's Sky on MacOS via Wine is viable (or at least it wasn't when I tried a few years ago). I think that's more a limitation of the graphics API MacOS uses though. Supposedly a native port is on the way anyway.
Tax software. The most popular in my country is Windows only.
AutoCAD Civil 3D would be the big non-negotiable one for me. It's a shame since I love linux but I have to use windows for work.
Office. And Visio.
It was good even decades ago. Wine is one of those projects that really impressed me back then and still does.
I gave up on Wine over a decade ago; I had no idea it has improved that much
When I used Wine around 20 years ago it was roullete if the application even starts. A few years ago I realized that it mostly works. Sure, some random little things could not work, some textures could be glitched, but I was confident that at least it will start. And it's constantly getting better (with some occasional regressions here and there, but it's bound to happen).
What's new in this release:
- Bundled vkd3d upgraded to version 1.7.
- Better error reporting in the IDL compiler.
- Support for shared Wow64 Classes registry key.
- More cleanups in IME support.
- Support for configuring a WinRT dark theme.
- Various bug fixes.Wine is just a great piece of software. Not just for gaming but the occasional dreaded enterprise software. I happily pay for crossover.
I have mixed experience with Wine, most of the times when I tried playing games it was close to impossible to install them. I go for Parallels Desktop those days (kudos to https://github.com/dreamncn/ParallelsDesktopCrack)
Works way better on linux. System tray support, desktop entries, and everything.
Just wondering, are there some things Wine can do that Windows can't? (Besides run on Linux)
Yes. Run 16 bit apps on a 64 bit OS install. A lot of old PC games no longer have 3D acceleration support on modern Windows like Jedi Knight I. On Wine the 3D acceleration just works. You can get Windows to do this stuff too of course but not out of the box.
Wine's 16-bit shim, winevdm, can even be run on 64-bit Windows to make it capable of running 16-bit apps.
We use this for running an old version of 16-bit Protel EDA on our work computers.
(Initially, I had setup a windows XP VM for this purpose, but it turned out to be a lot of friction for users, as well as requiring an annoying amount of setup)
Generally WineVDM works very well for running Protel with a few visual bugs.
That's funny, I had a dream about running a program in WINE last night
What can't be run in Wine at this point?
Is wine receiving patches from Valve's fork or are they completely separate at this point?
Proton developer here, working for CodeWeavers. Everything we develop goes preferentially in Wine, and is kept in Proton as a "hack" only when a solution clean enough for Wine is unfeasible or too complicated. Proton is periodically rebased onto Wine, so everything in Proton and not in Wine is additional rebasing work, which we'd like to avoid as much as possible.
Do you think Proton could be released on Steam for macOS? This could help rejuvenate the gaming community on macOS, which is suffering due to Apple's focus on the App Store. It seems like every decision Apple makes for macOS makes it harder to support games outside of their ecosystem.
On the technical level it should be totally doable. Whether that's something Valve is interested into, I don't have any privileged information.
I know people use CrossOver with Steam on macOS, though that requires a rather intricate setup I don't know much about. I guess what you'd like to have is the kind of seamless integration that Proton has with Steam on Linux.
I know people use CrossOver with Steam on macOS, though that requires a rather intricate setup I don't know much about. I guess what you'd like to have is the kind of seamless integration that Proton has with Steam on Linux.
Thanks for all the great work. I hadn't realised Proton was developed by CodeWeavers. Out of curiosity, what is the relationship between Proton and your own product Crossover?
In principle they are somewhat similar: they're both Wine + local patches (either backported from more recent Wine versions or hacks that are not suitable for upstream Wine) + some glue. CrossOver also has a GUI, which Proton doesn't need because the GUI there is Steam and Proton is supposed to be as transparent as possible. And like I said for Proton, it's in our best interest to keep the diff between Wine and CrossOver as small as possible, because that's a liability that takes its toll at each rebase.
In practice Proton and CrossOver tends to have rather different sets of needs. Proton only supports Linux and is only focused on gaming. CrossOver exists for a handful of platforms, most notably macOS (which has a number of intricacies: missing 32 bit libraries, Apple Silicon, missing Vulkan drivers which requires MoltenVK, but MoltenVK itself cannot really offer all the features standard Vulkan drivers have on Linux), and is also used for non-gaming applications. CrossOver also lives in the form of specialized branches we develop for specific applications, on request of their developers. So while of course we share everything that can be shared, in my experience this tends to be not that much (except what goes upstream, of course). In pratice CrossOver and Proton live in different repositories, have independent build systems and independent release schedules.
In practice Proton and CrossOver tends to have rather different sets of needs. Proton only supports Linux and is only focused on gaming. CrossOver exists for a handful of platforms, most notably macOS (which has a number of intricacies: missing 32 bit libraries, Apple Silicon, missing Vulkan drivers which requires MoltenVK, but MoltenVK itself cannot really offer all the features standard Vulkan drivers have on Linux), and is also used for non-gaming applications. CrossOver also lives in the form of specialized branches we develop for specific applications, on request of their developers. So while of course we share everything that can be shared, in my experience this tends to be not that much (except what goes upstream, of course). In pratice CrossOver and Proton live in different repositories, have independent build systems and independent release schedules.
Thanks for the explanation!
I've been a Crossover customer since their 2012 end of the world sale.
huge THANK YOU for the hard work on Wine, the entire community much appreciates, I'm a steam customer (400 games, no less!) and that's my humble contribution :)
note that I commonly buy all games that run on linux :)
note that I commonly buy all games that run on linux :)
AFAIK, Valve pays CodeWeavers to work on Proton, so Proton is more of a curation of Wine like CrossOver Office rather than a hard-fork.
I assume they're free to pull in as they wish? I didn't see any proton reference in the changelog though.
I would not have been able to move to Linux full-time without Wine. Thanks!