CrossOver Office 5 and Wine 0.9 Released

Jeremy White writes "I am happy to report that we have shipped version 5 of CrossOver Office. The most user visible changes are support for Office 2003 and 'bottles' which lets you deploy Windows applications more easily than ever. But under the hood, this release includes all of the major work that went into the 0.9 release of Wine, which also shipped today and is now officially in Beta."

Comments

Re:Congrads to Codeweavers and the WineHG Team!

[Anonymous Coward]

I would rather see important apps ported to Linux. If there is so much demand for Wine/Crossover, then surely there is demand for the apps natively on linux? Ask your vendors where they are.

Re:Congrads to Codeweavers and the WineHG Team!

[saur2004]

Actually I can understand not wanting to bear the cost of two lines of developement. I wouldnt mind if they simply came out and officially said they would support users trying to run under wine.

Re:RPM?

[Dr. Spork]

Yeah, and you know what else kills me: you don't actually get any wine from these "bottles" - that just makes me want to complain and complain about all the other things they don't do.

But then some kind person smacks me and I realize that instead of complaining I should take note that what's shaping up here is a system for running Windows apps that's better than Windows itself! There is no Windows box that lets you run IE5 and IE6 side by side, and this is actually a rather practical thing to do if you're a developer. Also, I'll make a bet that Wine will do a better and more consistent job of running old Windows binaries than will Vista when it's finally released. This really is going to make an important difference for the future of consumer Linux and OSX.

Direct link to a torrent of the demo

[jeremy_white]

Hmm. Our new ISP isn't doing as well as we'd have liked; our servers are humming along at a very mild load limit, but we seem to be throttled out of the ISP (seems like it always takes one /. post to iron out the kinks at an ISP :-/).

So, here's a direct link to the demo torrent.

Enjoy!

Re:Hmm

[jeremy_white]

Yeah, we wanted to as well. Sadly, it needs wire compatible DCOM in order to work properly, and we just weren't going to get that done. We decided it was a mistake to hold up the whole release just for Outlook. We're going to go after Outlook next and hope to have it out 'soon'. Cheers, Jeremy

Re:RPM?

[fgouget]

> In the past you have been able to tar the cxoffice and ".cxoffice" directory
> and move the entire installation to another machine.
[...]

This still works and much better than ever before.
You probably remember that when you simply tarred and restored the .cxoffice directory from one machine to the other you were losing the menus and file associations. Then you had to go into CrossOver Setup and manually recreate each of them.
Now all you have to do is run the following command and all the KDE / Gnome menus, file associations and browser plugins will be recreated:

~/cxoffice/bin/cxbottle --bottle win98 --install

The point of turning a bottle into an RPM is that there are tools that will automatically 'push' RPM packages to a bunch of machines. Big companies usually use such tools. So now all they have to do is generate an RPM, upload it to their server, and what you did above for one machine will happen automatically for their 200, 400 or more desktop computers.

Re:What does Beta mean ?

[WhiteWolf666]

Well, the problem with Win32 is that much of it is unknown territory :) It's difficult to implement something that is completely undocumented while being quite as huge as Win32.

Also, certain things are unimplementable, but also don't work in modern Windows anyways. VxDs, for example, often break in XP. Multi-user support doesn't make much sense, given that each Wine 'install' (/home//.wine/) is single user.

The amount of implemented 'stuff', however, is quite telling, especially considering that the latest and greatest Office suite (2003) runs on Wine now.

Also, notice the update date on the status page? August 16, 2005 . . . . I know that the Direct3D stuff has come a LONG way; the status page lists d3d8 as 10% done, while in reality, d3d9 is almost there. Especially true with the gaming 'stuff', but also for general cases, support is app driven. 'X' app breaks because 'Y' function isn't implemented yet. So someone picks it up. Combined with a few general architechtural changes (like the Installshield stuff), you get 90% app support. Remaining work is completed on an as-needed basis. The flip-side of this process is that you get up to speed on new stuff coming down the MS pipeline.

To your second question. "Beta". What does it mean?

Beta means 'feature freeze'. Wine, as a Win32 API implementation for Unix, is useful now. You can run IE, Office 2003, Google Earth, Picasa, Photoshop, and a boatload of other popular apps. (Quickbooks, etc. . .). In order to keep it working for that stuff, it makes sense to stop generating new implementations, and work out as many of the bugs as possible. Thus, nothing to revolutionary will be accepted into the tree between now (beta) and 1.0 (release). Patches between now and then will focus on making sure existing functionality works properly. Once 1.0 happens, new features can be implemented on an as-needed basis.

So far, in 'alpha', the Wine developers were not afraid to break major parts of the API. Often, a snapshot would be almost unusable, or break dozens of applications. This is necessary when certain sections of the code had to be ripped out and reimplemented.

Now that Wine is getting more and more functional/useful, this development methdology will have to change. With release, it'll be safe for Linux distributions to list support for certain Windows applications using the free implementation of Wine. That'll be quite a coup if you think about it. 'Includes Wine 1.0, support for Office 2003, Internet Explorer 6, Adobe Photoshop CS, etc, etc. . .'

I imagine the Wine 1.0 tree will continue to receive bug/security updates along side newer versions.

The end vision of the Wine project is not emulation layer. The end vision of the Wine project is a fully functional UNIX app API, alongside things like QT/KDE, or GTK2/Gnome. Moving out of the haphazard alpha state of the project is a necessary step in its maturity.