Hi,
I'm trying to install software which is only for 64Bit Windows 7/8 availiable. How can I create a 64Bit Bottle?
thanks
Important Information These are community forums and not official technical support. If you need official support: Contact Us
The following comments are owned by whoever posted them. We are not responsible for them in any way.
Back to Threads Reply to Thread
Hi,
I'm trying to install software which is only for 64Bit Windows 7/8 availiable. How can I create a 64Bit Bottle?
thanks
You can't...
Crossover is still 32bit only, and I have no idea when the 64bit capabilities of Wine will be integrated.
Even then, not all distros have Wine packages with 64 bit enabled. The reason for this is explained in the Wine wiki. In short, the problem as I see it, is maturity. The maturity of Wine64 means your mileage will vary, so this is not what you want in a product like Crossover.
So, depending on your distro, you might or might not have a 64bit enabled Wine package, and if you do, your results might be far from perfect or usable. If you don't have a proper package, then you need to compile it yourself on top.
Actually this is a big flaw of this software. Is someone even considering adding support to x64? More and more apps are 64-bit only nowadays.
Bartosz K wrote:
Actually this is a big flaw of this software. Is someone even
considering adding support to x64? More and more apps are 64-bit
only nowadays.
It might be on our radar.
Bartosz K wrote:
Actually this is a big flaw of this software. Is someone even
considering adding support to x64? More and more apps are 64-bit
only nowadays.
I don't think it's a big flaw. There's just so many moving parts to the WINE project that it's amazing that they've gotten to this point IMO. In time 64bit-only program support will be implemented I'm sure, but like many other areas it's just not a main focus.
Caron Wills wrote:
Bartosz K wrote:
Actually this is a big flaw of this software. Is
someone even considering adding support to x64? More and more apps
are 64-bit only nowadays.It might be on our radar.
how do you vote for x64 support as a voting member?
Kendrick wrote:
how do you vote for x64 support as a voting member?
Write in and ask to be added to bug number 12725.
64 bit please. PlayonLinux and wine both support X64 and their Free as in GPL as well as free as in $$.
Get with the program. X32 is decades old and it doesnt support Origin and Dragon Age Inquisition as they both require X64 machine. Im sure there are other games..
One cannot even buy a 32 bit system anymore...
It is definitely something we want to do. The big problem is not supporting 64-bit on Linux, the big problem for us is 64-bit wine on OS X. There are hard technical problems there. Ideally, we would like to have 64-bit for both platforms. We are working on it.
+1 for 64bit support. I just tried installing Adobe Illustrator but if failed due to missing 64bit support.
Josh DuBois wrote:
It is definitely something we want to do. The big problem is not
supporting 64-bit on Linux, the big problem for us is 64-bit wine on
OS X. There are hard technical problems there. Ideally, we would
like to have 64-bit for both platforms. We are working on it.
Would you please elaborate on the "hard technical problems" with 64-bit WINE when running on OS X?
I would like to understand so I can make the decision on whether to use OS X or Linux natively.
Josh DuBois wrote:
It is definitely something we want to do. The big problem is not
supporting 64-bit on Linux, the big problem for us is 64-bit wine on
OS X. There are hard technical problems there. Ideally, we would
like to have 64-bit for both platforms. We are working on it.
My concern is why is Linux being held back because of problems with OSX. You don't see other software providers holding back Windows or OSX software because they are having trouble with a Linux version.
Fargo wrote:
Josh DuBois wrote:
It is definitely something we want to do. The big problem
is not supporting 64-bit on Linux, the big problem for us is
64-bit
wine on OS X. There are hard technical problems there. Ideally,
we
would like to have 64-bit for both platforms. We are working on
it.My concern is why is Linux being held back because of problems with
OSX. You don't see other software providers holding back Windows or
OSX software because they are having trouble with a Linux version.
I'm guessing because it's not a good idea to treat one set of set of your customers poorly. For that very reason that Linux users are ignore by Windows software supporters is why CodeWeavers shouldn't do the same to their MacOS X customers. It's good business.
64-bit WINE is supported/runs on Linux [not sure which distributions] - it is not supported/does not run on OS X. I was trying to understand why it does not run on OS X.
Linux is mostly POSIX-compliant but not certified and OS X is POSIX-compliant [could not find definitive source] and UNIX 03 certified [at least 10.5 is - hopefully that extends to 10.10 and upcoming 10.11] - so it is a reasonable leap to think that 64-bit WINE runs on both.
However, for OS X I believe it is an issue on the implementation of SysV shared memory - something about a conflict with WoW64 requirements and OS X requirements - they both use the same address for different things.
If this is the issue then hopes for 64bit WINE on OS X are dashed.
I would prefer to run OS X [personal choice] versus Linux and want to understand if there is a reasonable hope of 64bit WINE on OS X or not.
Well, I don't know about angst...
There is a problem here though. Where Linux is usually left behind or outright ignored, at this time we have a technical advantage which we don't benefit from in Crossover because of OSX. Such a situation does suck from a Linux point of view. I wouldn't call it angst, but to call the situation as "just fine", would be a disingenuous at least. For once, there could be a serious advantage for Linux users, and a sort of "political correctness" is preventing things from happening. I can't say I really blame Codeweavers on this choice, but I won't say I'm happy about it either.
That being said, at this time, I understand to 64bit wine technology on OSX is all but impossible. So there's a chance to see it in the future, but a lot of work needs to get done.
I think that some of the "support"/implementation issues with Linux is the slight [but critical from a support/assigning of resources perspective] differences between distributions, the way packages are installed, what non-GPL software is included.
Just thinking about all those dependencies that need to work makes my head hurt ...
OS X has the advantage of being consistent and there is only one entity that you go to [Apple] if you have suggestions/issues/support. Additionally Apple has a fairly large developer code and knowledge base. There is a good chance that someone else has looked at your issue and either solved it OR documents why it cannot be solved.
If you are a small company perhaps it makes sense to target the most consistent single entity OS with a large developer base [yes - it sucks for Linux - just as it sucks for OS X in that some application developers only code for MS Windows]
Sometimes it is also the original developer - i.e. MS Windows - who do not document/distribute how something works - i.e. DirectX - so you have to figure it out yourself and that takes time.
Honestly, if the dependencies make your head hurt, you've been doing things really, really wrong. I'm on Arch, and dependencies is the least of my worries.
And of course, the famous Mac stability, which has regular api breakage. That's why Mac users regularly complain their old version of Crossover stopped working. Yeah, that kind of stable.
This has nothing to do with developers, outside Codeweavers not wanting some whining on the Mac about how much Linux is better served.
In our minds it would be great if there was some sort of basic compatibility between all OSs but in the real world that is not the case.
It sucks that Microsoft will not implement DirectX 12 on OS X but as the owner of property that is their choice ...
I really believe it comes down to the users and whether they pay for something or not [either software/buying gold in a game/donating, etc.]... lets face it either you have a patron who pays all your labour and expenses OR you need to go out and get revenue to pay for your labour and expenses.
This makes for some very unpopular decisions/perceptions for software providers who need to go out and get revenue.
Perhaps their sponsor will not allow their to develop for a certain platform and you cannot tell anyone as part of the conditions of your funding ... only they know.
What we need to do is provide constructive and precise interpretation of perceived actions so the person you are explaining can understand what is being perceived and decide if that impression is correct or not.
If it is not, then we need to make them accountable for setting that impression right ...
J-P Simard wrote:
Honestly, if the dependencies make your head hurt, you've been doing
things really, really wrong. I'm on Arch, and dependencies is the
least of my worries.And of course, the famous Mac stability, which has regular api
breakage. That's why Mac users regularly complain their old version
of Crossover stopped working. Yeah, that kind of stable.This has nothing to do with developers, outside Codeweavers not
wanting some whining on the Mac about how much Linux is better
served.
Well I am not the one complaining that Linux is better served. Honestly I do not care ...
I am just trying to understand if there are real technical issues in regards to 64-bit WINE [WoW64] on OS X so I can make a decision on whether I want to continue to use the Mac Wrapper for a MS Windows based game that has released an native HD [MS Windows] version that requires 64-bit - OR - go to Linux and start using the HD version now.
As for OS X stability - really that old argument again ... blaming the OS instead of the third-party developer.
Is Apple responsible for non-Apple software [third-party apps]? No they are not - the third-party app developer is.
What about your particular Linux distribution? Have you had third-party apps break when you update? Is the fault of the Linux distribution or the third-party developer?
Finally when has Apple [not some new article looking for more hits and not providing documentation] promised backwards compatibility? I do not recall any instance where they have.
Actually, don't take things personally, I wasn't saying you were complaining at all. But, there are many that easily complain in the Mac camp, at least on these forums.
As for third party developers, if you break api(s) every release, yes, you're basically the problem. And it's not about promising backward compatibility, it's about not being a freakin' moving target while claiming to be "stable". A few releases without breaking anything would be great for developers, that's not Apple's game though.
With Arch, I can update every god damned day if I want. The last time Arch was responsible for a third party app breaking was... uhmmm... never. The last time I had any trouble at all was a month ago, and HP shot itself in the foot with help from nobody at all. Before that was about 3 years ago, when Crossover had a little trouble with Python 3, not exactly Arch's fault. Otherwise, it has been smooth sailing. In other words, every problem I have had on Arch came from the software being run, not the distro. Your mileage may vary of course, it's just my experience.
As for OSX vs. Linux, I'm not about to tell you what's what. That is definitely your choice, and I have no trouble you choosing either one. What I don't like is empty Mac rhetoric. Like your little quip about dependencies, which is FUD at best. Modern package managers usually take care of things without any problem in the vast majority of cases. Some distros are better at it than others, I'll grant you that, but I doubt there's any real "headache" situation.
As for the choice you face, the only thing I would say to really consider is video cards. The Apple side of things doesn't seem to offer the greatest of choices, so if gaming is a consideration, a wide variety of cards to choose from seems like a must. Other than that, I can't really think why you should change unless you're impatient, or there's a really big problem you can't solve on OSX. On another thread, the devs seem to think they have some ideas for 64bit Crossover on OSX. It would seem that patience is virtue...
Some of my thoughts on the matter:
If 64bit support can be done for folks using Linux, it should be done. Doing this sort of forced feature parity is detrimental. The platforms are similar but not the same. There are always going to be feature disparities. Sometimes they will be worked around, sometimes they might not because of technical limitations. If this is Codeweavers stance on 64bit support, what are they going to do about the enormous gap in support for OpenGL? They plan on bringing support for D3D11 at some point this year which will continue to be fixed and refined. OS X is stuck with OpenGL 4.1 and there are no signs from Apple that they're going to add support for a higher versions. Linux is not stuck. OpenGL support is brought in two forms. MESA which is a an open-source implementation of the OpenGL api supports OpenGL 4.2 and is very close to 4.3 and 4.4 support or vendor supplied implementations from Intel, AMD, nVidia (others?). AMD and nVidia support OpenGL 4.5. I'm not sure where Intel stands, don't really care about their integrated GPUs either.So what is the wine project going to do if some D3D11 functions require extensions available in higher OpenGL versions? What are they going to if by using extensions available in later OpenGL versions they can improve performance of the D3D to OGL translation? Are they going to gimp support because of OS X? If I even get a whiff of that I'm going to stop buying a subscription and end all of my activity as an advocate.
I've asked this questions when talking to folks from Aspyr and Feral Interactive. They've all stated that they do not and have no intention of gimping their Linux ports because OS X only supports OpenGL 4.1. Virtual Programming who also port to Linux and OS X using their wrapper tech called eON are already using OpenGL 4.2+ on Linux. (While initially eON was slower than Wine+CSMT it has come a long way and it now runs around Wine in regards to performance. Which is to be expected. Wine and eON have different objectives. One strives to become a complete Win32 API implementation, the other one needs to implement just enough to get games running.)
In regards to perceived fragmentation on Linux. As far as I can tell, currently, all builds of CX for linux run the same binary and use system provided libraries. So that means the latest Debian, Ubuntu, OpenSUSE, CentOS, Fedora, Arch and all of their derivatives. While other projects don't necessarily have the same stance as the Linux kernel of never breaking API, it's not like these people are out to somehow screw with everybody else and introduce changes that break things. The fact that CX runs on so many distributions with various library versions in use, tells a lot about compatibility in general and backwards compatibility in particular. On the other side of the fence, there's not a single major update for OS X where I don't read people complain on the forums about new and "magical" ways that Apple managed to break CrossOver. And yes, if Apple breaks APIs, **it's on them**. The fact that software developers rush to fix things is because of numbers. More users, more potential money. If this sort of breakage were to happen on Linux, I have a faint feeling that Codeweavers would just give up on the platform. Hell, I would.
One for the ninjas. Guys, this question has been answered before in the advocate forums and it comes up in the user forums more often now. There's a good chance that it will come up even more frequently as more and more Windows programs become 64bit only. It would be nice to have an FAQ page that we could link to.
Silviu Cojocaru wrote:
One for the ninjas. Guys, this question has been answered before in
the advocate forums and it comes up in the user forums more often
now. There's a good chance that it will come up even more frequently
as more and more Windows programs become 64bit only. It would be
nice to have an FAQ page that we could link to.
A FAQ page. Okay.
That I can do. Sorry, I'm a little behind in reading through forums, but I didn't want you to think I missed this request.
And so I've started:
https://www.codeweavers.com/support/wiki/64bit_Support
This is the kind of page that takes time to write. I'm not necessarily the best person to explain it all. On the other hand, I live to make things easier for our advocates. So for now, I have a start at explaining the OS X side of the world. I need to think about the Linux side a little. AND, I know that the same question will surface for Android so I've left space to give further explanation. I'm sorry it's not all that extensive at this time.
Caron Wills wrote:
Silviu Cojocaru wrote:
One for the ninjas. Guys, this question has been
answered before in the advocate forums and it comes up in the user
forums more often now. There's a good chance that it will come up
even more frequently as more and more Windows programs become
64bit
only. It would be nice to have an FAQ page that we could link
to.A FAQ page. Okay.
That I can do. Sorry, I'm a little behind in reading through forums,
but I didn't want you to think I missed this request.And so I've started:
https://www.codeweavers.com/support/wiki/64bit_Support
This is the kind of page that takes time to write. I'm not
necessarily the best person to explain it all. On the other hand, I
live to make things easier for our advocates. So for now, I have a
start at explaining the OS X side of the world. I need to think
about the Linux side a little. AND, I know that the same question
will surface for Android so I've left space to give further
explanation. I'm sorry it's not all that extensive at this time.
Thanks for the FAQ page.
Answered my question about OS X - do not like the issue but it is what it is ...
Out of curiosity, is there a way to get an experimental x64 build? I get the fact that doing 2 builds on linux, 2 on OSX, and whatever android work is bad enough as is, but supporting all that on umpteen distros must be a royal PITA. But as I stated before with other options you have steered away from, you have proven that you can make a lot of us happy with just doling out an experimental build whilst you progress to a supportable and stable proper fix. This should be doable.
Andrew Schott wrote:
Out of curiosity, is there a way to get an experimental x64 build?
Possibly, although we don't have an eta offhand. However, with 15 shipped, 64-bit is a priority. Of course, there are the holidays, and we also have other work to do (usually after a major release we have a bug-fix update soon, and dx11 remains very important, plus Android, etc.). However, beginning the work of 64 bit in our development branch is quite important.
Actually the very beginnings of this have been done, and more can be committed now that we've released. There are quite a few steps, even for something usable. The first is to get the build system creating a 64-bit CrossOver build (wine can do this, but there are some fussy pieces, and we need to have that integrated into our build system and automated). That work has started. After that, there are plenty of things to think about in terms of user experience. Initially it will be possible to create a 64-bit bottle, on Linux, by using our internal command-line tools. What we really need is a way to expose that in the GUI and make it easy, seamless, and automated for the user. I.e., some people will know and care what kind of bottle they want to create, but most won't. For quite a while yet, 32-bit is going to be a sensible default, so users are going to notice two different 'bitnesses' of bottles. Making it possible to control those things, both by the user and by our crossties, but not requiring everyone to spend a lot of time thinking about issue of the bitness of their bottles, is important. Then, once we have a mechanism for that, we need to do the empirical work of finding out which things work well in 64-bit and which in 32. Then there's the matter of fixing various bugs that only exist in 64-bit. (Then there's OS X, which is another tough nut to crack on its own).
The first thing to happen will be that we'll have the ability to create 64-bit bottles from the command-line, without support from crossties or the GUI. Once a few remaining issues are solved, that capability will show up in our nightlies. That's probably the best place to look for it at the start.
I also would be interested in testing out a 64bit version.
I have 2 - 3 applications who would really benefit from 64bit (Painting + 3D Modeling). Just in the case someone needs a lab rat tester.
For this reason alone, I cannot justify buying Crossover Office. Huge flaw.
Bobby Ratliff wrote:
For this reason alone, I cannot justify buying Crossover Office.
Huge flaw.
Not really a "huge" flaw.. More like minor or maybe annoying, but definitely not a huge. Let's face the reality.. 99% of users are using wine for gaming where is 32-bit enough. For me is currently sufficient to know that 64-bit is planned, even if i don't know what would like to run, maybe Alienware Command Center which is only 64-bit. Anyway, CrossOver Linux is working great for me and because i am from those 99% of users, i have a blast to play FF13-3 :)
https://appdb.winehq.org/objectManager.php?sClass=version&iId=33493
Any word on 64 bit bottle support? The new Blizzard game Overwatch is 64 bit only and I am really excited to get to play it.
Overwatch can only be installed from the battle.net application.
Overwatch requires Windows 7, 8 or 10, so I made a new Windows 7 bottle to install Overwatch into.
I tried to install Overwatch but it tells me I need to have a 64 Bit OS to install the game.
How do I set my bottle to 64 bit instead of 32 bit?
David Brooks wrote:
How do I set my bottle to 64 bit instead of 32 bit?
Simple, you don't because you can't.
If you want to play around with 64bit Wine, that's a whole other matter. I don't know about other distros, but on Arch the Wine package is 64bit enabled. By default, unless specified every wine prefix created will be a 64 bit prefix.
Cool, thanks for the advice. I will try to get the newest WINE 64 bit going on my compy.
Crossover Team,
Is there anything I can do to help in the efforts of bringing the world 64 bit Crossover? I would be happy to help test and troubleshoot issues.
While Darksiders II does work on Crossover 15.2, the 64bit only remastered version Darksiders II Deathinitive Edition does not.
http://store.steampowered.com/app/388410/
Please implement 64bit Linux support. I'll put votes towards it, if someone has a link.
As the last post was 3 months ago I'd like to push the thread.
Not reading all details (program only for 64-bit) I had to cancel my purchase on a game I shifted from release to now (pricing and corrections).
(rest of post deleted by author because of announcement by Josh DuBois in following post)
Our upcoming CrossOver 16 will support 64-bit on both macOS and Linux. The major holdup for games will probably be DirectX 11, which is still a problem. However, if your game requires 64-bit but does not need DirectX 11, and you want to play it on macOS using CrossOver, I'd encourage you to give CrossOver 16 a try.
CrossOver 16 will be released quite shortly, during the month of December 2016. I hope it works for you!
That are great news! I don't care that much about DirectX11 but I have graphic software that will hopefully get a huge performance boost with the 64bit version, even if it only would be the fact that I can use more than 4GB of RAM.
Can't wait for the release :)
Please Note: This Forum is for non-application specific questions relating to installation/configuration of CrossOver. All application-specific posts to this Forum will be moved to their appropriate Compatibility Center Forum.
CrossOver Forums: the place to discuss running Windows applications on Mac and Linux