Wine In New Skins

Thanks to Jeremy White of Codeweavers for sending over some of the previews of Wine 1.0. I had a chance to see this during ALS, and was very impressed by what they are doing. 1.0 has Gnome/KDE integration, as well as new (better) config program, and some new launcher features. As well as doing this, they've also WineHQ, for all the Wine news that you can drink.

Comments

Re:Negatorio, mein troll.

[ninjaz]

1)Windows apps on Linux means that Linux apps are not developed. People don't use Linux, because the native performance of these apps in Windows if of course superior. Wine leads to a catch 22 situation.

Regarding preventing the development of Linux apps, there is evidence to the contrary. For instance, Word Perfect has been ported to Linux, yet the Free office projects are stronger than ever. Also, Wine is supporting more Windows games than ever. Meanwhile, Loki keeps cranking out native ports.

Regarding performance, there is no reason why Windows would perform inherently better. Wine Is Not an Emulator. It is a native unix implementation of the Windows API's, which basically amounts to a set of libraries and a glorified linker.

2) WINE means that software developers don't need to worry about porting their apps to Linux at all.

Winelib means that initial porting can be as simple as a recompile.

3) WINE reenforces the Windows blinders, if anything. The users are never escaping from the Windows environment at all. How is this good for Linux?

Users are ecaping from their Windows environment. If I use 99 applications on my Linux box which are native to Linux, and 1 that is native to windows, I'd say I've successfully escaped the Windows environment. Legacy support does not mean you're trapped in the legacy environment. On the contrary, it's a powerful tool to free you of that environment while not losing access to a specific application.

Historically, lack of applications, or lack of one specific application on Linux has been a major obstacle preventing people from becoming full-time Linux users. Once Wine can reliably run most Windows applications, the barrier against change becomes much smaller. And, as the user becomes more familiar with Linux, apps mature and are ported, the legacy Windows applications used under Wine can be phased out.

Is Wine good in the long run ?

[Forge]

The long term effect of Wine on Linux is still open to debate. One logic to follow is that developers like to write as little code as possible to reach the desired audience.

This is why many Unix developers code to POSIX and ignore the special tweaks available on even the most popular of commercial Unix systems. "Write once, Run anywhere" wasn't invented by Sun's Java Marketing team.

That brings us to OS/2 with it's robust ( at the time ) Win16 support. Developers were faced with a choice. Write apps for OS/2 and enjoy patronage of the OS/2 userbase or write for the Win16 API and enjoy the Windows 3.11 userbase AND the OS/2 userbase.

That wasn't a tough call and OS/2 was driven from the desktop in part because of it.

"Wine Is Not An Emulator" can be screamed and shouted every day, all day. The fact is people use it as such. As is Linux users run Quick books on Linux+Wine without Intuit having expended a single coin to port it over. For all practical purposes we have Quick books on Linux now. There is no longer much of a financial incentive for a Linux port.

Fast forward a bit to the next version of Quick Books. It has made use of some special new feature in the Windows 64 API of Whistler and it will take years of hacking for Wine to support it again. Suddenly the Linux, QB users are left out in the cold.

This is why the Wine Runtime is may be a bad thing. The porting API is however a different animal. It works well enough to get an app over but for long term development; you really need to rewrite in KDElibs or something like that to work properly on a Linux desktop. Maintaining a Wine port must be a nightmare by comparison.

At least it shows signs of going to 1.0 Something that all software should do at least once in it's life. That still leaves the Hurd as the code base determined to NEVER be "finished". Of course they have a different problem. Linux delivers to the user what Hurd intended but with a different technology. V6, V8 ? Who cares, I want Miles Per Galon and cruising speed.