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.

Re:Skins for wine?

[Royster]

"And no one puts new wine into old wineskins; if he does, the wine will burst the skins, and the wine is lost, and so are the skins; but new wine is for fresh skins." Mark 2:22

New project

[PD]

Anyone want to start a project that allows Windows machines to run Linux binaries? With the way it's going, that's what Windows will need to be a desktop OS.

Re:New project

[Brento]

Anyone want to start a project that allows Windows machines to run Linux binaries? With the way it's going, that's what Windows will need to be a desktop OS.

Great idea! That would give you all the stability of Microsoft Windows, with the ability to run the broad base of Linux applications! Brilliant.

(That would be sarcasm, if you didn't catch it in all its brilliance.)

Not quite there

[fatphil]

I use Wine daily. More accurately I use it constantly. For programs written by friends who don't have Linux. It has it's teeting troubles, it's still cranky in places but it's a life saver (life expectancy of anyone in the same room as me when I am forced into windows is measured in minutes). All progress on Wine is good news.
This has made my day!
FP.

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.

Can WINE talk directly to hardware?

[commander salamander]

Anyone who's used Visual Basic knows that while the language is a pus-filled zit on the nose of all programmers, it is really easy to access hardware directly using controls such as MSCOMM32.OCX, et al...even on WinNT/2k.

I used such a program to control a couple of serial barcode scanners. I'd love to be able to do this on Linux - anyone know if Windows programs are allowed to access the hardware under WINE?