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."

Comments

Re:What will interest me is

[The MAZZTer]

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.

Re:What will interest me is

[QBasicer]

uTorrent does, and lists Wine first.

Re:I would really like to try this out

[jonasj]

I tried installing the source tarball in CYGWIN, but no avail. I know you're joking, but might wine-under-cygwin actually be a solution to Vista's incompability with some software written for older versions of windows?

Re:What will interest me is

[TheNetAvenger]

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

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 .NET 3.5 SP1 for some interesting demos of how far WPF has already gone in just a year.)

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.)

Not really

[an.echte.trilingue]

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.

Re:I would really like to try this out

[Anpheus]

A lot of old compatibility fixes are actually problems with the game itself, especially because you mention pre-2000 as the release date. I'm reminded of the Sim City example. Source: http://ianmurdock.com/2007/01/14/on-the-importance-of-backward-compatibility/

Raymond Chen is a developer on the Windows team at Microsoft. He's been there since 1992, and his weblog The Old New Thing is chock-full of detailed technical stories about why certain things are the way they are in Windows, even silly things, which turn out to have very good reasons.

The most impressive things to read on Raymond's weblog are the stories of the incredible efforts the Windows team has made over the years to support backwards compatibility: "Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, 'Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z.' Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messages? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)"

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

This was not an unusual case. The Windows testing team is huge and one of their most important responsibilities is guaranteeing that everyone can safely upgrade their operating system, no matter what applications they have installed, and those applications will continue to run, even if those applications do bad things or use undocumented functions or rely on buggy behavior that happens to be buggy in Windows n but is no longer buggy in Windows n+1...

A lot of developers and engineers don't agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It's why so few applications from the early days of the Macintosh still work...

To contrast, I've got DOS applications that I wrote in 1983 for the very original IBM PC that still run flawlessly, thanks to the Raymond Chen Camp at Microsoft.

Re:FINALLY!

[mcrbids]

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.