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."
Using GTK for Wine would be totally opposite to it's goals. While it might be nice for some things, it means that it's no longer possible to have exact Windows compatibility -- you'll be putting more and more hacks in to make things work, rather than actually reimplementing the Win32 API, like they have thus far. Overall, it might make 30% of applications look nicer, but it might break the other 70%, what do you think is more important?
Game! - Where the stick is mightier than the sword!
So, here's a direct link to the demo torrent.
Enjoy!
WoW has been working on and off lately, sometimes new patches break things, things usually get fixed again pretty quickly though, you might find this thread useful.
Game! - Where the stick is mightier than the sword!
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
The reason there are official "beta" and "pre-pre-pre-Alpha" releases is because it informs the community of the intended audience. The "pre-pre-pre-Alpha" phase is for interested developers. The "beta" phase indicates it's not ready for your production data, but if you are an interested user, you can help the project by searching for bugs.
Also, these milestones give the community a chance to judge how long it will be before the "official" 1.0 release. In the case of Wine, this is a decade in the making, and is a very, very, VERY big deal. So, it might only be a year before we see an official 1.0 version of Wine.
Commercial companies have learned that internal Beta releases do not find all the bugs, and so they have emulated the free software community by releasing early, releasing often. I feel this has helped products like MS-Windows become stronger products. They don't get all the benefits of open source, but they do get some.
In any case, if you are not interested in anything but the 1.0 release, that's fine; meanwhile, those of us who like the Wine project, and like to test and debug important projects know it's a fine time to jump in and help. Our participation will hopefully make your 1.0 experience a pleasant one.
Microsoft is to software what Budweiser is to beer.
I've had wine and Crossover office 4.2 run on 64-bit debian. It won't run natively in 64-bit mode, but it runs seemlessly as a 32-bit binary under chroot (or dchroot). You won't even notice that it's running in 32-bit mode.
Check out this HOW-TO from debian AMD64 on setting up a 32-bit chroot environment.
However, that support is fairly new, so we don't tend to recommend that people move all their books solely to CrossOver; that would be crazy (okay, so we're crazy [grin]).
And yes, the server is slow. We're working on it. The server is up; if you wait 15-20 seconds, the pages do come up. Just takes it a bit.
Cheers,
Jeremy
Had you actually chosen to purchase, you'd know that all those formats are available.
Try out fish, the friendly interactive shell.
Actually, for the record, you can run IE 4, 5.0, 5.5, 6.0, 6.eolas, and 7 all on one box....
check out QuirksMode Multiple IE
Updates I'm not so sure about; we just did it via the online tool and it worked, but we haven't tested (or triaged anyway) all the versions to make sure they all worked.
Cheers,
Jeremy
> > Finally, CrossOver Office Professional has the ability to create an RPM .TGZs or .DEBs?
> > package out of a bottle.
[...]
> What about
Tgz are supported too.
Just click on the 'Archive' button in the bottle manager. This will create a '.cxarchive' file which you can simply rename to '.tgz' if that's what you prefer. Then to install that file, click on the 'Restore archived bottle' button, browse to select the archive and that's it!
Alternately, on the command line you would do:
~/cxoffice/bin/cxbottle --bottle mybottle --tar mybottle.tar.gz
and then, possibly on another computer:
~/cxoffice/bin/cxbottle --restore mybottle.tar.gz --install
And voila, all that bottle's Windows applications are ready for use, complete with KDE / Gnome menus and file associations.
> In the past you have been able to tar the cxoffice and ".cxoffice" directory
.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.
> 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
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.
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.
.). 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.
.'
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. .
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.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
Yes, and yes.
.) in DX9WINE, which has been integrated into the Wine CVS tree.
Commercial?
Go to www.transgaming.com
World of Warcraft, Half-Life 2, City of Heroes, and many other games work properly under Cedega, Transgaming's version of Rewine (the BSD wine).
Wine?
Yes.
Wine main has quite a few DirectX features properly implemented, and Oliver Steiver (sp?) is implementing many Direct3D 9 features (like pixel shaders, etc. .
So yes, its been done, and yes, a lot of stuff works. Cedega gives me my gaming fix in Linux. I've currently got Eve Online, Secondlife, Half Life 2, Age of Wonders, World of Warcraft, and some other titles I don't play much installed. Works great.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
Actually, this is in Wine already. It's called $WINEPREFIX, and can be used like: WINEPREFIX=$HOME/.ies4linux/ie5 wine "C:\\Program\ Files\\Internet\ Explorer\\IEXPLORE.EXE" $@
The best way to accelerate a windows server is by 9.81 m/s2