When Windows games don't work properly, it's common to run dxdiag, a handy little app that comes with Microsoft DirectX; gamers use it to get information about their 3d graphics card and to test to make sure it's working ok.
The project here is to both get Microsoft's dxdiag working a little better on Wine, and to get Wine's dxdiag to be more feature complete.
To try the native (Microsoft) version of dxdiag, do
$ wget http://winetricks.org/winetricks-alpha $ sh winetricks-alpha dxdiag $ wine dxdiag
In 2009, cs130 also tried improving Wine's dxdiag. Their code is online at code.google.com/p/yadxdiag, but was never committed to Wine because they tried to send it too late in the term. Let's not make that mistake this time. On the very first week, let's try to submit the smallest possible patch to improve Wine's dxdiag, and keep trying until it gets in.
The wine maintainer's policy is that only the person who writes the code should submit it to wine-patches, so we can't reuse the old code in yadxdiag that Allen Hair wrote.below) on your laptop; you might find the UCLA LUG's Installfest on Saturday January 15th useful.
Then let's have a meeting where everyone brings their computer, we get a Wine development environment set up on it, and verify that you can build the existing dxdiag. (Perhaps this can be done during the UCLA LUG installfest.)
Then let's have one or two meetings where we bring our computers and get started with the development work in person.
The mailing list ucla-cs130-wine is set up for students currently enrolled in the class. Please use this to ask questions about the project or run ideas past the coordinator or other students.
You can commit to the existing code.google.com/p/yadxdiag repo while getting things together, but the real source code repository is the git repository at winehq.org. To commit, you have to submit patches as described at Sending Patches.
My favorite way to access IRC is with the Chatzilla plugin to Firefox (Tools / Addons / Get Addons, search for IRC). Then you can just click on the above link, and/or add it to your bookmarks.
wget http://winezeug.googlecode.com/svn/trunk/install-wine-deps.sh sudo sh install-wine-deps.sh(see RecommendedPackages).
git clone git://source.winehq.org/git/wine.git wine-gitThis creates a Wine source tree in a new directory named wine-git.
cd ~/wine-git ./wine programs/cmd/cmd.exe.so
cd ~/wine-git make -k test > log 2>&1(The -k makes it continue past failing tests; the "2>&1 log" redirects both stdout and stderr to a file named "log".) This should take about five minutes. If a test hangs, you may need to kill the process or wineserver from another window.)
To see a list of failures, just look for lines with "Test failed" in them, e.g.
grep "Test failed" log | moreYou can get a count of failures with wc:
grep "Test failed" log | wcYou shouldn't see more than ten or so errors in 32 bit Wine (assuming your have an nvidia graphics card). http://wiki.winehq.org/SubmittingPatches.
Once you have made a change to Wine or its test suite that you're happy with, create a patch (see here and here for how), and make sure the patch applies cleanly to a fresh checkout of the Wine sources, and still builds and runs properly. If you used git to retrieve the sources, you should be able to use 'git diff > my.patch' to create a patch.
Once your patch works, add a changelog entry at the top, giving your name and the license (LGPL), and saying very briefly what it does. Then have a friend review the patch for errors, and clean up anything they found confusing or wrong.
If you're a student working in a structured project, send it to your project leader for review, and clean up any issues they find.
If the patch isn't accepted right away, don't worry, just address any feedback you're given, and resubmit it once a week or so. Ask on wine-devel if you're unsure what's happening. Continue resubmitting until it makes it in. (Sometimes the Wine maintainer's mailbox overflows, so don't expect approval to be quick or easy.)