WineHQ
Please do these projects because they are fun.

Fun Projects

Color Key

To Do

In Progress

Works

Done

Abandoned

This page is a collection of Wine related projects that come with a big Cool! factor. I will be tracking their status on this page, as they are also quite important from a practical point of view. If you feel like working on any of these, please let me know.

Desktop Integration

Some of these range from fairly easy to somewhat difficult. The payoff on these is high - how users interact with the desktop are some of the most visible parts of Wine. Mike Hearn, who suggested most of these ideas, explained, these "provide a good intro to Wine development for anybody who has been lurking on the sidelines and wants to get involved. As usual no guarantees these patches would be accepted, that's Alexandre's call. But they probably would be, and you'll learn something while doing them!"

Create My Documents

Map CSIDL_PERSONAL (My Documents) to the $HOME directory if mapped. See the _SHGetDefaultValue function in dlls/shell32/shellpath.c for an explanation of how to do this. It would probably be ok to grab $HOME using the UNIX getenv() and then using the libwine APIs to map them to a Win32 path. If the mapping fails (i.e. $HOME is not accessible given the users dosdevices) then just fail with a WARN().

  • workers: Juan Lang
  • status: committed to the tree.
  • updated: Oct 3, 2005

Map Desktop Directory

This is similar to above but with some extra work. Map the contents of the ~/Desktop directory to the Windows virtual Desktop folder. In file pickers and Explorer, the filesystem root is represented by a magic Desktop folder. In real Windows this reflects the icons that are on the desktop and is mapped to a real directory at some arbitrary point in the filing system. On Linux we have no such virtual root, however it'd be nice if icons that appeared in the KDE/GNOME desktop were put in their proper place. That way users won't be confused by the file being on their desktop but unavailable from their Windows applications file picker.

This should not be too hard. The Desktop folder is implemented by a COM object in dlls/shell32/shfldr_desktop.c. You just need to read the $HOME/Desktop folder and put the items you find in there inside. Ignore .desktop files for now, they are a bit tricker to map and aren't especially useful for us anyway.

You also want to map CSIDL_DESKTOP in dlls/shell32/shellpath.c, _SHGetDefaultValue. See above.

Bonus points for fixing the desktop icon while you're at it (an arrow??!)

  • workers: Juan Lang
  • status: committed to the tree.
  • updated: Oct 3, 2005

Use Icon Themes

