Difference between revisions of "Summer Of Code"

From WineHQ Wiki
Jump to: navigation, search
(adjust DirectX-D3DX9 and WineLib links)
 
(98 intermediate revisions by 16 users not shown)
Line 9: Line 9:
 
** If so, please introduce yourself on the [http://www.winehq.org/mailman/listinfo/wine-devel wine-devel mailing list] or the [irc://irc.freenode.net/#winehackers #winehackers IRC channel at freenode.net], and apply for a [http://code.google.com/soc Google Summer of Code scholarship]!
 
** If so, please introduce yourself on the [http://www.winehq.org/mailman/listinfo/wine-devel wine-devel mailing list] or the [irc://irc.freenode.net/#winehackers #winehackers IRC channel at freenode.net], and apply for a [http://code.google.com/soc Google Summer of Code scholarship]!
 
* Hint/reminders:
 
* Hint/reminders:
 +
** Have a look at [[Developers|the developers page on the wiki]] and grab Wine's [[Source_Code|source code]], try to get acquainted with it
 
** Look at [[Previous_Summers_of_Code|Previous Summers Of Code]] for previously accepted proposals / their results
 
** Look at [[Previous_Summers_of_Code|Previous Summers Of Code]] for previously accepted proposals / their results
** Do not forget: we can only support one proposal per application
+
** Do not forget: we can only support one proposal per application. You can file multiple applications if you want to propose more than one idea.
** We cannot accept [http://www.reactos.org ReactOS] proposals, so please only make proposals that will benefit Wine.
 
 
** Copying proposals verbatim will get your proposal deleted without even looking at it twice. You have to make your own proposal. See also [http://www.postgresql.org/developer/summerofcodeadvice PostgreSQL's Summer Of Code Advice]
 
** Copying proposals verbatim will get your proposal deleted without even looking at it twice. You have to make your own proposal. See also [http://www.postgresql.org/developer/summerofcodeadvice PostgreSQL's Summer Of Code Advice]
 
** Read [http://www.quora.com/How-can-I-prepare-for-GSoC-2015 How can I prepare for GSoC] for some general rules.
 
** Read [http://www.quora.com/How-can-I-prepare-for-GSoC-2015 How can I prepare for GSoC] for some general rules.
 
** Read [http://blog.gerv.net/2006/05/how_not_to_apply_for_summer_of/ How Not To Apply For Summer Of Code] to save your time and save our time.
 
** Read [http://blog.gerv.net/2006/05/how_not_to_apply_for_summer_of/ How Not To Apply For Summer Of Code] to save your time and save our time.
* Note: Applicants '''MUST''' have submitted a patch or testcase to wine-patches (see http://wiki.winehq.org/SubmittingPatches) to be considered for acceptance.
+
* Note: Applicants '''MUST''' have submitted a patch or testcase to wine-devel (see [[Submitting Patches]]) to be considered for acceptance.
To apply, go to the [https://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code 2015 home page].
+
To apply, go to the [https://developers.google.com/open-source/gsoc/ 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 [http://www.reactos.org ReactOS] proposals, so please only make proposals that will benefit Wine.
 +
To apply, go to the [https://developers.google.com/open-source/gsoc/ Google Summer of Code home page].
 +
-----
  
 
== Beware of Legal Requirements ==
 
== Beware of Legal Requirements ==
Line 28: Line 35:
 
* '''You are not allowed to analyze Windows files with the trace functions of Wine'''
 
* '''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'''
 
* '''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:
 +
* [https://www.outreachy.org/ 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.
 
-----
 
-----
  
Line 37: Line 49:
 
* 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.
 
* 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.
 
----
 
----
=== Tools - Implement resource editor and / or dialog editor ===
 
Possible Mentors: [[User:MarcusMeissner|Marcus Meissner]], [[User:AndreHentschel|André Hentschel]]
 
  
Knowledge prerequisite: C, some UI programming perhaps
+
=== Fix Tests on Your Windows Machine ===
 +
Possible mentors: Depends on the libraries you pick
  
Difficulty medium, might be bit large for a student project
+
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.
  
* We currently have no graphical dialog / resource editor
+
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.
* Free external ones are AdWare infected or Payware
 
----
 
=== Tools - Winetest Graphical User Interface ===
 
Possible Mentors: [[User:AndreHentschel|André Hentschel]]
 
  
Knowledge prerequisite: C
+
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.
  
Difficulty: Easy
+
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.
 
 
* Currently the only way to see test results in a nice synthetic format is to upload the report and view it at [http://test.winehq.org/data/ test.winehq.org].
 
* It would be nice to have a mode in [http://test.winehq.org/builds/winetest-latest.exe winetest.exe] that would present a nice table of available tests with their results, ideally updated on the fly as tests are run.
 
* The list could also be interactive and allow you to click on a test to run it again, view its result log, etc.
 
 
----
 
----
=== D3DX9 - Implement missing D3DX9 APIs ===
 
Possible Mentors: [[User:StefanDösinger|Stefan Dösinger]], [[User:MatteoBruni|Matteo Bruni]]
 
  
Knowledge prerequisite: C, maybe some domain-specific knowledge related to the APIs you want to implement
+
=== Upstream changes from winevdm ===
 +
Possible mentors: Stefan Dösinger
  
Difficulty: Easy to medium, depending on the functions you want to work on
+
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.
  
* [[DirectX-D3DX9|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.
+
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.
* 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: [[User:StefanDoesinger|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.
 
  
 +
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.
 
----
 
----
=== Direct3DRM - Implement rendering for D3DRM ===
 
Possible Mentors: [[User:StefanDoesinger|Stefan Dösinger]], [[User:AndreHentschel|André Hentschel]]
 
  
Knowledge prerequisite: C, DirectDraw, Direct3D
+
=== Multi-monitor display settings support on Mac ===
 +
Possible mentors: Zhiyi Zhang
  
Difficulty: Hard
+
* Currently, Wine supports enumerating multiple monitors(EnumDisplayMonitors) but cannot change their display settings on Mac(EnumDisplaySettings, ChangeDisplaySettings). On Mac, only the primary display settings can be changed. Multi-monitor display setting handlers are implemented in winex11.drv so we can do a similar thing in winemac.drv.  
 
+
* End goal would be to allow changing the display setting on multi-monitor Mac systems and passing all the tests in dlls/user32/tests/monitor.c
* D3DRM (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: [https://bugs.winehq.org/show_bug.cgi?id=12851 12851], [https://bugs.winehq.org/show_bug.cgi?id=19733 19733], [https://bugs.winehq.org/show_bug.cgi?id=21670 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: We'll provide you with the appropriate mentor
 
  
Knowledge prerequisite: C, CMD commands
+
=== Implement XRandR display settings handler with transforms ===
 +
Possible mentors: Zhiyi Zhang
  
Difficulty: Medium
+
* On Wayland and some setups with Nvidia proprietary drivers, XRandR reports only one resolution(https://bugs.winehq.org/show_bug.cgi?id=34348#c34). In this case, the proper solution is to use XRandR transforms to simulate display resolution changes so that Wine can support multiple display resolutions even if the host only report the native resolution.
 
+
* End goal would be to allow changing the display setting on Wayland and passing all the tests in dlls/user32/tests/monitor.c
* 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: [[User:AricStewart|Aric Stewart]]
+
=== DirectShow DVD support ===
 
+
Possible mentors: Zebediah Figura
Knowledge prerequisite: C
 
 
 
Difficulty: Medium
 
 
 
Work is being done to build a full HID infrastructure in wine. This will make it possible to implement Xinput on top of the HID.dll entry points. Doing this work would be extremely valuable as more and more games are requiring Xinput for controller input.
 
  
 +
* 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.
 
----
 
----
=== Linux Input driver for HidClass ===
 
Possible Mentors: [[User:AricStewart|Aric Stewart]]
 
  
Knowledge prerequisite: C, Linux Input
+
=== AVFoundation video capture support ===
 +
Possible mentors: Zebediah Figura, Gijs Vermeulen<br>
 +
Requirements: Mac OS development
  
Difficulty: Medium
+
* 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.
With the new HID infrastructure it is needed to write back-ends so that HID can communicate with the underlying operating system.  A working OS/X IOHid and Linux hidraw implementation have been written, however for full support on linux platforms a Linux Input version will also be required.  
+
* End goal would be to allow a native application to capture video.
 
----
 
----
=== Expand Dinput / WinMM (winejoystick.drv) to use HID.dll ===
 
Possible Mentors: [[User:AricStewart|Aric Stewart]]
 
  
Knowledge prerequisite: C
+
=== DirectShow audio capture ===
 +
Possible mentors: Zebediah Figura
  
Difficulty: Medium
+
* Yet another DirectShow project: implement audio capture.
 
+
* The work would consist of implementing the CLSID_AudioRecord object, which is currently only stubs.
The new HID infrastructure has a goal of moving all the platform specific code out of the various locations that communicate directly to the underlying OS for gamepad controller support to a single common location, HID. Then we need to rewrite the HID clients to actually be clients of HID.dll instead of having direct platform implementations.  
+
* Audio capture should probably be done through WinMM APIs (i.e. waveIn*).
 +
* End goal would be to allow a native application to capture audio.
 
----
 
----
=== Portability - Port WineLib to a new architecture ===
 
Possible mentors: [[User:AndreHentschel|André Hentschel]]
 
  
Knowledge prerequisite: Assembler for the target
+
=== Implement robocopy.exe ===
 +
Possible mentors: Zebediah Figura
  
Difficulty: Medium, depending on the target
+
* A complex copying program needed by some installers: <https://bugs.winehq.org/show_bug.cgi?id=43653>
 
+
* Work would consist of implementing the basic functionality of the program, including flags needed by the relevant programs.
* Wine can run WineLib applications on different CPU architectures, but needs at least some assembler code for that.
 
* Suggested architectures: [https://en.wikipedia.org/wiki/Ppc64 PowerPC64 (maybe POWER8?)], [http://en.wikipedia.org/wiki/Sparc64 Sparc64], [https://en.wikipedia.org/wiki/OpenRISC OpenRISC], [http://en.wikipedia.org/wiki/X32_ABI x32].
 
* You will also need a test system. Qemu should be possible.
 
 
----
 
----
=== Implementing XACT sound dlls ===
 
Possible mentors: [[User:AndrewEikum|Andrew Eikum]]
 
  
Knowledge prerequisite: C
+
=== Evaluate performance of hqemu in Hangover ===
 +
Possible mentors: Stefan Dösinger
  
Difficulty: Medium
+
Hangover (https://github.com/AndreRH/hangover) is a proof of concept of integrating a CPU emulator - in this case qemu - with Wine to run x86 Windows applications on non-x86 host CPUs without running a full Linux userspace stack inside the emulator. While its design is not suitable for upstream integration, it is useful for performance evaluation.
  
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.
+
hqemu (http://csl.iis.sinica.edu.tw/hqemu/) is a modification of qemu to generate more efficient translated code with the help of LLVM.
  
----
+
This project proposal is about merging together the hqemu modifications and hangover qemu modifications to evaluate the combined performance. Hangover ideally keeps the amount of code that needs to be emulated small and hqemu speeds up the emulation. If combined, they might either synergize well, or the faster emulation makes hangover's high level thunks moot.
=== WineCE: Implement the CommandBar ===
 
Possible mentors: [[User:AndreHentschel|André Hentschel]]
 
  
Knowledge prerequisite: C
+
To work on this you will need an arm64 Linux machine. Hangover is notoriously difficult to build. Please try to build and run both Hangover and hqemu separately before submitting your application. Try to get an idea of the modifications each project makes to qemu and how to reconcile them.  
 
 
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 [https://github.com/AndreRH/wine/blob/winece/dlls/commctrl/main.c#L41 the CommandBar].
 
* If there's time you could also implement [http://msdn.microsoft.com/en-us/library/aa931573.aspx CommandBands].
 
----
 
=== Winecfg / winemenubuilder - enhance MIME type handling ===
 
Possible Mentors: [[User:MichaelMueller|Michael Müller]], [[User:SebastianLackner|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 [https://forum.winehq.org/viewtopic.php?f=2&t=24237 Forum] or in the [https://bugs.winehq.org/show_bug.cgi?id=19182 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: [[User:NikolaySivov|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
 
 
----
 
----
=== Tools - Winetest Scripting Interface ===
 
Possible mentors: [[User:StefanDoesinger|Stefan Dösinger]]
 
 
Knowledge prerequisite: C, scripting language of your choice
 
 
Difficulty: Easy
 
 
Wine has an extensive set of regression tests. These tests can be helpful for projects Wine depends on. E.g. the developers of 3D drivers may want to run our d3d tests and our d3d implementation to test their OpenGL implementations.
 
  
One obstacle Mesa developers reported is that the default way to run tests (run "make test") only reports success or failure. That's OK when all tests are passing, but it is a problem when there are known test failures and you want to make sure you don't introduce additional failures. In this case users have to manually check the output written to stdout, which is a terrible task.
+
[[Category:Development]] [[Category:Internships]] [[Category:ToDo]]
 
 
The Wine testbot has some scripts to ignore known failures. It might help developers of dependency libraries if we made them available outside the testbot environment somehow. On the other hand we do not want to make the existing test code more complicated than it is. Ideally the tests themselves would not be modified.
 
 
 
For your proposal please think about what the API of such a scripting interface would look like and which information it provides to its callers.
 
 
 
----
 
[[Category:Development]] [[Category:ToDo]] [[Category:SummerofCode]]
 

Latest revision as of 00:53, 14 July 2021

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.

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.


Multi-monitor display settings support on Mac

Possible mentors: Zhiyi Zhang

  • Currently, Wine supports enumerating multiple monitors(EnumDisplayMonitors) but cannot change their display settings on Mac(EnumDisplaySettings, ChangeDisplaySettings). On Mac, only the primary display settings can be changed. Multi-monitor display setting handlers are implemented in winex11.drv so we can do a similar thing in winemac.drv.
  • End goal would be to allow changing the display setting on multi-monitor Mac systems and passing all the tests in dlls/user32/tests/monitor.c

Implement XRandR display settings handler with transforms

Possible mentors: Zhiyi Zhang

  • On Wayland and some setups with Nvidia proprietary drivers, XRandR reports only one resolution(https://bugs.winehq.org/show_bug.cgi?id=34348#c34). In this case, the proper solution is to use XRandR transforms to simulate display resolution changes so that Wine can support multiple display resolutions even if the host only report the native resolution.
  • End goal would be to allow changing the display setting on Wayland and passing all the tests in dlls/user32/tests/monitor.c

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 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


Evaluate performance of hqemu in Hangover

Possible mentors: Stefan Dösinger

Hangover (https://github.com/AndreRH/hangover) is a proof of concept of integrating a CPU emulator - in this case qemu - with Wine to run x86 Windows applications on non-x86 host CPUs without running a full Linux userspace stack inside the emulator. While its design is not suitable for upstream integration, it is useful for performance evaluation.

hqemu (http://csl.iis.sinica.edu.tw/hqemu/) is a modification of qemu to generate more efficient translated code with the help of LLVM.

This project proposal is about merging together the hqemu modifications and hangover qemu modifications to evaluate the combined performance. Hangover ideally keeps the amount of code that needs to be emulated small and hqemu speeds up the emulation. If combined, they might either synergize well, or the faster emulation makes hangover's high level thunks moot.

To work on this you will need an arm64 Linux machine. Hangover is notoriously difficult to build. Please try to build and run both Hangover and hqemu separately before submitting your application. Try to get an idea of the modifications each project makes to qemu and how to reconcile them.