CrossOver Support - Community Forums

It is pretty well known that different versions of Crossover offer varying levels of application compatibility. One application might run great under version 18, yet not at all under version 21. Yet if you do try to run multiple versions of Crossover, the bottles have to go through a conversion process everyone you change versions. I understand that every time you do this there is some risk of corrupting the bottle.

What if you could associate a specific version of Wine/Crossover on a per bottle basis? This would allow you to run apps in the best environment possible rather than having to settle for one static version of Crossover. This would take up more disk space, but I think the convenience and compatibility improvements would be worth it.

Any thoughts?

I’ll second this request.

In the meanwhile, you can create a Mac user account for each version of Crossover you wish to run. Put the version of Crossover you wish to associate with each account in ~/Applications instead of /Applications. By default, Crossover puts its bottles into a nested folder inside ~/Library so those will already be sequestered by account. Log out of your main account and into one of these other accounts to use the version of Crossover and that version’s bottles associated with that specific account.

Adding multiple versions of wine into CrossOver would become a support nightmare.

I would point out that Lutris and Heroic (open source Wine game managers) do this already. And of course Steam manages multiple versions of Proton.

Eric Volker wrote:

I would point out that Lutris and Heroic (open source Wine game
managers) do this already. And of course Steam manages multiple
versions of Proton.

I’m going to point out the obvious here but those are Linux specific and have there own issues, a good example being Proton can’t run Steam DRM titles.

For macOS the only currently viable sources to cover the vast majority of users would be CX19.0.2 (this needs heavily patching), CX20.0.4 (sincos & M1 GPU texture fixes) & CX21.0.0

Next comes the runtime (dylib libraries) this luckily can be resolved rather easily with a little finesse so a single set can be used with the three wine Engines.

The support binaries could all be in a single place to avoid duplicates.

Should all compatible Engines bundled within CrossOver or made into plugins will complicate things.

Next would be packaging CrossOver as there are specific requirements to code-sign/notarize the app bundle.

Most other things should be too complex but lastly we have the business questions.

From a business standpoint would it be worth constantly maintaining multiple old codebases requiring to back-port upstream patches into multiple year old versions of wine to keep them functional, if so what’s the support cost?

TLDR;
It’s possible but would it be worth it for CodeWeavers?

Part of the point would be to NOT patch the old wine binaries. Patching them might improve compatibility and/or performance with some apps/games, but also introduce regressions that would break others that are nominally supposed to work with version 19 or 20. My idea is to keep the code as much the same as possible such that if the app database shows that app X has 5 stars with Crossover 19, it remains fully operational in a CX19 bottle running under Crossover 21 (or 22 or whatever.) Now if the patching is necessary to ensure that the binary will run at all in a given environment (MacOS 12 or ARM64 for example), that's another proposition. However this would probably end up breaking compatibility with several of those games that ran well with CX19.

For M1 Macs, I would expect only the versions that have ever worked with ARM to be available (Crossover 20 and 21 I believe.) If Codeweavers would want to go back and patch it, that'd be OK I guess, but I'd rather they keep their eyes on the present and future versions.

Eric Volker wrote:

Part of the point would be to NOT patch the old wine binaries.
Patching them might improve compatibility and/or performance with
some apps/games, but also introduce regressions that would break
others that are nominally supposed to work with version 19 or 20.