The freedesktop.org icon theme specification shows us how to find icons for many different types of things. Implement support for loading and using the following icons from the icon theme (it should be OK to use native libraries for this like GdkPixbuf, just fall back to the compiled in defaults if it's missing):

  • folder
  • desktop
  • computer
  • unknown document
  • any others??

Don't do file types, as native icon<->file type association is done by mime types not extensions, and it'd make our file dialogs even slower than they already are.

You may be tempted to use e.g., libpng to implement this. Don't! Use GdkPixbuf instead, stock icons are allowed to be in many formats including SVG.

Actually it's probably easier to use the new GTK+ APIs to implement this, that takes care of not only rendering the image to a raw bitmap you can then convert to an HICON, but it also implements the icon lookup algorithm for you. In future it'll probably also implement some fancy caching mechanism to reduce memory overhead. Might as well get these benefits easily!

  • workers: wanted
  • status: to do
  • updated: Dec 21, 2004

XDG Menu Support

Try updating the menu mapping code to support the new XDG menu specification. Don't bother trying to make this work everywhere, it's a total nightmare. Just try supporting the new standards. Be warned: not every desktop/distro supports this yet!

This one might be quite hard.

  • workers: wanted
  • status: to do
  • updated: Dec 21, 2004

Improve winebrowser Script

Try improving the winebrowser script to take into account the user's preferred applications. At the moment it just tries every browser it knows about in a hard coded order. Hint: in modern GNOME desktops you can use the "gnome-open" program to make this automatic. There is a KDE equivalent (kfmclient openUrl).

  • workers: wanted
  • status: to do
  • updated: Dec 21, 2004

Integrate Windows Screensavers

Integrate Wine with XScreensaver, so installing Win32 screensavers makes them automatically appear in the list. You may need to write patches for xscreensaver to make this really slick.

Bonus points for getting xscreensaver to respect the registry setting LowPowerActive.

  • workers: wanted
  • status: to do
  • updated: Dec 21, 2004

Take Out the Trash

Steven Edwards suggested, "add support to use the draft FreeDesktop trashcan spec."

  • workers: wanted
  • status: to do
  • updated: Dec 21, 2004

Integrate the Registry With Native Configurations

Implement a bridge between the Windows registry and the GNOME/KDE configuration systems. If you set the wallpaper in a Windows app it should reflect on your real desktop. This is useful for programs like the WebShots desktop. This could be done by extending the wineexplorer

  • workers: wanted
  • status: to do
  • updated: Dec 21, 2004

Configure Some Default Registry Entries

Stefan Dösinger suggested, "probably a bigger task: Look for common native applications and write entries for them into the registry. For example, I manually added an entry for KMail in \\Machine\\software\\clients and now I can select Kmail as the default Mail application in the internet options control panel (Which is created when Internet Explorer is installed). My registry entries look like this:

    [Software\\Clients\\Mail\\Kmail] 1100110998
    @="KMail"

    [Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo] 1100110998
    @="URL:MailTo Protocol"
    "EditFlags"=hex:02,00,00,00
    "URL Protocol"=""

    [Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo\\DefaultIcon] 1100110998
    @="C:\\Program Files\\Opera\\opera.exe,1"

    [Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo\\shell\\open\\command] 1100110998
    @="\"Z:\\usr\\kde\\3.3\\bin\\kmail\" \"%1\""

    With Z: mapped to /

I selected KMail as the default Mail application, and when I open an Mail Address in MSIE kmail pops up. The same happens when I enter a mailto: address in Task Manager->New task.

  • workers: wanted
  • status: to do
  • updated: Dec 21, 2004

Virtualization Projects

Virtualization environments tend to stress the host considerably, due to the inherent impedance mismatch between the two. As such, they provide very good (and tough) test cases. Having such virtualization environments run within each other is an important milestone in the lives of said projects, and not without good reason: it is a remarkable technical feat that requires a great deal of maturity.

Platforms

Wine provides Windows in Linux; Cygwin provides Linux in Windows. Why not run one inside the other?

NB: having them both work would allow us to nest them arbitrarily, which would be ubercool.

Cygwin under Wine in Linux

This provides an a good test case for Wine. It is tough, but we do have the Cygwin source code, and we have a good chance to understand why it does not work. This task is tracked as Bug #443
  • worker: Sylvain Petreolle
  • status: it seems that all internal commands work
  • updated: Oct 5, 2003

Wine under Cygwin in Windows

This will provide a good test case for Cygwin, but will help Wine's portability. Moreover, the ability to run Wine code under Windows without a reboot, can help with testing sometimes. This task is tracked as Bug #273
  • worker: David Fraser
  • status: almost compiles
  • updated: Nov 18, 2002

Runtimes

Over the past 10 years, a number of portable runtimes have been created. Why not use them in a way they weren't meant to be used? That is, compile and run their Windows port on Linux under Wine. For this to happen, they need to have a MinGW port on Windows (that is, they need to support building under MinGW).

Java Virtual Machine

There are three noteworthy Java implementations:
Sun's JVM
Unfortunately, the Windows port requires MSVC to build. How ironic.
IBM's JVM
I can't seem to be able to find the sources for this one. Help!
Kaffe
This one seems to have ports to Cygwin and MinGW. Good candidate for a port.

Perl

Any Perl monger up for this? Update: The ActivePerl branch support building under both Cygwin and MinGW. This is a very good test for winegcc. Unfortunately, the MinGW makefile uses backslashes as fileseparator, so it will take a bit of work to get working under Linux. Why do people use backslash, when the forward slash works on both Windows and Linux?

Python

Not very exciting, but still interesting port. It's a good test for the non graphic APIs, such as threading, files, etc. Update: Configure the packages like so: 
  CC=winegcc CXX=wineg++ configure --with-suffix --without-threads
Unfortunately, configure gets confused about the executable extension, and needs to be hacked manually to suppress it. It still determines that an .exe extension is needed, so the definition of the EXE variable in the resulting Makefile must be manually adjusted. Things compile fine, but linking unfortunately fails. winegcc needs more work to support the -Xlinker, and -shared options.
Update: Here is an article containing a log of successful compilation of Python 2.2 using MinGW.

Toolkits

While some have focused on portable runtimes (see above), others tried to create portable UI toolkits. Due to the large UI component of the Win32 API, these are a perfect test for Wine.

QT

Imagine we compile QT under Wine, and then we get the entire KDE compiled and running under Wine! How cool would that be? Update: It seems that both Qt3 and Qt4 can be compiled with MinGW. This should make a Winelib port feasible.

Gtk+

This is maybe a little less interesting than the others, as Gtk+ does not use the native widgets when ported to Windows. Instead, it uses it's very thin abstraction layer (gdk) to do the drawing, all else is build 'in house'.

wxWindows

A perfect test case for Wine's headers, and MinGW emulation! Wouldn't it be cool to have the Windows controls available on Linux too? <duck/> :-) The first try at porting wxWindows to Wine was attempted by Robert Roebling. His work was later on improved by Julian Smart. Unfortunately, it never seemed to have reached a fully functional stage, and seems to have started bitrotting as a result. Due to numerous bugs in Wine at the time, they were forced to add multiple ugly hacks to the wxWindows code.

My current porting effort is a brand new approach, that builds on the MinGW port of wxWindows. In theory, wxWindows should work with just a few lines changed in the makefile. Practice is however a bit different, and a bit more work is required. That being said, I will try to minimize to the absolute minimum the changes required to wxWindows (unless such changes would correct problems). Rather than working around Wine bugs, I am fixing them as I go along, and submit them for integration in the Wine tree.

FOX Toolkit

