Home/Misc | Wine | Bing | Distributed Computing | Fun | Links |
If you are new to Wine I highly recommend reading the following pages on the Wine Headquarters pages:
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.
Home/Misc | Wine | Bing | Distributed Computing | Fun | Links |
fgouget@free.fr | This page is hosted for free by Free.fr |