Wine





All about Wine

Local index
About Wine
French Documentation
Quick API stats
Checking spec files
Book Testing:
- Programming Win95
- Programming Win98
- Programming Win95 with MFC
- Programming Applications for Windows
Wine HQ
Wine HQ
Latest News
Downloads
Application Compatibility
Bug tracking
Who's who
Development
Git
Git Web
Wine Announce
Wine Devel
Wine Patches
Wine Commits
comp.emulators.ms-windows.wine
CodeWeavers
CodeWeavers

If you are new to Wine I highly recommend reading the following pages on the Wine Headquarters pages:

Contributing to Wine

So how can you contribute to Wine?

It's easy to be a bit overwhelmed when you're new to Wine. Yes there may be a lot of things to do but where should you start? Is there anything simple that can get you started? Is there anything you can do that does not require an intimate knowledge of the Windows API and of Wine's internals? What if you don't know C? Or if you're not a programmer in the first place?

So here are a few projects that might provide you with a starting point. Note that this list is not an official statement of what should be done on Wine or anything. It's just a list of things I thought could be useful. But I may be mistaken about some items. Maybe some of them are already on their way, maybe someone is already working on them, maybe some are not such a good idea/not feasible. In any case I welcome your feedback. Similarly, if you can think of projects to add to the list let me know too.