Yet another nice cross-platform UI toolkit. This one compiled with just a couple of trivial fixes to Wine's headers, a few portability fixes to their source, and just one or two Wine specific tweaks.

Source portability

We should be able to compile Wine with various C compilers.

Microsoft's Visual C

The most popular compiler in the Windows Universe. Also known as Visual C++, Visual Studio, or MSVC. You can download a free version of the command line compilers from msdn.microsoft.com/visualc/vctoolkit2003. The Wine test programs do seem to build with Visual C (see posts by Jakob Eriksson and Dan Kegel). Wine itself, does not build under MSVC currently.
  • worker: Patrik Stridvall
  • status: most tests work, DLLs are pretty bad though
  • updated: Nov 29, 2002

Borland's bcc

Borland has released it's C++ Compiler 5.5 as freeware. The compiler is the core of C++Builder, and is capable of creating fully functional C++ applications from the command line.

Watcom's cc

Sybase acquired the compiler from Watcom, and released it as Open Source software. Currently it is being ported to FreeBSD and Linux, and a Windows version is readily available.

Sun's cc

  • worker: Patrik Stridvall
  • status: older version that didn't support stdcall. I abandoned that project years ago...
  • updated: Dec 1, 2002

Others

Make a ghostscript driver that uses Wine to print

When we are going to support native Windows printer drivers, this is going to allow ghostscript to use any of the existing gazillion printer drivers out there. This is still a virtualization project, but at the printing subsystem level. The complementary project (use ghostscript to print from Wine) has been implemented, and working just fine.

wined3d use wgl

Make wined3d (or d3d8) use wgl (windows opengl) instead of glx. (just search for glx commands and replace then with the wgl equivalents) Doing so would enable wine's d3d to run on windows in place of the windows driver and without the rest of WINE which would greatly help in debugging. It would also allow wined3d to use the wgl implementation in wine.

  • workers: Aric Cyr
  • status: debug phase
  • updated: Jan 12, 2006

Miscellaneous Projects

This is a catch-all category for all sort of strange (and sometimes cute) ideas.

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. This already being done with the wpbtk toolkit.

Update: Currently the script can make HTML maps of the dll imports. I've been too lazy to integrate the program that processed that into a table so far. :) Right now it requires dumpbin (Visual C++) I plan to add pedump or winedump support so more people are able to use it. It is also analyzing the Wine .spec files to determine if each API has an entry and reports whether it's a stub, unimplemented (not in spec files), etc.

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 likely hood 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 likely hood 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.

Mono GDI+ Wrapper

Microsoft GDIplus currently works on Wine already, however it might be faster if we can take advantage of the Mono project's libgdiplus implementation as it can use the Cairo vector graphics library or OpenGL as a backend. There are 4 efforts underway at this time to make a free gdiplus.dll replacement for Windows and one example is The Gimp for Win32. However they are still going to suffer from the same problem of being implemented on top of the GDI. And if we can use the Mono libgdiplus we just might end up with apps that render faster than on Windows.

  • workers: Steven Edwards
  • status: initial work has just started
  • updated: June 26, 2005

GDI DIB Engine

Integrate the GDI engine contributed by the TransGaming folks.

  • workers: wanted
  • status: to do
  • updated: June 24, 2005

Wineconsole Copy & Paste toolbar support

The standard Windows console has Copy & Paste toolbar icons. Adding them to wineconsole would be a very nice project for someone who knows a bit about windows programming. This task is tracked also in Bugzilla, as Bug #1304.

Wine Explorer

A Windows Explorer replacement. People migrating from Windows would love it, and it would provide a great testbed for our shell32 DLL, as well as some key controls such as the List-View Common Control.

Winetest Shell

Would be nice to have a shell exe (sort of like the one provided by JUnit), that contains the little exes, extracts them in a temp dir one by one, runs them, and displays a nice progress bar, together with a list with messages.

Compressed or Modified Executables

Many applications are compressed with EXE packers or use other tricks to thwart those who would try to look inside them. These applications typically crash or refuse to run if they think a debugger is being used. The tests used generally involve taking advantage of some undocumented quirks in the API. It turns out that many of these tests fail with Wine. This is often because Wine does not implement a feature the exact way the application expects. There is some sample code available here and additional information here. Getting this kind of code to run and give the correct results could help with other stubborn applications that depend on the same feaures.

  • workers: wanted
  • status: to do
  • updated: Oct 22, 2003

JScript engine

Implement jscript.dll. Use Mozilla's SpiderMonkey to implement the Windows scripting interfaces for the JScript COM object in jscript.dll. Figure out a way to deal with the differences between JScript and JavaScript.

  • workers: wanted
  • status: to do
  • updated: Mar 15, 2004

Colour Management

Implement mscms.dll, for Image Colour Management, using Little CMS. mscms.dll is necessary to run some photography and desktop publishing software, such as Phase One's Capture One. The functionality of mscms.dll seems to be defined by the International Color consortium.

  • worker: Hans Leidekker
  • status: about 25% complete
  • updated: Mar 15, 2005