rpbancroft
2011-Jun-01 18:19 UTC
[Wine] Understanding Wine's build processes/development cycle
Hey everyone! I'm a fairly new user of Ubuntu, and I stumbled across Wine a few months back. I would love to use Ubuntu more regularly, but there are a few programs that I use in Windows that I simply couldn't live without if I were to make the switch. However, I'm fairly confident these programs would not work within a Wine environment just yet. That story in mind, I just had some questions about Wine: Is there a maintained list of what Windows programs work reliably in Wine, which ones sort of work, and which are being developed into Wine? How does the development process work? Does Wine provide a framework in which all Windows programs can operate (basically emulating the Windows platform), or does each individual program need to be built into the Wine framework so that it'll work? Or some combination? I ask these question mainly so that I can know whether it makes sense to somehow request specific programs be added to the Wine support roster, or if it works in some other way (which would change the way I'd frame the requests, and help me understand and sympathize with the build process). Following that, where can I make requests for new functionality in Wine? I read in the usage-statistics wiki that Wine developers wanted feedback from users so that they could better prioritize their development. How and where do I provide such feedback? Thanks so much for any replies to these questions! I'm very excited to see this platform continue to develop. ~Ryan
DanKegel
2011-Jun-01 21:05 UTC
[Wine] Re: Understanding Wine's build processes/development cycle
Wine is a generic implementation of win32 (and win16 and win64), it's not app-specific. Working apps are tracked at http://appdb.winehq.org (see the AppDB tab in the forum interface). Adding support for an app means fixing the bugs it exposes in Wine. Bug reports are tracked at http://bugs.winehq.org (see the Bugzilla tab in the forum interface). The best way to help the wine developers is to file clean bug reports; if it's a regression, figuring out which commit broke the app, and including that info in the bug report, improves the chances it'll get fixed. (See http://wiki.winehq.org/RegressionTesting ) Some bugs are easy to fix, e.g. http://bugs.winehq.org/show_bug.cgi?id=27339 was fixed in two days (because it was small, and had an excellent bug report); others are devilishly hard and take months or years.