I tried to write for each the skills that I expect will be needed to complete them. As you will see many projects can be performed even if you are not a C programmer or if you don't have an intricate knowledge of the Windows internals. Let me know if you are interested in tackling a given project, I'll update this page so that other interested persons can contact you and give you a hand (but if you prefer to remain anonymous that's fine too).

Note that now WineHQ has some good starting points describing how to get started contributing on Wine. I hope to eventually merge the remaining items on this page in WineHQ and retire it. For now, make sure to also check the following pages:

Write about Wine

There are not very many articles covering such subjects as: What is Wine? Where is Wine now? Where is it going? What's the point of Wine?... I tried to cover these subjects a little bit here but you can probably do much better. Your writings would then either be integrated into the Wine web site or become part of the documentation. Also, if you feel like a chroniquer, you could lend a hand to the Wine Weekly news team.

Required skills:
Good writing skills

Present Wine at your LUG

You can get more people to know about wine and understand why it is important by presenting Wine at your LUG. You can use the CrossOver and Wine presentation I made at LUGOD (Linux User Group Of Davis) as a starting point.

Draw icons for Wine

Wine cannot reuse the Windows icons verbatim because of copyright issues. So we have to redraw them, keeping a similar design so that users are not completely lost, all while making them different enough (and possibly nicer). You'll see this if you open a file selection dialog (but should the folder icons really be grey???).

Required skills:
Drawing skills

Cross referencing the Windows executables and libraries

The idea is to write a Perl script that analyzes the Windows dlls and executables of a regular Windows installation and cross references them. This would generate Web pages telling you which API is used by which program/library and reciprocally.
Analyzing the import/export section of PE executables is quite simple: it's just a matter of running dumpbin (part of Visual C++) or pedump (open source) on them and then parsing the resulting text file. I'm already doing this in the wpbtk toolkit.

Required skills:
Perl plus a little bit of HTML

Build a database of Windows APIs and dependencies

This is basically an extension of the previous project. Instead of generating HTML pages for a given configuration, this would tag the results with a Windows version number and save them in some sort of database (either RDBMS style or flat files). We could then merge the results coming from multiple Windows setups and analyze which API is implemented in which configuration (e.g. with or without Internet Explorer 4), ...

Required skills:
Perl and databases

Cross-check the Windows API and the Wine spec files

Once we are able to extract the APIs implemented by Windows (either projects above can serve as a basis for that) we can cross-check them against the Wine spec files. This should allow us to quickly detect missing Wine entries as Windows evolves. We should also be able to detect incompatibilities in the entries order for those entries that have no name.

Required skills:
Perl

Convert Visual C++'s 'project' files to Winelib makefiles

Projects written with Visual C++ often don't have proper makefiles. Instead they rely on ".dsp" files which define which files are part of the project, which options to use, which libraries to link them with, etc. Visual C++ parses these files and displays all the settings in the 'project' dialogs at which point you can modify them and save them to the project file again. Visual C++ normally relies entirely on these files to know how to compile and link executables and libraries.
As long as the user does not specify 'PreBuild' or 'PostBuild' commands it should be possible to convert such a project file into a makefile (and stub file) that is garanteed to work with Winelib (Visual C++ already knows how to do so for Windows). all you would have to add is a list of exported APIs for your libraries.
A similar, and more ambitious, project would be to directly take a Windows Makefile and generate a Winelib makefile out of it. the converter would recognize when 'cl', the Visual C++ compiler, is invoked, and replace the command by the corresponding command and arguments for Winelib. The resulting makefile would probably not be perfect but should be good enough to be used as a starting point.

Required skills:
Perl should be fine for the Visual C++ project files. For general Makefiles you may need to use C and lex/yacc

Check which APIs are missing for a given program

The scripts that scan a Windows environment could be modified to restrict the scan to the dependencies of a given executable/set of executables. Then these results can be cross-referenced with the results of the above script to tell you which APIs this program is missing, what percentage they represent, etc. Reciprocally one can weight each API according to how often they are referenced in a given environment to produce an approximation of the likelyhood that such an API will actually be called. Note that this would just be an approximation because we would miss all the dynamically loaded APIs and libraries (since we only scan the statically linked dynamic libraries). This would be an even more approximate measure of the likelyhood that the program will work: even though a program references an API it may never call it, work even though this API does not work, or really depend on this API or even some undocumented aspect of this API. Still this may provide a better approximation of the completeness of Wine than just treating all APIs as equivalent.

Required skills:
Perl, a bit of HTML to present the results, maybe querying a database will be necessary too

Port your Windows application to Wine

If you are working on a Windows application, porting it to Wine may be the best way to get started for contributing code to Wine. You can start by trying to run it in Wine and then try to compile it with Wine.
The reason I suggest to start with an application you normally work on, is that first you obviously have access to the source code and second, since you programmed it, you know how it works. Furthermore you can attack the problem from both sides: put traces in your application and in Wine. All this combined together and makes it much easier to detect where Wine is doing something wrong, what and why. Then, since you already know what Wine is supposed to do, you're also in a better position to provide a fix.

Required skills:
C/C++ programming skills

Perform a focused code review

A regular 'random' code review can be pretty boring and inefficient. But I think that if you are looking for something specific it can be a productive way of finding and fixing bugs.
Typically you would start by picking a subject. For instance I once found code that was using strncpy without making sure the resulting string would be '\0' terminated. One would normally fix this specific piece of code and move on. But how many similar hard to find bugs would this leave elsewhere? So I decided to check all instances of strncpy. This can take some time so one cannot always do it (drop me a line if you think of some specific bug to look for but you don't have time). But it's a nice way to get acquainted with the code and you can actually find bugs without needing months of experience on Wine's code.
But be warned though that since your changes will be scattered throughout Wine they will be scrutinized by many developpers. Furthermore since your changes probably will not be direct obvious bug fixes, there may be (founded) resistance. Make sure your changes are indeed a fix, not something that will just hide the problem under the carpet (especially with compilation warnings). Also cosmetic fixes, unnecessary changes are generally not welcome (but I admit it's sometimes hard to resist).
Here are a few starting points:

Required skills:
C programming

Write a Swingset like tool for Windows

Swingset is a (relatively) simple Java program that demonstrates the Swing API. Basically, all it does is use all the possible widgets in almost all their possible forms. For instance you will have a windows with ten buttons: one with text aligned on the left, one the right, centered, with an image, etc. Then you have the same for scrollbars, lists, tables, text fields, etc. The idea is not really to use this as a tool for doing complete 'A' to 'Z' regression tests. You would have to test each case by hand which takes a lot of time. Rather it would be a nice tool for testing specific implementation changes and making sure they do not break a the widget (e.g. lists) in a special case. Writing such an application is not particularly complex and only requires knowing Windows. In fact you don't even need to have access to Wine!
The requirements for such an application would be that it can be delivered with Wine (compatible license) and that it compiles on all Windows systems: from Windows 3.1 to Windows 2000. With some use of the windowsx.h macros and a few ifdefs this should be possible. But of course you can start by getting it to work on the platform available to you.

Required skills:
Windows C/C++ programming

Test a programming book's examples in Wine

For this project you'll need access to a Windows programming book (either you bought it or you can borrow it from a library, etc.). Then you try the sample programs with Wine, and maybe try to also compile the source code using Winelib. What's nice is that when such programs turn up bugs, you have all the source code and a complete and detailed documentation about it! What else can you ask for? A kit to get started and create Web pages showing the results? No problem! I started doing just that for 'Programming Windows 95 and the kit I wrote is available right there.

Required skills:
Testing, writing bug reports. Debugging to fix them if possible. Programming in C/C++ if you want to try compiling the programs with Winelib (if the examples are in some other language this would probably not give much useful information).

You may also find some other project ideas on WineHQ's projects page.

fgouget@free.fr This page is hosted for free by Free.fr