Wine and the Google Summer of Code

This page collects some tips for students who want to work on Wine during the Summer of Code, and provides a few ideas for projects.

To apply, go to the Google Summer of Code 2015 home page.


Beware of Legal Requirements

You must state that you will follow these minimal legal requirements during the SoC (and have done so in the past):

  • You are not allowed to read or reuse Windows source code (leaked source / Windows Research Kernel* / ...)

  • (* we are following the SFLC's advice)

  • You are not allowed to reverse engineer Windows files by disassembling or decompiling them

  • You are not allowed to analyze Windows files with the trace functions of Wine

  • People who work or have worked for Microsoft should probably not participate


Ideas

Your own idea

Possible mentors: We'll provide you with the appropriate mentor

  • If you have an idea, please post it on Wine Developers mailing list so we can help you with your idea and find out if it's realistic or not. Showing initiative and willing to discuss your idea greatly improves your chances of getting accepted. Even more so than taking one of the ideas below.

  • As long as you work hard and interact with the community and your mentor in a positive and constructive way you don't have to worry about not meeting all your goals.


D3DX9 - Implement missing D3DX9 APIs

Possible Mentors: Stefan Dösinger, Matteo Bruni

Knowledge prerequisite: C, maybe some domain-specific knowledge related to the APIs you want to implement

Difficulty: Easy to medium, depending on the functions you want to work on

  • D3DX9 dlls contain various utility functions related to common 3D graphics tasks. For instance they contain math functions, functions for loading textures, compiling shaders and much more.

  • A good chunk of those APIs has been implemented but a lot is still missing, such as:
    • some math functions (what's left is mostly about spherical harmonics and precomputed radiance transfer)
    • some mesh functions (D3DXComputeNormals(), D3DXOptimizeVertices(), ...)
    • a few texture functions
    • quite a few ID3DXConstantTable methods
    • various shader-related functions (D3DXGetShaderInputSemantics() and D3DXGetShaderOutputSemantics() to name two)
    • effect framework bits and pieces
    • fonts framework
  • The project would choose a reasonable subset of the missing functions and the work would consist of writing behavioral tests for those functions and actually implementing the functions themselves. We will help you in selecting a reasonably-sized subset of the API, suitable for a GSoC project.


Direct3D - Microbenchmarks

Possible Mentors: Stefan Dösinger

Knowledge prerequisite: C, Direct3D, OpenGL

Difficulty: Medium

Debugging performance problems in full games is a challenge. Small test programs that test the performance of single operations can help to locate performance problems and fix them. Once fixed, those test programs can be used as regression tests to detect regressions that are hidden inside the margin of error in games. With an equivalent test case in OpenGL it is possible to separate problems in wined3d from problems in the driver.

Stefan Dösinger has already written test programs for draws, buffer uploads, clears and a few other operations and is testing them on a daily basis. More tests need to be written. The test programs will probably be maintained outside the Wine source tree.

A good application should contain a list of d3d operations to test, a rationale why those operations are good candidates and a short description how each of the tests will be implemented.


Direct3DRM - Implement rendering for D3DRM

Possible Mentors: Stefan Dösinger, André Hentschel, Christian Costa

Knowledge prerequisite: C, DirectDraw, Direct3D

Difficulty: Hard

  • Direct3D Retained Mode is mostly a stub, it needs to interact with ddraw to actually display something.

  • Even if it's an old library and has been removed in Vista, there are small Games based on it.
  • There may be value in making this work on Windows / native ddraw as well.
  • Some bugs with games that use d3drm: 12851, 19733, 21670. There are more of them.
  • Some functionality in d3drm is already implemented, mostly math helper functions.

Applicants should try to find some more applications that require d3drm and, as far as possible, try to find out which functions and interfaces they use. The proposal should include steps for writing tests and a description how the d3drm implementation will interact with the rest of the d3d libraries.


CMD - implement more robust parser

Possible Mentors: Jason Edmeades

Knowledge prerequisite: C, CMD commands

Difficulty: Medium

  • http://kegel.com/wine/sweng/2010/ is a project to fix a number of small bugs in Wine's cmd.exe and friends, and to write testcases for it. It has helped bring to light certain flaws in cmd.exe's parsing of if/then/else and () blocks.

  • Somebody could quite usefully spend a summer bulking up the test cases for cmd and friends, fixing any remaining reported bugs, and improving the parser.


Xinput / Xbox 360 controller compatibility

Possible Mentors: Andrew Eikum

Knowledge prerequisite: C

Difficulty: Medium

Michael Gruber submitted patches from 2009 that appear to actually implement xinput:

There were two follow up threads in relation to this:


Implement OpenMP (vcomp.dll)

Possible Mentors: André Hentschel, Sebastian Lackner

Knowledge prerequisite: C, at least x86 assembler

Difficulty: Medium to hard

  • OpenMP is a shared memory multiprocessing API and vcomp.dll contains the Windows implementation for it.
  • See http://bugs.winehq.org/show_bug.cgi?id=26688

  • Only two games are known to be affected at the moment.
  • Non-parallel fallback implementations might be useful?


Portability - Port WineLib to a new architecture

Possible mentors: André Hentschel

Knowledge prerequisite: Assembler for the target

Difficulty: Medium, depending on the target

  • Wine can run WineLib applications on different CPU architectures, but needs at least some assembler code for that.

  • Suggested architectures: MIPS, Sparc64, x32.

  • You will also need a test system. Qemu is possible, but real hardware is recommended.


Implementing XACT sound dlls

Possible mentors: Andrew Eikum

Knowledge prerequisite: C

Difficulty: Medium

The goal here is to implement a subset of the Microsoft Cross-Platform Audio Creation Tool dlls, also known as xact. There are a few sections (xactengine, xaudio, x3daudio, xapof) involved, so only a portion would be done for the project. You should have (or read up on) experience with Linux sound systems (ALSA/OSS) or other audio experience.

See also bug 26833


WineCE: Implement the CommandBar

Possible mentors: André Hentschel

Knowledge prerequisite: C

Other prerequisite: ARM device with Linux or some Qemu experience

Difficulty: Medium

  • WineCE targets to support Windows CE applications, an huge update to revive it will be pushed soon.
  • This is an out-of-tree project, but obviously still related to Wine.
  • The goal is to implement the CommandBar.

  • If there's time you could also implement CommandBands.


Winecfg / winemenubuilder - enhance MIME type handling

Possible Mentors: Michael Müller, Sebastian Lackner

Knowledge prerequisite: C

Difficulty: Medium

Wine tries to integrate Windows programs as much as possible into your unix/linux system and provides ways to directly assign MIME types to programs running in Wine. This makes it possible to open Word when you click on a .docx file in your file browser. However, this kind of integration is not always desirable, especially if there are native programs which support the same MIME type. At the moment a user can only decide to disable this kind of integration completely or Wine will automatically forward all MIME type registrations of Windows programs, resulting in questionable ones like .txt -> notepad and .png -> Wine Internet Explorer. If a user wants to remove such MIME type registration again, it is necessary to manually delete the according files.

The idea of this task is to provide a GUI (most probably as part of winecfg) to control the creation of such MIME type assignments and therefore making Wine more user friendly. You can find ideas how such a GUI could look like in the Forum or in the Bug Tracker. This task is also suitable for new Wine developers as no deep knowledge about the Wine source code is required. It might help though to have some knowledge about Win32 Dialogs.


XMLLite: Implement fully compatible xmllite parser

Possible mentors: Nikolay Sivov

Knowledge prerequisite: C

Difficulty: Medium

  • There shoudn't be any external dependencies for parsing functionality
  • The main focus should be on the Reader
  • Full parser resuming functionality for pending reads
  • Unit tests
  • Support for external entities to allow nested parser inputs


SummerOfCode (last edited 2015-03-02 23:49:03 by AustinEnglish)