Wine 1.0 — Uncorked After 15 Years
pshuke writes "After 15 years of development, Wine version 1.0 has been released. Wine is an Open Source implementation of the Windows API on top of X, OpenGL, and Unix. While perfect windows compatibility has not yet been achieved, full support for Photoshop CS2, Excel Viewer 2003, Word Viewer 2003 and PowerPoint Viewer 2003 have been among the goals prior to the release. For further information about supported applications, head over to the appdb. Get it (source) while it's hot."
By deleting the incomplete msxml dlls and setting winecfg's settings to use the native versions, then installing microsoft xml..
You can install and run Microsoft Office 2007.
I do find it a little disappointing that Wine didn't set getting Office 2007 working out of the box as a goal for 1.0, as it really currently just relies upon finishing two DLLs.
Change is certain; progress is not obligatory.
Obviously, sooner is better for actual use; but releasing it on June 30th would have been more amusing.
Don't forget the main commercial sponsor CodeWeavers. Alexandre Julliard, one of the leading developers of Wine, now works for them. Their main product is CrossoverOffice, which regularly snapshots the Wine branch and then does bugfixing on it. Then they charge $40 for a solid and stable version, and include a GUI to make installing IE and other applications a cinch.
It's a small shop and very sympathetic. They also read Slashdot. Jeremy, the CEO, is active here as user jeremy_white. Befriend him to let his comments show up as +5.
Disclaimer: I'm just a happy customer since version 4 (about 5 years ago).
8 of 13 people found this answer helpful. Did you?
while I wait for you bastards to stop hammering poor mozilla.com.
And of course such a program would be pointless anyway. If 'Designed For Windows' apps don't work under Wine then Wine itself has failed its objective.
I dunno...Personally, I like my wine at room temperature.
It goes great with vintage Windows apps.
Oh, and bread.
I would really like to try out Wine, but I couldn't find the WinXP version on the site, which is strange because usually open source apps get ported over really quickly. I tried installing the source tarball in CYGWIN, but no avail. Anybody know where I can get the Win32 binaries?
weirdest thing I ever saw: scientology advertising on slashdot.
uTorrent already does, last time I checked.
I was debugging a Half-Life crash once and I noticed it checks the registry for Wine keys while starting up, probably for compatibility hacks.
uTorrent does, and lists Wine first.
x86, oh yes, I'm pro.
how many applications will state "Designed for Windows XP, Vista, and Wine 1.0" as a supported platform. That will be the metre stick for success IMHO
.NET 3.5 SP1 for some interesting demos of how far WPF has already gone in just a year.)
Quite a few in the non-commerical areana already do list Wine/XP/Vista etc...
However,Wine may be a little late to the game. Virtualization will give us all the features we once needed Wine for if done properly.
The other problem with Wine is the evolution of the Win32/64 API, and how it is slowly being replaced. Vista API technologies are not even on the radar, and have the potential to shake up the next generation of application development. (Search Channel9 on WPF
Microsoft sees a movement away from Win32 before too long, and even current applciations a lot of developers are working on projects that stretch from generic Win32 to fully hybrind Win32/WPF/DirectX all in one application.
If Virtualiation doesn't solve the divide, we still have Wine and Mono, and for any future, some of the backend of the current Linux kernel will need to extend to handle hardware with the same levels of abstraction, or shoving DX to OpenGL will not be enough when some of the core aspects of WPF is based around 3D UI that uses aspects of the OS to schedule and manage the 3D aspects so that two applications don't fight for 3D GPU resources, and currently only Vista's design allows for this.
(Didn't mean for this post to go negative, as there is a congrats to the Wine peeps in order, and even if Wine translation doesn't last forever is meeting a lot of people's needs now.)
Wine doesn't have a logo? I'd send you a link, but the website is down. Oh wait! All I had to do was scroll up to see it ON SLASHDOT!
And of course such a program would be pointless anyway. If 'Designed For Windows' apps don't work under Wine then Wine itself has failed its objective.
IIRC, Wine's objective is to give software vendors a set of libraries to compile their Windows software against so that it will run under Linux, not necessarily run all windows software natively in Linux. The idea is that if it is so simple to do, people like Adobe will release a Linux version of Photoshop compiled against Wine.So actually, getting products to say that they are "compatible with Wine 1.0" is the goal. That is also the reason that they are releasing: it gives vendors a stable branch to work with.
weirdest thing I ever saw: scientology advertising on slashdot.
It goes great with vintage Windows apps.
Many a true word was said in jest. Back in 1998 I wrote a small Windows program at work (~3000 lines of Turbo Pascal 7.0, Win 3.1) and tested it at home on Wine on Slackware. It worked fine.
Wine is an astonishing project. It deserves a lot of credit.
Stick Men
the same can be said of Windows....
If you believe everything you read, you'd better not read. - Japanese proverb
Using wine is a stop-gap measure for running Windows apps on Linux. All users of wine (and I am one) should write to their applications' developers and let them know that they would like native Linux support. I have a list of tens of software house and their contact info, for writing to software developers. Please, if you use wine, at least write to the application developers and let them know that there is demand for their products on Linux. Whether the apps work in wine or not.
It is dangerous to be right when the government is wrong.
And there is a fatal flaw in your pointing out that he has a fatal flaw in his last argument, namely - Wine is not an emulator
At the very least, write to them if it doesn't run in Wine.
Porting a software project can be a very nontrivial task, taking many manyears of work to complete. Few companies are willing to invest this kind of work (and money) for what seems to be a rather small customer base. They could, though, be willing to invest in a few tweaks to make it run on an emulator that would accomplish, from their point of view, the same thing: Letting Linux users use their software.
Companies are usually reluctant to develop for a platform with a small customer base. They do, though, accept making a few tweaks to get a foot into the market.
Currently, the only argument for people to keep using Windows is that Wine can't handle EVERY SINGLE Windows application. When there is no important application left that doesn't run well on Wine, people will more readily switch (Linux+Wine == Windows, from a user's point of view, but about 100-300 bucks cheaper).
And THEN it's time to ask software companies to develop for Linux, with it being the bigger market.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I don't think you understand the reality of WINE, especially to Microsoft!
With WINE, Microsoft officially loses control over their Windows API. It's like IBM with the ISA vs. MCA architectures around the 286 era. Microsoft desperately wants to move to something else, ANYTHING else, so that they can maintain control of their API, so that developers have to write to the Microsoft API, and so that customers still have to buy Windows.
But if there is a WINE that is reasonably stable, that's no longer the case. Case in point: I develop a cross-platform application with PHP-GTK, which has been ported over using the Win32 API. I can write software that's immediately usable on Windows, Macintosh, and *nix. But I haven't released an actual installer for *nix, simply because nobody's asked for one. And if I decide that I want to support *nix, I have to go with at least one of two options:
1) Pick a distro or five and build packages for each every time I issue a new release. (as often as weekly!) This is pretty much a guaranteed FAIL since everybody has their own fav distro...
2) Release a Windows installer and test it against WINE to ensure reasonable compatibility.
I'm going with option 2 for now. Note that I prefer this even when using a toolkit that's natively a *nix toolkit. It's not because I don't love *nix, it's because I have no desire whatsoever to deal with customers who are often barely competent to turn their computer(s) on and try to get them to recompile ANYTHING.
Win WINE, the most successful development platform in existence becomes an open-source platform, and will quickly deflate the Microsoft monopoly. Microsoft has no choice, simply because the very thing that's kept them in the business (the massive base of WinXX applications) now becomes the very thing that they cannot abandon.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Dear software dev,
I am writing you to inform you that even though you only write Windows apps, I (somewhat) successfully managed to get it to run on my Linux operating system. Please start making a Linux version of this application post haste so you can not gain a customer (I have already hacked your app to run in linux) and increase your development costs. An added perk is the fact that you will be required to support the Linux version rather than just telling me to "run it in Windows" when I call. The extra staff you hire for your support center should help the unemployment rate.
Thanks Again,
A Wine User
Have you considered using a distribution-neutral package format like autopackage? There are solutions written specifically for developers in your situation. Not everyone needs to build packages in native formats; really those are mostly for central repositories. If you're not distributing your app through a central repository, there's no reason not to use something like autopackage.