I'm only talking about patching to keep the Engine running on the later versions of macOS it doesn't affect compatibility (I've literally done this with CX19.0.2 and CX20.0.4 prior to CX21 landing)

Eric Volker wrote:

My idea is to keep the code as much the same as possible such that
if the app database shows that app X has 5 stars with Crossover 19,
it remains fully operational in a CX19 bottle running under
Crossover 21 (or 22 or whatever.)

As long as the CX19 bottle is running using CX19 Engine the compatibility would still be the same (wine, wine32on64 on intel and wine32on64 Rosetta2 all have different compatibility)

Eric Volker wrote:

Now if the patching is necessary to ensure that the binary will run
at all in a given environment (MacOS 12 or ARM64 for example),
that's another proposition. However this would probably end up
breaking compatibility with several of those games that ran well
with CX19.

See my prior comment.

Eric Volker wrote:

For M1 Macs, I would expect only the versions that have ever worked
with ARM to be available (Crossover 20 and 21 I believe.) If
Codeweavers would want to go back and patch it, that'd be OK I
guess, but I'd rather they keep their eyes on the present and future
versions.

CX19.0.2 can work on the M1, but to run decently it does require changing some compiler options along with some backported patches will also improve the M1 compatibility and memory mapping differences in macOS Big Sur.

Hi folks,

I keep pretty close tabs on regressions introduced in new CrossOver versions, and for the past few releases the number has been pretty low. Are there a bunch of apps that are no longer working that haven't been reported anywhere? I'd also be very curious to know if there are specific applications that are broken on 21, work on an older version AND are known to have problems when changing between CrossOver versions on Mac.

Dean is right, this would likely be a support nightmare for us. We don't actually provide support for Proton like we do for CrossOver, so the support comparison there really isn't apt. We would also need to ship every Wine/MoltenVK/vkd3d/DXVK etc version with CrossOver that we would want to support, which poses several challenges and again is quite different from how Proton handles multiple Wine versions. That would also significantly increase the QA burden for a new release to have to check to make sure multiple Wine versions play nice with the updated CrossOver client. And then of course we would need to come up with a way to disable Wine versions for incompatible OS versions. I'm sure there are other obstacles, but those are the few that come to mind off the top of my head.

Bottom line, if we see more evidence that the number of regressions we're introducing in few releases is larger than we think AND the ability to simply run multiple CrossOver versions is running into problems we can't overcome, then we can certainly investigate solutions like the ability to change the Wine version on a per bottle basis. But considering how large a task that is, we might be better served by continuing to focus efforts to preventing regressions and releasing fixes quickly if they aren't caught in internal testing or beta testing.

Best,
Meredith

Thanks for the response Meredith. One thing I appreciate about Crossover is the responsiveness of the community, customer support and the development team.

The specific regressions I’m considering are Fallout 4 and Skyrim (classic). Even with the recommended DLL overrides Fallout audio is broken in Crossover 21. Skyrim suffers a problem common to all 32 bit games in Crossover 21; poor performance, practically unplayable. Of course there are other options, and Skyrim SE is also available. But the 32 bit issue is annoying when previous versions worked so well.

Since it appears that this would be a support nightmare, is there a middle ground? Would it be possible to deploy Crossover in such a way that multiple versions could be used side by side? Maybe by containing the bottles in Crossover version specific directories instead of converting the bottles in the same folders every time you switch? Such a directory structure would have Crossover 21, then 20 and then say 19 at the top level, and then each Crossover version would have its own bottles. Using multiple accounts is doable, but decidedly inconvenient.

Thanks for listening...

Eric Volker

Meredith Johnson wrote:

We would also need to ship every Wine/MoltenVK/vkd3d/DXVK etc
version with CrossOver that we would want to support.

The needed dylib libraries could be shared across all the wine versions, only the latest DXVK would be required and the older versions if needed could just become a crosstie.

Eric Volker wrote:

The specific regressions I’m considering are Fallout 4 and Skyrim
(classic). Even with the recommended DLL overrides Fallout audio is
broken in Crossover 21. Skyrim suffers a problem common to all 32
bit games in Crossover 21; poor performance, practically unplayable.
Of course there are other options, and Skyrim SE is also available.
But the 32 bit issue is annoying when previous versions worked so
well.

The Fallout 4 audio issue was mentioned that overriding the needed dlls now cause a crash for some reason. Skyrim was running slightly sluggish before CX21 but I didn't focus on that title during Beta instead opting to worry about Valves older gold source titles and good thing too as CS1.6 & Half-Life opposing force had some weird regression that was resolved in the following beta version.

Overall I've not seen any major speed regressions in 32Bit titles that weren't already running badly under wine32on64.

Eric Volker wrote:

Since it appears that this would be a support nightmare, is there a
middle ground? Would it be possible to deploy Crossover in such a
way that multiple versions could be used side by side? Maybe by
containing the bottles in Crossover version specific directories
instead of converting the bottles in the same folders every time you
switch? Such a directory structure would have Crossover 21, then 20
and then say 19 at the top level, and then each Crossover version
would have its own bottles. Using multiple accounts is doable, but
decidedly inconvenient.

Having isolated bottles per CrossOver version would need to be an advanced option as a common end user would expect when upgrading CrossOver version that their bottles will still be usable. To accomplish this CodeWeavers would need to modify there older releases updating the GUI portion of there app to support this then submit to apple to be code-signed and notarized again.

The only viable ways to handle multiple Engines is ether bundle every single version within the app (preferred) or have each one as a "Plugin" and the base CrossOver.app provides the current release. Aka CrossOver.app contains CX21.0.0 but can download and use CX19.0.2 & CX20.0.4 Engine Plugins.

Hi folks,

Awesome, I'm happy to have these conversations!

Couple of things here: first, are you having trouble switching CrossOver versions to play Fallout 4 on CrossOver 20? I switch CrossOver versions constantly, especially on my Mac (just part of the job description!), and I very, very rarely see issue with bottles becoming broken while doing that. . For Fallout 4 in particular, I've been able to revert to 20 even after having trouble on 21. If just launching a different CrossOver version works around the odd regression, then I'm having a hard time justifying taking resources from other projects to try to make a drastic change to CrossOver.

Second, I'm very curious to hear if Skyrim does worse on 21 than it does on 20. If that's the case, I'll happily investigate and file a bug for that.

Thanks!
Meredith

Thanks Meredith. First let me ask this; is there a ‘proper’ way to run two different versions side by side. What I have been doing is leaving the Crossover 20 app bundle named ‘Crossover’ and renaming version 21 ‘Crossover-21’. This causes some odd behavior where it seems like even though I’ve launched version 20, version 21 will spontaneously start by itself in the background. I haven’t done extensive testing of this, but it’s been enough of a problem that I resorted to using a separate account for version 20. Has anyone else experienced this? How would you recommend using both versions side by side?

Thanks,

Eric Volker

Just saw this discussion....

I have Chronicles of Riddick that ran fine with CrossOver 13 and never again and Diablo II and Summoner that stopped working for me in CrossOver 20.
The way I solve these and other things like switching some bottles to another place is to make a copy of the version of CrossOver that can run the wanted game/program where I change the BottleDefaults in the config file. So I have eg. a CrossOver13.app that points toward the directory containing only the bottles for that version. This allows me to keep track of what is where, test these bottles again with each new version and easily move them if necessary. No need for new users, etc.

So I am in 2 minds with the original idea (for Macs at least; I don't know enough Unix to have an opinion there). Especially now where Apple is cutting off the past, I would hate to end up with a version of CrossOver I can't run any more; be it because my machine is too old to be able to run a new version of CrossOver or my machine is too new to be able to run an old version.

I find it strange as I’ve found CX21 runs 32Bit titles better than CX20. But need to test Skyrim LE to see if I also get additional slowdowns when compared to CX20.

Eric Volker wrote:

First let me ask this; is there a ‘proper’ way to run two
different versions side by side. What I have been doing is leaving
the Crossover 20 app bundle named ‘Crossover’ and renaming
version 21 ‘Crossover-21’. This causes some odd behavior where
it seems like even though I’ve launched version 20, version 21
will spontaneously start by itself in the background. I haven’t
done extensive testing of this, but it’s been enough of a problem
that I resorted to using a separate account for version 20. Has
anyone else experienced this? How would you recommend using both
versions side by side?

Thanks,

Eric Volker

Use the following naming CrossOver-20.0.4 no spaces and preferably only have the CrossOver app bundles in ~/Applications/ but I’m not sure that makes much difference.

Eveline wrote:

Just saw this discussion....

I have Chronicles of Riddick that ran fine with CrossOver 13 and
never again and Diablo II and Summoner that stopped working for me
in CrossOver 20.
The way I solve these and other things like switching some bottles
to another place is to make a copy of the version of CrossOver that
can run the wanted game/program where I change the BottleDefaults in
the config file. So I have eg. a CrossOver13.app that points toward
the directory containing only the bottles for that version. This
allows me to keep track of what is where, test these bottles again
with each new version and easily move them if necessary. No need for
new users, etc.

I have Diablo2 working correctly in CX19/CX20 & CX21.0.0 on my Intel MacBook Pro running macOS Mojave/macOS Catalina and my M1 Mac Mini running 11.3.

Eveline wrote:

So I am in 2 minds with the original idea (for Macs at least; I
don't know enough Unix to have an opinion there). Especially now
where Apple is cutting off the past, I would hate to end up with a
version of CrossOver I can't run any more; be it because my machine
is too old to be able to run a new version of CrossOver or my
machine is too new to be able to run an old version.

The only viable versions would be CX19.0.2 (heavily patched) , CX20.0.4 (only needs a couple of patches) and CX21.0.0

I’ve done this and it’s really not worth the effort as overall CX21 has been much more stable and response, wine-6.0 is a more stable base on macOS than wine-5.0.

It's kind of known there are ways to run titles under specific hand picked wine versions and libraries. One all solution like this really doesn't work well. Case in point, the various versions of Proton. It's incredible we can even try this but I've personally found almost nothing runs on 20 or 21 for me on my M1. Can't speak to Intel version as I didn't bother to try on my MBP 16.

Bob Warren wrote:

It's kind of known there are ways to run titles under specific hand
picked wine versions and libraries.

That’s a large issue with the wider “wine” community as issues don’t get reported upstream, or when it is the bug report is missing useful information.

Bob Warren wrote:

One all solution like this really doesn't work well. Case in point,
the various versions of Proton.

Valve does all the support for Proton where CodeWeavers work on fixes/hacks or cherry picking upstream commits to add into Proton.

Bob Warren wrote:

It's incredible we can even try this but I've personally found
almost nothing runs on 20 or 21 for me on my M1. Can't speak to
Intel version as I didn't bother to try on my MBP 16.

Have you opened tickets for the titles that are not working for you?, overall a large majority of titles are working for me on my M1 Mac Mini. (Ignoring 16Bit titles as those outright don’t work via wine32on64)

Eric, I'm actually rather surprised to hear that another version of CrossOver will randomly start opening. If Dean's advice doesn't help, please see if you can identify any pattern for this behavior. I always have multiple renamed versions of CrossOver in both Applications and Downloads on multiple machines, and I've never seen that :/

And for anyone who wants to keep their bottles from being upgraded when switching CrossOver versions, we do have an ancient wiki explaining a workaround. This was recently tested internally and found to still be accurate, but please be warned this isn't exactly a supported feature 😊 https://www.codeweavers.com/support/wiki/mac/faq/cxmacmultiplecopies

Best,
Meredith

Dean Greer wrote:

Bob Warren wrote:

It's kind of known there are ways to run titles under
specific hand picked wine versions and libraries.

That’s a large issue with the wider “wine” community as issues
don’t get reported upstream, or when it is the bug report is
missing useful information.

Bob Warren wrote:

One all solution like this really doesn't work well. Case in
point,
the various versions of Proton.

Valve does all the support for Proton where CodeWeavers work on
fixes/hacks or cherry picking upstream commits to add into Proton.

Bob Warren wrote:

It's incredible we can even try this but I've personally found
almost nothing runs on 20 or 21 for me on my M1. Can't speak to
Intel version as I didn't bother to try on my MBP 16.

Have you opened tickets for the titles that are not working for
you?, overall a large majority of titles are working for me on my M1
Mac Mini. (Ignoring 16Bit titles as those outright don’t work via
wine32on64)

I'll try that, I've just started jumping into Crossover recently. Honestly, I want to help as I think it a cool technology.