Crossover linux — идеальный продукт для запуска Windows
CrossOver Linux — самое простое решение для использования приложений и игр Windows на компьютере с Linux. Это платформа представляет собой интегрированную виртуальную машину, которая запускает программное обеспечение, игры и утилиты Windows. В итоге, желаемая программа для Windows будет работать без сбоев.
Особенности CrossOver Linux
CrossOver для Linux предлагает множество удивительных функций. На основных из них остановимся по подробнее.
Устраняет перезагрузку перед запуском программ Windows
После завершения процесса установки вы сможете без проблем устанавливать и запускать желаемое программное обеспечение. И это не требует загрузки или какой-либо виртуальной машины для использования желаемых программ Windows.
Он напрямую запускает программное обеспечение Windows в операционной системе Linux. Для копирования файлов из одного системного файла в другой не требуется.
Установка в один клик
CrossOver Linux позволяет вам расслабиться, выполняя свою работу самостоятельно. Он имеет основную технологию CrossTie, которая является прорывом для пользователей CrossOver.
CrossTie позволяет установить ваши любимые приложения Windows за несколько простых шагов. Вы просто нажмете кнопку «Установить», и она сделает все остальное.
Программное обеспечение работает на собственной скорости
Вам не нужно запускать копию Windows, потому что это программное обеспечение работает на ПК с Linux. Это означает, что ваша оперативная память и процессор не будут платить дополнительную память за использование двух операционных систем одновременно.
Однако по этой причине программы и игры Windows работают быстрее, чем операционная система Windows.
Подробнее о играх на Linux в данной статье.
Таким образом, нет недостатков в производительности. CrossOver Linux — это комплексное решение для запуска приложения Windows на вашем компьютере с Linux.
Плавно объединяется с вашей рабочей средой
Поскольку CrossOver Linux запускает нужные программы Windows из родной файловой системы Linux, вам не нужно перемещать файлы между системой разделов Linux и программами Windows. Все в одном месте, где вы считаете это необходимым.
Есть возможность редактировать документы Windows и Linux. Более того, вы можете сразу запускать программы Windows, а не выполнять кучу работы перед его запуском. К тому же, в этом приложении ваши программы для Windows действуют как настоящие приложения для Linux .
Bottles — портативная виртуальная среда Windows
Одна из его уникальных функций — это «Bottles», которые позволяют отдельной среде Windows, такой как XP, Win7, упаковываться и быть автономными с вашей любимой программой. CrossOver Linux удобен для резервного копирования приложений Windows и перемещения их с одного компьютера на другой.
Это также гарантирует доступность правильной версии Windows, необходимой вашим приложениям. Такая уникальная особенность программного обеспечения заставит вас чувствовать, что вы работаете с несколькими разными машинами Windows на компьютере.
Установка CrossOver
Установка CrossOver c сайта
- Переходим по ссылке, нажимаем Free trial
- Указываем почту и Имя, и нажимаем Download Free Trial Now
- Подтверждаем место сохранения программы.
Нажимаем Install в появившемся окне, и указываем пароль.
Установка CrossOver в терминале
- Набираем sudo dpkg —add-architecture i386
- Затем sudo apt-get update
- Следующим шагом sudo apt-get install gdebi
- Пишем cd Downloads
- Вводим wget http://crossover.codeweavers.com/redirect/crossover.deb, а затем sudo gdebi crossover.debsudo gdebi crossover.deb
- Подтверждаем установку, нажимая y.
sudo gdebi crossover.deb
Заключение
CrossOver Linux — это приложение, которое изменит ваше представление о Linux. Из-за некоторых ограничений для Linux вы не можете запускать программы Windows на вашем компьютере с Linux.
Есть три основных фактора чтобы использовать CrossOver.
Во-первых, использование и установка CrossOver Linux — это просто и комфортно. Во-вторых, возможность переключения между операционными системами. В-третьих, вы получаете все утилиты в одном месте.
Run Windows software
on Linux with CrossOver
Even the most die-hard Linux users sometimes need to run Windows software once in a while. Some keep an old Windows PC around, some dual-boot, some use a virtual machine, while others have discovered the power of CrossOver Linux. CrossOver enables you to run the Windows programs you need on your favorite Linux distro like Ubuntu, Mint, Fedora, Debian, RHEL and more.
Easy, Efficient and Economical CrossOver Linux
Not only is CrossOver easy to set-up, our CrossTie technology makes installing your Windows software simple, with one click installation. Effortlessly switch between Linux and Windows programs and play Windows games at native speeds.
Unlike other cross-platform compatibility solutions, CrossOver doesn’t require that you purchase a Windows license ($99) in order to run Windows software on your Linux – and with licenses starting as low as $39.95 USD, CrossOver is the most economical choice for running your Windows software on your Linux distro.
Requiring less than 150 Mb of free space (depending on your Linux distro), CrossOver Linux doesn’t have the overhead of a Windows operating system like a virtual machine which means you don’t have to dedicate gigabytes and gigabytes of hard drive space. Allowing you to efficiently run the Windows software you need on Linux with CrossOver.
No Overhead, No Lag with CrossOver Linux
Not only does CrossOver Linux run productivity and utility software all in one application, it also runs games. Without the overhead of a virtual machine, games can run as fast or faster than they would under a Windows operating system.
Check out our What Runs database to learn what Windows software customers are using with CrossOver, and then download our 14-day, fully-functional trial of CrossOver Linux and see the magic of CrossOver for yourself.
Is the Windows Software you need to run on Linux compatible with CrossOver?
Need Help with CrossOver Linux
When you’re working with new software, we understand that getting started is often the hardest part. That’s why we have provided an extensive range of resources to help you do just that.
CrossOver Support
This no longer applies with the release of Crossover 16.2. We now offer support for some 64-bit Windows applications on Mac and Linux. We will leave this page up for archival purposes.
The technical world is moving to 64-bit everything, so why aren’t we?
The CrossOver application itself can install and run on 32-bit or 64-bit Linux distributions. If CrossOver is run on a 64-bit Linux OS it may need to add legacy 32-bit Linux libraries to the machine in order to have some Windows applications be functional.
But.. CrossOver can’t run 64-bit Windows applications. 64-bit Windows applications use different APIs than 32-bit Windows applications and it’s this translation that’s missing from CrossOver and preventing 64-bit programs from running. Whether the native Mac/Linux operating system is 32/64-bit doesn’t matter.
The most general reasons CrossOver does not have 64-bit support are discussed at WineHQ. The maturity of Wine on 64-bit means that your mileage would vary at this stage in development.
We face some general problems. CrossOver is noted for stability and adding 64-bit testing to the mix means that we add to what needs to be tested in exponential ways. That means having the resources to test it internally.
Challenges on Mac
OS X has an ABI incompatibility with Win64 — OSX overwrites a CPU register that Win64 applications expect to remain untouched. Apple can’t change the ABI because there are already 64 bit OSX apps that expect things to work that way.
If you are interested in the details, there is a significant amount of reading available:
Challenges on Linux
Challenges we face on the Linux Operating System.
CrossOver Support — Community Forums
The following comments are owned by whoever posted them. We are not responsible for them in any way.
I’m trying to install software which is only for 64Bit Windows 7/8 availiable. How can I create a 64Bit Bottle?
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.
It might be on our radar.
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.
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?
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.
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.
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.
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 .
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.
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.
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:
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.
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.
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:
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?
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.