WineHQ

Summer Of Code

Revision as of 16:39, 4 February 2021 by Zf (talk | contribs) (→‎Ideas: + directshow)

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 home page.


Important notes!

  • Applicants MUST have submitted a patch or testcase to wine-devel (see Submitting Patches) to be considered for acceptance.
  • Please first send a draft proposal and discuss it with us, don't send the final one directly.
  • We cannot accept ReactOS proposals, so please only make proposals that will benefit Wine.

To apply, go to the Google Summer of Code 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

Other Outreach Programs

In addition to Google Summer of Code Wine also participates in:

  • Outreachy is a program similar to GSoC organized by the Software Freedom Conservancy. The goal of Outreachy is to provide encouragement, experience, and networking opportunities for minorities that are underrepresented in tech. Unlike GSoC, it is not limited to students; you can read the Wine Wiki's Outreachy page for more information.
  • Google Code-In is aimed at pre-university students and doesn't require any previous coding experience. As a result, the tasks for Code-In participants are more focused, smaller, and have a gentler learning curve. Some aren't even programming tasks but related to other aspects of an open-source project, such as market research, user-support, or documentation. For more details, see the Wine Wiki's Code-In page.

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.

Fix Tests on Your Windows Machine

Possible mentors: Depends on the libraries you pick

Wine has an extensive testsuite that is used to document how the Windows API works and check Wine's conformance to the native Windows behaviour. The Wine testbot automatically runs tests when patches are submitted to check if a patch breaks anything.

Unfortunately no Windows machine passes all the tests: http://test.winehq.org/data/ . A few tests are failing reliably and others fail randomly. This can have a number of reasons. Either the test is too strict, Windows' behaviour changed from version to version, the test does not take the influence on some settings into account (e.g. system language), etc.

A possible GSoC project is to pick a set of libraries of a certain domain you are familiar with (e.g. 3D graphics, XML parsing, networking, etc), where tests are failing on one or more of your machines and try to fix them. However, we don't simply want to remove failing tests, but try to understand why they are not behaving as expected. So be prepared for long debug sessions to find out the differences between your Windows installation and one that passes the tests.

Some of the details we expect you to provide in your proposal are DLLs you plan to look at and the current test failures you see in them. Hack away any crashes that prevent any later tests from running to get the full picture. Test how the same tests behave on Linux inside Wine.

Upstream changes from winevdm

Possible mentors: Stefan Dösinger

Wine supports running old Windows 3.x (Win16) programs on 64 bit Linux hosts. The winevdm project (https://github.com/otya128/winevdm) ported this ability to Windows. They are using Wine's 16 bit thunks and combine it with a CPU emulator to get around kernel limitations that prevent 16 bit applications from working natively on 64 bit Windows.

The winevdm project has made quite a few changes to the thunks over time and extended them. This project proposal is about upstreaming those changes to Wine. Find some applications that work in winevdm but not Wine, isolate the changes necessary to make them work (the winevdm git log is your friend) and submit them in small patches to wine-devel.

Your GSoC application should identify one or more Win16 applications together with a likely set of changes that will get the application running. It doesn't have to be a complete set of patches - that will be the main part of your project - but we want to see that you are able to find your way around the source tree.

Improvie HiDPI support

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

Wine currently supports HiDPI. But there're many places in Wine UI that don't take HiDPI into consideration. An example application is Control Spy v6 2.0 with DPI set to 192. DateTime Picker doesn't have enough space, same for Edit, Hot Key, Month Calendar, Status Bar, SysLink, Tab Control, Trackbar, and Up/Down. Note that it may be an application bug. But there are other places in Wine apps as well, e.g., print preview button and toolbar size in WordPad. First, get a scope of Wine common controls/user controls/applications that need to be fixed. Then for further improvements, you may work on setting the recommended DPI scale at Wine startup or dynamic DPI change at runtime.

DirectShow DVD support

Possible mentors: Zebediah Figura

  • DirectShow is a general multimedia streaming framework, built around creating graphs of individual "filters" which consume and produce data. Windows ships a number of built-in filters.
  • Several interfaces related to DVD support (DVD Navigator filter, DVD filter graph) are stubs or unimplemented. The work would consist of providing an implementation of these interfaces.
  • End goal would be to allow a native application to play DVDs.

AVFoundation decoding support

Possible mentors: Zebediah Figura, Gijs Vermeulen Requirements: Mac OS development

  • DirectShow currently uses the old QuickTime decoding libraries on Mac. However, these are deprecated in favor of AVFoundation.
  • The work would consist of writing a new DirectShow filter that serves as a general-purpose demuxer/decoder using AVFoundation.
  • The decoder should generally follow the winegstreamer design structure. Possibly it can serve as a second backend, using the same PE-side code.
  • The same code may be usable for Media Foundation as well.

AVFoundation video capture support

Possible mentors: Zebediah Figura, Gijs Vermeulen Requirements: Mac OS development

  • Yet another DirectShow project: implement video capture on Mac.
  • Currently the only video capture backend is Video4Linux (i.e. v4l2). The work would consist of writing another backend using AVFoundation.
  • End goal would be to allow a native application to capture video.

DirectShow audio capture

Possible mentors: Zebediah Figura

  • Yet another DirectShow project: implement audio capture.
  • The work would consist of implementing the CLSID_AudioRecord object, which is currently only stubs.
  • Audio capture should probably be done through WinMM APIs (i.e. waveIn*).
  • End goal would be to allow a native application to capture audio.

Implement robocopy.exe

Possible mentors: Zebediah Figura


This page was last edited on 4 February 2021, at 16:39.