Slashdot Mirror
Ask Jeremy White and Alexandre Julliard About the Future of WINE
Last week, after 15 years of development, tempered by the need for arduous reverse engineering, the WINE project released version 1.0. What "1.0" means for WINE is neither that the project is finished, nor that it is perfect, but rather that the software runs a small subset of specific freely downloadable Windows applications. That's not to say it doesn't run scads of others, too -- the apps database is proof that thousands of programs run to at least some degree. Here's your chance to ask WINE developer Jeremy White and WINE project lead Alexandre Julliard (both of Codeweavers) about the future of WINE, or any other questions about the project that cross your mind. The usual Slashdot interview rules apply; please ask as many questions as you'd like, but limit yourself to one question per post. We'll pass on the best questions to Jeremy and Alexandre for their answers.
1.0 is used to mark the API as being stable: it is now safe to build your Windows' program's source code against the wine headers without having to worry about them changing in the future.
That a few of the important Windows applications work was a side goal: the wine developers merely thought that it would be fitting, given the apparent significance of the 1.0 release name, to perfect support for what they can.
Perhaps you're thinking of wine the wrong way. It is, first and foremost, a windows-compatible API for porting applications to posix.
Wine already implements some Vista API's. The calls that get targeted to be added are usually those that popular applications require. If more applications require Vista features, they will be added. Right now most programs will also work on XP, so the need isn't so pressing.
OpenGL games work very fast. It's typically only games that have Direct3D that are screwed up, and that is another whole morass on top of WINE proper.
My blog. Good stuff (when I remember to update it). Read it.
You know, the official Wine page lists OS X specifically as a supported platform. If you want to get the dependencies (expat, freetype, fontforge, iconv, and so on) together for Wine you can build it yourself on OS X. Also, projects like MacPorts make it easy to build all kinds of free software. Personally, I like to just download a prebuilt binary of Darwine.
What were you saying about being available to OS X users?
And Amazon has it for a cheap $150 (used)! http://www.amazon.com/Meiers-Alpha-Centauri-Planetary-Linux/dp/B00004TBBX/ref=sr_1_14?ie=UTF8&s=videogames&qid=1214510827&sr=1-14 (Tuxgames is sold out as usual.)
It's Free Software: can't be discontinued by Microsoft, costs nothing, and runs anywhere you can get X Windows. Doesn't matter how excellent your emulation is, WINE still has a purpose. It's not an emulator, after all...
There are no trails. There are no trees out here.
Bugs in such apps are valid and they work hard on fixing them where at all possible. In fact, almost all such apps work just fine.
What tends to happen is that a given area of Win32 is covered to the extent that all apps written with a tool that uses that area then work. So e.g. we're desperately waiting for .NET 2.0 to work properly in Wine.
http://rocknerd.co.uk
This is something they're specifically working their arses off to achieve, particularly the Wine contributors at Google.
http://rocknerd.co.uk
Had a native port. It's not really available in any practical sense.
You are not alone. This is not normal. None of this is normal.
Who said anything about Cider? That's a Mac-specific proprietary port of WineLib, the product under discussion. The market for Cider is much smaller than the overall market for WineLib, so saying that Cider isn't that popular really doesn't say anything about WineLib. It could be that the free WineLib is good enough that very few people porting apps off Windows need to bother with Cider. Or that people using WineLib to port stuff want to end up with Linux versions, too.
Yeah, you can use traces to show when it's trying to access a particular DLL.
You should probably stop by the forum with app-specific questions, devs there will suggest how to give enough info for a usable bug report.
http://rocknerd.co.uk
Do you have any idea how difficult that would be? Emulating Windows down to the last undocumented quirk
Wine Is Not an Emulator
Flappinbooger isn't my real name
I just wanted to thank the team, on behalf of everyone in the /. crowd, for making sure Notepad.exe was one of them. It was the first Windows program I tried to use under WINE and it performed flawlessly, making me feel a little more at home on Linux.
I know it's a joke, but it's actually worth explaining. Wine's notepad implementation serves (at least) two purposes:
The same reasons lead to the addition of wordpad two years ago.
WineHQ further lists "Wine will never run on Win64" in their "Wine Myths" section, seeming to imply that there will eventually be Win64 support.
It's hard to say how much of a priority it should be. I want my 64-bit stuff working, and ideally, I'd love for Wine to be as good or better than Windows for certain tasks. (Benchmarks showed Quake3 was faster on Linux, even under Wine.)
But it seems more like Wine is a killer app for random, old, small-user-base apps, often that one last thing that you can't do on Windows. Gamers will outgrow Quake3 and start playing QuakeWars (which has native Linux support), and you can always choose to play a different game (unless you're playing WoW, which runs well under Wine.) But if you need QuickBooks, you need QuickBooks, and Gnucash isn't likely to be a valid replacement.
Don't thank God, thank a doctor!
Wine is just an API computability layer, whilst DOSbox is an actual emulator which emulates the actual CPU.
If you want to see how cross-architecture Wine is it can run on PPC Macs using Qemu: http://wiki.winehq.org/MacOSX/QemuWork
Unicode in Slashdot
A few years ago Lionel and I wrote some debugging tutorials and docs. If you're curious try reading the developer cheatsheet, and tutorials on debugging Reason 3, PE Explorer, and Wild Metal Country.
Reading the documentation, writing unit tests. The docs are sometimes incomplete or wrong but are mostly pretty good. The missing bits are stuff that most API docs miss - what exactly is done under all the error conditions, for instance.