This FAQ covers topics related to software development within the Wine project. For other topics, see our main FAQ here.
- Developer FAQ
- General Questions
- How do I become a Wine developer? What do I need to know?
- I have written some code that I would like to submit to the Wine project. How do I go about doing this?
- Who can't contribute to Wine?
- Can I contribute if I've only seen the source to ATL, MFC, and/or msvcrt?
- How do I download and build the very latest source code for testing purposes?
- Does Wine allow C++, Objective C, or other code?
- I sent a patch, but it got ignored. Why?
- How can I improve the chances of my patches being approved?
- Why is becoming a successful Wine contributor so hard?
- Independent Software Vendor Questions
- See Also
- General Questions
How do I become a Wine developer? What do I need to know?
If you can program C, you are off to a good start. See if there's anything that you think you think you can fix or work on. You won't have much trouble finding areas that need work in Wine. For example, find a program that you want to run that doesn't, or simply grep for FIXMEs in the source. You may also find the Developer documentation and TodoList Wiki pages worthwhile. While it is not essential, having the latest Windows Platform Software Development Kit (PSDK) available for reference will be a help. Wine is always moving along with the latest Windows developments and changes should reflect the latest PSDK.
Once you figure out what to work on, the next step is actually doing the work and getting to know the other developers. First, download the sources via Git (GitWine for help), subscribe to the mailing lists (http://www.winehq.org/site/forums), maybe join #winehackers on irc.freenode.net, and of course, look around the source. It might not hurt to pay attention to the comp.emulators.ms-windows.wine newsgroup, although it is not used very much anymore by Wine developers. Second, you will need to debug a program, if that is what you wish to fix, or otherwise find something to patch. Once you have completed some work, create a patch. See the following question.
Who can't contribute to Wine?
Some people cannot contribute to Wine because of potential copyright violation. This would be anyone who has seen Microsoft Windows source code (stolen, under an NDA, disassembled, or otherwise). There are some exceptions for the source code of add-on components (ATL, MFC, msvcrt); see the next question.
Can I contribute if I've only seen the source to ATL, MFC, and/or msvcrt?
Yes, but not on those components. Also please state on the mailing list that you have seen the source to these and that you will not contribute to them. You are free to contribute to other areas of the Wine source code.
How do I download and build the very latest source code for testing purposes?
Current Wine sources are available via Git. You will need Git 1.4 or above. If you are coming from behind a firewall, use the http:// protocol.
First install the packages needed when building Wine per the instructions at Recommended Packages.
To get an initial copy of the entire Wine source tree, do
git clone git://source.winehq.org/git/wine.git wine-git
Then, in the wine-git directory, do
./configure && make depend && make
Then, every day, you can get a fresh build of Wine by doing
git fetch git rebase origin ./configure && make depend && make
See GitWine for more information.
Does Wine allow C++, Objective C, or other code?
No. For maximum portability, both across platforms and across compilers, we only allow pure ANSI C. That means e.g. C++ style comments aren't allowed in C source files.
I sent a patch, but it got ignored. Why?
- Don't panic! Having your patch ignored is fairly routine, particularly for newer contributors.
Check the patch status for a possible answer. Clicking on the patch status will show the possible causes for that status.
If there are any replies at all to your patch, they have to be addressed, and then you should resubmit your patch.
Beyond that, a patch is ignored either because it is not obviously correct (most likely) or because the maintainer did not have the time to get to it. Developer persistence is seen as a necessary part of the process.
A patch can be 'not obviously correct' for a variety of reasons. Often the reason is clear, and a second look on your part will reveal an obvious mistake. This is why it is valuable for you to double- and triple-check an ignored patch.
Also, patch approval is based on reputation. Once you have had several patches approved, and/or are known to submit good code, your patches are much more likely to be reviewed and approved. Conversely, if you have had several patches rejected, and/or are known to submit poor code, your patches are much more likely to be ignored.
Your reputation is informally known as your 'Julliard Rank'. Everyone starts with a neutral Julliard Rank, and it goes up or down based on the quality of your patches and how responsive you are to feedback. A high Julliard Rank and a not obviously broken patch will often be committed right away. A low Julliard Rank earns you at best dubious scrutiny and at worst repeated dismissal. The following table gives example Julliard Ranks:
Even dubious patches are often committed without complaint.
Normally nothing he sends gets rejected or pending.
Jane Q. Conformance
Long time developer who has contributed many conformance tests, whose patches rarely break the conformance tests, and who sends small, clean patches that are fully and carefully thought out. Patches that look sound often go into Wine without much delay or critical scrutiny.
Joe B. Newbie
A new developer. His patches are given time, considered carefully, and he is welcomed to Wine and we will actively try to help him get his patches in.
Betty Q. Sinking
A relatively new developer. She fails to follow the guidelines on the web site, doesn't respond to replies to her patches, and never contributes conformance tests.
Patches automatically directed to /dev/null
Of course, sometimes patches are 'not obviously correct' because they are non trivial, or don't look quite right to the maintainer. You may have to make a case for your patch (best done via conformance tests), or connect with folks via email or on irc to further explore your patch.
And, finally, patches are often just dropped for no particular reason other than the maintainer ran out of time that day, or missed it, or was off skiing. Double check and resend; no one will be upset.
How can I improve the chances of my patches being approved?
Send a small, very clean patch first.
Make sure your patches are formatted properly and include your real name.
Make sure your patch includes a conformance test, and verify that the test passes both on Linux and on Windows XP or Vista. Patches that add a conformance test are much easier to get approved than patches that change core Wine code.
Make sure the Wine test suite passes after your patch is applied.
If your patch is ignored in a day or two, improve or simplify it and send a new version. Repeat until it is accepted. Persistence is important.
Send a conformance test first rather than including both a conformance test and a bug fix in the same patch.
Why is becoming a successful Wine contributor so hard?
Two reasons come to mind: 1) Wine development has a steep learning curve, and 2) establishing trust takes time.
Independent Software Vendor Questions
Can I use Wine to port my Win32 sources to Unix?
Yes. If you just want your application to run on Intel-compatible PCs, the most practical way is to simply ship your Windows .exe along with an isolated copy of Wine.
If you need to support non-Intel computers, or if you want to intimately mix Windows and Unix code, you may want to rebuild your application in Linux using Winelib. See Winelib User's Guide for info.
Will MFC work with Wine? What do I need to do?
Wine is not implementing an MFC replacement nor does it intend to. However it is possible (with a lot of work) to compile the MFC from source and thus produce an mfc42.dll.so library.
Please refer to the Winelib User's Guide for how to do this.
Are there any commercial applications which have been ported using Wine?
Here are few examples of applications ported using Wine or Winelib:
Corel's WordPerfect Office Suite 2000 was ported to Linux using Wine.
- Kylix, the Linux version of Delphi, was ported to Linux using Winelib. The IDE actually uses a combination of QT and Winelib which would not have been possible to achieve using only Wine. The generated applications however do not depend on Wine in any way.
Vividas Streaming Video (http://www.vividas.com/support/)
Ability Office (http://www.ability.com/linux/abilitylinux.php)
- IBM's Websphere
BricsCad® (BricsCad® V6 for Linux)
- Google Picasa
Can I build one large Monolithic application?
No. However, if you don't want Wine as a dependency, you can bundle your private version of Wine into your package (.rpm/.deb). Wine has good support for such a setup via the WINEPREFIX environment variable. This is the way Google Picasa works - they actually use the exact same binary on Windows and Linux, but in the Linux version they bundle a tested version of Wine.
How can I detect Wine?
This is a bad idea. The goal of Wine is that an application will see no difference running under Wine rather than Windows. So any method to detect running under Wine is unsupported and may break without warning in the future.
Wine should not be treated as a "version" of Windows - functionality or performance-tuning is likely to be different between any two development versions.
Rather than detecting Wine:
- Detect if functionality exists and use it when available.
- File a bug if something works in Windows that does not work in Wine.
If you can write a minimal test that demonstrates the bug, even better!
- Ask for help on the developers' list.
That said: There is nothing wrong with detecting Wine for survey purposes. Many developers are surprised to learn that a substantial portion of their userbase has been running their program via Wine; sometimes developers aren't even aware that this is possible.
If you still really want to detect Wine, check whether ntdll exports the function wine_get_version. (See http://www.winehq.org/pipermail/wine-devel/2008-September/069387.html )