Hey guys, so I’d like to know how crossover fairs against WINE. Not just in terms of compatibility but also in terms of installing.

One of the biggest issues I have with Linux software is the way it’s needs dependences from a repository. While there is no DRM but getting things to work offline can be tricky and from my experience requires a good understanding of terminal to make it all work. This includes getting dependences from the repository.

So which out of these two comes with most of what it needs without having to grab more stuff from the repo?

Is it weird that I keep reading this post in paul hogans accent?

Sorry I should have clarified that this is for ubuntu based systems like Mint. Well yes you can use Wine offline once you've installed all the dependences but that's not really what I'm after. That’s kind of how Steam does things where as I’m more after a GOG way. Something that works like a GOG installer where everything is packed into one file and is portable.

They have a tutorial on Wine HQ website though it' doesn't explain things too well. Basicly what you need to do is enter a series of commands in terminal that pull all the dependences from the repo and put them in a folder for you to install later. Not ideal but it's all we have for now.

First, keep in mind that I'm writing this from the perspective of an OS X user. While CX behaves very similar among OS X and Linux, I just thought it would be important to post that YMMV when it comes to CX as it does have some platform-specific caveats (like the OS X-specific Native Mac Driver vs. the standard X-based driver).

That being said CX installs the following dependencies with every new bottle created:

CrossOver HTML Engine
Microsoft Rich Edit 2.0
Microsoft Rich Edit 4.0 (msftedit.dll)
msls31
Uniscribe
Wine Gecko (32-bit)

...apart from that, CX has its own repo of dependencies that it downloads and installs in a manner basically identical to winetricks, except that the CrossOver Software Installer has its own seperate server from the ones called by winetricks.

I suggest you to just try PlayOnLinux to get an idea of what you get with crossover (but since crossover is a paid product you will also get some support).
Wine is a great thing but sometimes a game only work on some wine version or there is some problem find what winetricks to install... with POL and Crossover you will get a simple wine wrapper configured to work for that game.

I'm sure some linux guy will suggest you to make your own wine index (since you will get full control etc...) but I think easier is better and it is easier to use premade wine wrappers.

ahhh I see. Can you download those dependences yourself. Both the ones you've listed and the ones from the CX repo I did try POL and I could never get it to work on an offline station. is CX is much the same then that too could be an issue. If Wine is not an emulator why does it have compatibly issues. I should mention that I use Wine it works most of the time. It's just s little tedious getting everything together to make it work probably.

I'm a little confused; those dependencies are bundled with CrossOver itself, so you don't need to download them. Apart from the CrossOver HTML Engine (which IIRC is their in-house rendering engine for apps like MS Office) those are dependencies you can get yourself from winetricks with ordinary WINE. As for CX's repos, I'm fairly sure you could get at them with curl or something similar.

From what you say, it looks like what you want to do is use WINE in a completely offline fashion, without any need for network access. If so, I would think that just downloading everything from winetricks locally would solve your problem...

POL for me work offline. I don't think CX require any connection too.
Wine is an API layer, it translate Dx system call to OpenGL call.
there are many compatibility issues because dx and opengl are really different and many times there are some middleware that use strange API or proprietary not-standard library that is difficult to implement.

Emulator means that you create a cpu hardware component 100% with a software... pure emulation is really slow, but there are less compatibility problems...
but to make it work faster you need to use some mix of hardware virtualization (for example ps2 emulator use that)... and that is when problems come.

Virtualizzation is like Vmware or Virtual box virtual machine, you still use the same hardware but you install a different Operative system that support the same hardware.
this is the best method for 100% compatibility...

Wine is closer to native than virtual machine and emulation.

Emulation best compatibility, worst performance
|
Virtualization good compatibility, good performance
|
Wine worst compatibility, better peformance
|
Native better compatibility, better peformance

There are also problems with some games on wine because wine right now only support dx 9, when a game only use dx 11 you just cannot make it work.

Because WINE is a compatibility layer that translates calls to Windows APIs into calls to Linux/OS X APIs. For example, when a DirectX app like a 3D game is attempting to access Direct3D to draw its graphics, what it's really doing is using your system's OpenGL through WINE to do so. It's not an emulator in the sense that the term "emulator" is usually used to refer to a a CPU emulator (e.g. something you would use to run x86 apps on PPC computers, or something you would use to run console/arcade games on x86 computers).

The compatibility issues come from the fact that as what one would expect, stuff will break or not work fully as expected given that your given Windows app is running on top of another layer of software abstraction on top of your non-Windows OS, as opposed to running directly on top of an actual copy of Windows.

Edit: Ninja'd by LiefLayer!

Ah I see so no recompiling but same principal more or less.

Well, it doesn't recompile your apps, no. In the best case scenarios (e.g. Apps rated Platinum on the AppDB) you just install and use your Windows app in your Linux/OS X machine just like you would on a real Windows machine, with zero loss in performance or functionality.

That's incidentally true not just for WINE as it's usually used on Linux systems, but for commercial distributions of WINE like CrossOver or (the now defunct) Cider/Cedega.

woops. What I meant to say was dynamic recompiling. It's what emulators do to get games working on PC's. Dynarc is when the emulator looks at what is the is asking for and then recreates it. If a game want you draw graphics on the screen instead of vitalizing the hardware instead the emulator simply draws it. That's about as much as I know of how it works. Does WINE not work this way?

As far as I know, no, it doesn't. WINE doesn't recreate system calls made to Windows APIs; it translates them to calls made to system APIs that the host system can actually understand. In other words, WINE isn't pretending to be something it isn't; it uses what's already available and translates it into something the app (and the host OS) can use.

The problems arise when there is a gap between what's available on the host OS (for example, what graphics capabilities are present in the OpenGL 4.1 APIs present in OS X) and what the app wants (say, if I want to try to run a game which uses DirectX 11 :P), and its where WINE's limitations become most apparent.