Difference between revisions of "Summer Of Code"

From WineHQ Wiki
Jump to: navigation, search
 
(44 intermediate revisions by 10 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://developers.google.com/open-source/gsoc/ Google Summer of Code 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.
 +
* [https://codein.withgoogle.com/ 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.
 
-----
 
-----
  
Line 36: Line 49:
 
* If you have an idea, please post it on [http://www.winehq.org/pipermail/wine-devel 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.
 
* If you have an idea, please post it on [http://www.winehq.org/pipermail/wine-devel 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.
 
* 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.
 
 
 
----
 
----
=== Further cmd.exe improvements ===
+
=== Direct3D 10 Effects ===
 +
Possible Mentors: We'll provide you with the appropriate mentor
  
Further work on the cmd.exe implementation. We need to scope / find out what is missing before offering.
+
Difficulty: Medium
  
 +
* Direct3D 10 implements effects in d3d10.dll. Native d3d10.dll cannot be used in Wine; thus, it would be quite valuable to have a better support for Direct3D 10 effects.
 +
* The work would consists of writing more tests for Direct3D 10 effects and implementing missing functionality.
 +
* The project goal could be set to fix/improve Steam Big Picture rendering in Wine, see bug [https://bugs.winehq.org/show_bug.cgi?id=44120 44120].
 
----
 
----
=== Implement ping.exe ===
+
=== VKD3D - Write more tests for Direct3D 12 ===
 +
Possible Mentors: We'll provide you with the appropriate mentor
  
(We could also forward to ping.exe ... ) We have one, but we could hook in icmp.dll usage.
+
Knowledge prerequisite: C, knowledge of Direct3D 11, 12 or any 3D graphics API is helpful
Or call out to system /usr/bin/ping
 
  
Might not be big enough for GSOC.
+
Difficulty: Easy
  
 +
* [https://source.winehq.org/git/vkd3d.git/ VKD3D] is a D3D12 to Vulkan translation library. It has a test suite which verifies behavior of Direct3D 12 API.
 +
* The work would consists of writing more tests for Direct3D 12 API.
 +
* Direct3D 11 tests from Wine conformance tests are good candidates to be ported to Direct3D 12 tests.
 
----
 
----
 +
=== Direct3D - Microbenchmarks ===
 +
Possible Mentors: [[User:StefanDoesinger|Stefan Dösinger]]
  
=== Fix Windows theming / implement themes ===
+
Knowledge prerequisite: C, Direct3D, OpenGL
  
After we fix Windows theming in Wine (project 1) we could implement themes (project 2).
+
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.
=== Improve Wines fonts ===
 
 
 
Improve our own fonts and/ or add new fonts.  
 
(This is not for GSOC usually, more for Outreachy)
 
  
 +
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.
 
----
 
----
=== Improve accessibility of Wine ===
+
=== Make explorer.exe more useful ===
 +
Possible Mentors: We'll provide you with the appropriate mentor
  
Wines accessibility for e.g. blind people is lacking and can use improvements.
+
Knowledge prerequisite: C, Win32
  
 +
Difficulty: Medium
  
----
+
Wine's file explorer allows a user to browse files but many features are missing.  In particular, there is no support for drag & drop copying and moving of files and directories.
=== winetest improvements ===
 
  
Improve the server and/or client side of the wine test framework. (?)
+
On many platforms, using a native file browser is a more natural alternative.  However, on Android (and Chrome OS) machines, improving Wine's file browser could be better than using a native file browser.  This is because of the Android security model and file system structure.  Wine, when installed on Android, lives in a sandbox running as its own user, and on a non-rooted device, a native file browser will not have access to the files inside the Wine prefix.  A user who wants to copy files from the limited areas of shared storage (i.e., the Downloads folder) into the c: drive, or vice versa, basically has to use a wine command prompt. Adding move / copy features to Wine's file explorer would provide a more user-friendly mechanism (which could also be used on other Wine platforms if desired)
  
 +
Not being able to interact easily with the wineprefix is a major and basic usability issue with Wine on Android and Chrome OS.  You can fix it!
 
----
 
----
=== signtool.exe ===
+
=== Direct3DRM - Implement rendering for D3DRM ===
 +
Possible Mentors: [[User:StefanDoesinger|Stefan Dösinger]], [[User:AndreHentschel|André Hentschel]]
  
A tool to verify signatures on MSI packages / EXEs(?)
+
Knowledge prerequisite: C, DirectDraw, Direct3D
  
(Need to evaluate if effort matches GSOC effort scope.)
+
Difficulty: Hard
  
 +
* D3DRM (Direct3D Retained Mode) is partially implemented, 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.
 +
* Basic object creation, ddraw initialization and stand-alone math functions are implemented. Very rudimentary display functionality exists.
 +
* The most notable missing features are geometry and texture handling, state management and actual 3D draws.
 +
Applicants should have understanding of how 3D APIs work, and specific knowledge in old Direct3D / DirectDraw versions will be of an advantage. You will have to work with file formats for 3D geometry and textures, fixed function transformation and the really awful Direct3D 1 interface.
 
----
 
----
  
=== tasklist.exe ===
+
=== D3DX9 - Implement missing D3DX9 APIs ===
 +
Possible Mentors: [[User:StefanDösinger|Stefan Dösinger]], [[User:MatteoBruni|Matteo Bruni]]
  
A tool to list currently running programs.
+
Knowledge prerequisite: C, maybe some domain-specific knowledge related to the APIs you want to implement
  
(Need to evaluate if effort matches GSOC effort scope.)
+
Difficulty: Easy to medium, depending on the functions you want to work on
 
 
See, e.g., https://bugs.winehq.org/show_bug.cgi?id=43990
 
  
 +
* [[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.
 +
* 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
 +
** effect framework bits and pieces
 +
** drawing text in ID3DXFont
 +
* 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.
 
----
 
----
 +
=== Tools - Winetest Scripting Interface ===
 +
Possible mentors: [[User:StefanDoesinger|Stefan Dösinger]]
  
=== Calculator ===
+
Knowledge prerequisite: C, scripting language of your choice
  
Implement a calc.exe.
+
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.
=== DPI Resolution handling ===
 
  
We have some DPI resolution issues, some work in this area is needed.  
+
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.
  
 +
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.
 
----
 
----
=== DirectPlay ===
+
=== DirectWrite: Implement vertical text layout support ===
 +
Possible mentors: [[User:NikolaySivov|Nikolay Sivov]]
  
Is there any work needed on DirectPlay... Identify missing things.
+
Knowledge prerequisite: C
  
----
+
Difficulty: Medium
=== Common Item Dialog Box improvements ===
 
  
Ask Vincent Povirk about details / ideas.
+
DirectWrite is a text layout and rendering library available on recent Windows releases, starting with Vista. It provides several API layers to manage font file, process text, render it, and interact with GDI subsystem. A lot of basic functionality is already supported in Wine, this proposal is however about specific feature to process and render text in vertical mode. This touches every layer mentioned above, brief summary on what needs to be done follows:
  
Improvements of this dialog box framework.
+
* AnalyzeVerticalGlyphOrientation - this method analyzes input text and returns orientation for every part of the text;
 
+
* GetVerticalGlyphVariants - returns vertical glyphs for specified nominal glyphs, if font has any;
----
+
* vertical glyph metrics should be properly returned, that includes GetDesignGlyphAdvances;
=== Improvements of specific Windows applications ===
+
* layout part has to support vertical direction when building lines, this implies baseline calculation, alignment logic changes, maybe something else;
 
+
* IDWriteBitmapRenderTarget1 and IDWriteGlyphRunAnalysis have to support sideways mode too.
Hard to scope the effort for specific applications beforehand to meet the GSOC effort range.
 
 
 
(brainstorm: Perhaps select some "known" apps that might be in the range?)
 
 
 
----
 
=== Improve the AppDB ===
 
 
 
Our application database written in PHP code is in need of improvements and bugfixes. (fill in)
 
 
 
Cross check with Roseanne on needed projects.
 
 
 
- accessibility
 
 
 
 
 
----
 
=== Tools - implement a wine diagnostic tool ===
 
 
 
Collect data about the current installation that can be used for AppDB or bugreporting. Things like wine version, operating system, native dlls versions, etc.
 
----
 
=== 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
 
 
 
Difficulty medium, might be bit large for a student project
 
 
 
* We currently have no graphical dialog / resource editor
 
* Free external ones are AdWare infected or Payware
 
 
----
 
----
=== Tools - Winetest Graphical User Interface ===
+
=== crypt32: Implement DSS (digital signature standard) Provider ===
Possible Mentors: [[User:AndreHentschel|André Hentschel]]
+
Possible mentors: Hans Leidekker
  
 
Knowledge prerequisite: C
 
Knowledge prerequisite: C
  
Difficulty: Easy
+
Difficulty: Medium
  
* 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].
+
Many .NET applications fail to run, because currently the DSS and enhanced DSS provider are missing in crypt32.dll.
* 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.
+
There are already some tests for that, but more might be necessary. See also [https://bugs.winehq.org/show_bug.cgi?id=10506 Bug 10506]
* The list could also be interactive and allow you to click on a test to run it again, view its result log, etc.
 
 
----
 
----
=== VKD3D - Write more tests for Direct3D 12 ===
 
Possible Mentors: Józef Kucia
 
  
Knowledge prerequisite: C, knowledge of Direct3D 11, 12 or any 3D graphics API is helpful
+
=== AppDB improvements ===
 +
Possible mentors: Jeremy Newman, Rosanne DiMesio
  
Difficulty: Easy
+
Knowledge prerequisite: PHP, HTML, MySQL
  
* [https://source.winehq.org/git/vkd3d.git/ VKD3D] is a D3D12 to Vulkan translation library. It has a test suite which verifies behavior of Direct3D 12 API.
+
Wine's Application Database (https://appdb.winehq.org/) is old and could use improvements. If you have ideas for improvements and new features please step forward!
* The work would consists of writing more tests for Direct3D 12 API.
 
* Direct3D 11 tests from Wine conformance tests are good candidates to be ported to Direct3D 12 tests.
 
 
----
 
----
 +
=== Uniscribe: Improve Indic language support ===
 +
Possible mentors: [[User:AricStewart|Aric Stewart]]
  
=== Direct3D 10 Effects ===
+
Knowledge prerequisite: C, familiarity with fonts and opentype a plus,  familiarity/fluency in Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada or Malayalam not required but a big plus.
Possible Mentors: Józef Kucia
 
  
 
Difficulty: Medium
 
Difficulty: Medium
  
* Direct3D 10 implements effects in d3d10.dll. Native d3d10.dll cannot be used in Wine; thus, it would be quite valuable to have a better support for Direct3D 10 effects.
+
Uniscribe is the text layout and rendering system for earlier versions of windows and much of the Wine UI. The frameworks is mostly in place as well as a first pass implementation for many languages including the Indic languages. However nobody with more than a passing knowledge of the languages has dug into the details and issues in properly displaying these complicated languages.  Including issues around separate Indic matras. Ideally the student working on this will also be fluent enough to at least start doing some translation of the Wine strings into the target language as well, so that Wine's usability in those languages greatly improves.
* The work would consists of writing more tests for Direct3D 10 effects and implementing missing functionality.
 
* The project goal could be set to fix/improve Steam Big Picture rendering in Wine, see bug [https://bugs.winehq.org/show_bug.cgi?id=44120 44120].
 
 
----
 
----
 +
=== Implement Windows Media Player control ===
 +
Possible mentors: We'll provide you with the appropriate mentor
  
=== VKD3D - DXBC/Direct3D 10 shader reflection ===
+
Knowledge prerequisite: C, COM+, OLE32, DirectShow?
Possible Mentors: Józef Kucia
 
  
* VKD3D (https://source.winehq.org/git/vkd3d.git/) contains libvkd3d-shader library which has a parser for shaders in the DXBC format.
+
Difficulty: Medium
* The goal of project would be to introduce shader reflection API to libvkd3d-shader. In long-term, the API could be used to implement Direct3D 10 shader reflection - ID3D10ShaderReflection.
 
* The work would consists of writing tests for ID3D10ShaderReflection and developing a new libvkd3d-shader reflection API.
 
* The following WineHQ bugs are related: 39816 (https://bugs.winehq.org/show_bug.cgi?id=39816) and 43042 (https://bugs.winehq.org/show_bug.cgi?id=43042).
 
----
 
=== 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
+
A lot of apps and libraries use Windows Media Player COM/ActiveX control to implement media playback (Including MS .Net's  System.Windows.Media.MediaPlayer class).
 +
Users can usually workaround this by just installing windows media player 9 or 10. However this technically requires a Windows license.
 +
Wine currently has a stub-only implementation of WMP.
 +
WMP can be used in a headless mode for media playback or could be used as a full UI component with full controls. For the purpose of GSoC scope could be limited to headless parts.
  
Difficulty: Easy to medium, depending on the functions you want to work on
+
It would be nice to have a builtin implementation.  Potentially media playback could be implemented using DirectShow.
  
* [[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.
+
This project should most likely have an end goal of "Have <insert app/game here> work with builtin WMP implementation and have audio/video media playback working".
* 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
 
** effect framework bits and pieces
 
** drawing text in ID3DXFont
 
* 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 ===
+
=== Winecfg / winemenubuilder - enhance MIME type handling ===
Possible Mentors: [[User:StefanDoesinger|Stefan Dösinger]]
+
Possible Mentors: [[User:MichaelMueller|Michael Müller]], [[User:SebastianLackner|Sebastian Lackner]]
  
Knowledge prerequisite: C, Direct3D, OpenGL
+
Knowledge prerequisite: C
  
 
Difficulty: Medium
 
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.
+
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.
 
 
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.
 
  
 +
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.
 
----
 
----
=== Direct3D - Automated game benchmarks ===
+
=== XMLLite: Implement fully compatible xmllite parser ===
Possible Mentors: [[User:StefanDoesinger|Stefan Dösinger]]
+
Possible mentors: [[User:NikolaySivov|Nikolay Sivov]]
  
Knowledge prerequisite: Autohotkey, knowledge of common game engines
+
Knowledge prerequisite: C
  
 
Difficulty: Medium
 
Difficulty: Medium
  
Monitoring performance over time is a tedious task. In many cases it requires manual gameplay, and the results are unreliable if the gameplay is not 100% the same every time. It would be much better if the game could be scripted to produce a reliable result without human intervention.
+
* 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 - Implement resource editor and / or dialog editor ===
 +
Possible Mentors: [[User:MarcusMeissner|Marcus Meissner]]
  
Many games have a replay mode or even a builtin benchmark mode for this purpose. [[User:StefanDoesinger|Stefan Dösinger]] has written a few scripts for Half Life 2, Unreal Tournament, Trackmania and a few other games to monitor performance. More tests are needed, especially with newer games.
+
Knowledge prerequisite: C, some UI programming perhaps
  
If you know some games that offer a benchmark mode that can be controlled from the command line or via Autohotkey this task may be right for you. The goal is to write scripts that can run the games on Windows (and thus by extension in Wine), configure common settings, run a benchmark and read the result. Stefan's scripts track the results via the Phoronix Test Suite, but other performance monitoring tools can be used as well.
+
Difficulty medium, might be bit large for a student project
  
 +
* We currently have no graphical dialog / resource editor
 +
* Free external ones are AdWare infected or Payware
 
----
 
----
=== Direct3DRM - Implement rendering for D3DRM ===
 
Possible Mentors: [[User:StefanDoesinger|Stefan Dösinger]], [[User:AndreHentschel|André Hentschel]]
 
  
Knowledge prerequisite: C, DirectDraw, Direct3D
 
 
Difficulty: Hard
 
 
* D3DRM (Direct3D Retained Mode) is partially implemented, 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.
 
* Basic object creation, ddraw initialization and stand-alone math functions are implemented. Very rudimentary display functionality exists.
 
* The most notable missing features are geometry and texture handling, state management and actual 3D draws.
 
Applicants should have understanding of how 3D APIs work, and specific knowledge in old Direct3D / DirectDraw versions will be of an advantage. You will have to work with file formats for 3D geometry and textures, fixed function transformation and the really awful Direct3D 1 interface.
 
----
 
 
=== CMD - implement more robust parser ===
 
=== CMD - implement more robust parser ===
 
Possible Mentors: We'll provide you with the appropriate mentor
 
Possible Mentors: We'll provide you with the appropriate mentor
  
Knowledge prerequisite: C, CMD commands
+
Knowledge prerequisite: C, bison, flex, CMD commands
  
 
Difficulty: Medium
 
Difficulty: Medium
Line 259: Line 247:
 
* 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.
 
* 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.
 
----
 
----
 +
 
=== Portability - Port WineLib to a new architecture ===
 
=== Portability - Port WineLib to a new architecture ===
 
Possible mentors: [[User:AndreHentschel|André Hentschel]]
 
Possible mentors: [[User:AndreHentschel|André Hentschel]]
Line 267: Line 256:
  
 
* Wine can run WineLib applications on different CPU architectures, but needs at least some assembler code for that.
 
* 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/RISC-V RISC-V], [http://en.wikipedia.org/wiki/X32_ABI x32].
+
* Suggested architectures: [https://en.wikipedia.org/wiki/Ppc64 PowerPC64 (maybe POWER8?)], [http://en.wikipedia.org/wiki/Sparc64 Sparc64], [https://en.wikipedia.org/wiki/RISC-V RISC-V].
 
* You will also need a test system. Qemu should be possible.
 
* You will also need a test system. Qemu should be possible.
 
----
 
----
=== Implementing XACT sound dlls ===
+
 
Possible mentors: [[User:AndrewEikum|Andrew Eikum]]
+
<!--
 +
=== VFW - Implement Indeo codecs ===
 +
Possible mentors: [[User:zf|Zebediah Figura]]
  
 
Knowledge prerequisite: C
 
Knowledge prerequisite: C
  
Difficulty: Medium
+
Difficulty: Easy
 +
 
 +
* Many old games need an implementation of the various Indeo codecs (ir32_32.dll, etc.) For an example see [https://bugs.winehq.org/show_bug.cgi?id=27244 bug 27244].
 +
* Actual decompression code should probably be copied from libavcodec.
 +
----
 +
-->
 +
<!--
 +
=== Implement calculator app ===
 +
Possible mentors:
  
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, xapofx) involved, so only a portion would be done for the project. Some examples would be implementing xaudio effects like reverb and echo, or implementing 3D positional audio.
+
Knowledge prerequisite: C
  
 +
Difficulty: Easy
 +
 +
* There are actually multiple applications which try to open the Windows Calculator, see [https://bugs.winehq.org/show_bug.cgi?id=15555 bug 15555].
 +
* [http://www.jebriggs.com/winecalc/ GNU winecalc] is an open source (LGPL) calculator app for Win32, but it would require so much refactoring to be accepted into Wine that it would probably be easier to start from scratch.
 +
* ReactOS also has an open source calculator app, but its stricter GPL license means that it cannot be used in Wine in any form.
 +
* The first step would be to implement a 4-function calculator, and then add features like memory registers and a scientific mode.
 
----
 
----
=== WineCE: Implement the CommandBar ===
+
-->
Possible mentors: [[User:AndreHentschel|André Hentschel]]
+
 
 +
=== mspatcha - implement patch parser ===
 +
Possible mentors: [[User:zf|Zebediah Figura]]
  
 
Knowledge prerequisite: C
 
Knowledge prerequisite: C
  
Other prerequisite: ARM device with Linux or some Qemu experience
+
Difficulty: Medium
  
Difficulty: Medium
+
* Many MSI installers ship patch files to update or install programs; see [https://bugs.winehq.org/show_bug.cgi?id=12501 bug 12501]. These patch files are in an undocumented binary format.
 +
* Project would consist of reverse-engineering the patch format and implementing a parser. Ultimate goal is a working ApplyPatchToFile() implementation.
 +
* A way to create new patch files (i.e. mspatchc.dll / mpatch.exe) could also be useful.
  
* 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 ===
+
=== Testbot ideas ===
Possible Mentors: [[User:MichaelMueller|Michael Müller]], [[User:SebastianLackner|Sebastian Lackner]]
+
See the [https://testbot.winehq.org/ Wine Test Bot] site and the source at [https://source.winehq.org/git/tools.git/tree/HEAD:/testbot tools.git]
 +
==== Javascript-ification of the site ====
 +
Possible mentors: François Gouget
 +
 
 +
Knowledge prerequisites: Perl (server side), JavaScript, REST or equivalent
  
Knowledge prerequisite: C
+
The goal would be to avoid reloading pages all the time, starting with the Job details page and moving on to other pages if time permits.
 +
* A prime target would be the job details page which reloads every time one shows / hides a log or a screenshot. Dealing with screenshots should be easy. The interesting part would be to have the website provide an API to retrieve the logs which the JavaScript code would then insert in the right place, taking into account that logs are not available until a task has completed. Also, instead of reloading the whole page regularly, the JavaScript code should query for changes to the Job status and update the page accordingly.
 +
* Similarly, instead of reloading all of the main page regularly, JavaScript could be used to retrieve just the new jobs and status changes, and then update the page.
 +
* The job submit page could also use JavaScript to have all operations happen on a single page and make uploading the patch / executable smoother.
 +
* Finally, refreshing the activity page could benefit from a similar treatment to the main page.
 +
* Note: As part of this project you will have to set up your own TestBot instance, that is the Engine, webserver and a QEmu VM.
  
Difficulty: Medium
+
----
 +
==== Swap TestBot's Object Relational Mapper ====
 +
Possible mentors: François Gouget
  
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.
+
Knowledge prerequisite: Perl, SQL
  
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.
+
* The TestBot uses its own Perl ORM implementation which has a lot of issues: [https://bugs.winehq.org/show_bug.cgi?id=45023 Bug 45023]
 +
* These issues are currently not blocking the TestBot development but the performance is pretty bad: see for instance the load times for the main and activity pages. It seems likely that the current ORM is responsible for the poor performance.
 +
* So the goal of this project would be to switch the TestBot to a standard ORM, one with better performance and that does not need to be maintained as part of the TestBot codebase.
 +
* The first task will be to pick a replacement Perl ORM based on functionality, community support and performance. The next point can help for that last part.
 +
* To test the performance aspect, the project can convert access to the Records and RecordGroups tables since they are isolated.
 +
* The difficulty with the switch is that the rest of the TestBot's tables are all connected together: in $Task->VM the ORM takes care of returning the appropriate VM object for the Task, which would not work if the Task and VM tables are accessed using different ORMs. So an important part of the project will be to figure out how to handle the transition.
 +
* Note: As part of this project you would have to set up your own TestBot instance, that is the Engine, webserver and a QEmu VM.
  
 
----
 
----
=== XMLLite: Implement fully compatible xmllite parser ===
+
==== Implement load balancing and fail-over ====
Possible mentors: [[User:NikolaySivov|Nikolay Sivov]]
+
Possible mentors: François Gouget
 +
 
 +
Knowledge prerequisite: Perl, SQL
 +
 
 +
Difficulty: Hard
 +
 
 +
See [https://bugs.winehq.org/show_bug.cgi?id=39412 Bug 39412]
 +
This implies:
 +
* Currently a VM, such as a Windows 7 VM, can only be present on a single VM host. If that host goes down, the corresponding tasks cannot be run: there is no fail-over. Similarly if the VM host is busy running other VMs, the task cannot be moved to a less busy host: there is no load balancing. The goal is to change that to improve the reliability and performance of the TestBot.
 +
* In the current schema a Task is associated to the VM that it will run on. However that model will need to be expanded:
 +
** We can already have multiple test configurations for a single VM. This is done by having one VM snapshot per configuration, for instance one per locale. Since there is a single VM, only one configuration can be tested at a time. This is currently represented as separate VM objects and it's up to the task scheduler to detect when two objects reference the same VM and thus to not try to use both at the same time. The new schema should probably find a better way to represent the relationship between the tasks, test configurations and VMs.
 +
** The VM object specifies the hypervisor instance, and thus VM host, used to access it. If a VM is present on multiple VM hosts it's possible to create one VM object for each. However since Tasks link directly to VMs, once created a task would be linked to the VM instance on a specific VM hosts, thus preventing failover. So a better are of representing the relationship between the tasks, VMs, VM instances and VM host / hypervisor is needed.
 +
** The new schema will also need a way to represent licensing restrictions. The TestBot typically has a single license for the Windows VMs, which means at most one instance can run at a time, even if the VM is present on two hosts. But the TestBot should be able to run two or more instances of the Linux-based VMs simultaneously.
 +
** While allocating hypervisor resources for specific VM instances is not part of this project, the new schema should be extensible so one can represent the hypervisor resources and the corresponding VM requirements.
 +
* So the project will need to:
 +
** Update the database schema to account for the above requirements.
 +
** Provide SQL code to update the existing tables.
 +
* Update the code impacted by the schema changes (essentially everything).
 +
* Update the task scheduler to implement fail-over and load balancing.
 +
* Note: As part of this project you would have to set up your own TestBot instance, that is the Engine, webserver and a couple of QEmu VMs.
  
Knowledge prerequisite: C
+
----
 +
=== Unsorted further ideas ===
 +
==== Further cmd.exe improvements ====
  
Difficulty: Medium
+
Further work on the cmd.exe implementation. We need to scope / find out what is missing before offering.
  
* 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 ===
+
==== Fix Windows theming / implement themes ====
Possible mentors: [[User:StefanDoesinger|Stefan Dösinger]]
+
 
 +
After we fix Windows theming in Wine (project 1) we could implement themes (project 2).
  
Knowledge prerequisite: C, scripting language of your choice
+
----
 +
==== Improve Wine's fonts ====
  
Difficulty: Easy
+
Improve our own fonts and/ or add new fonts.
 +
(This is not for GSOC usually, more for Outreachy)
  
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.
+
----
 +
==== Improve accessibility of Wine ====
  
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.
+
Wines accessibility for e.g. blind people is lacking and can use improvements.
  
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.
+
----
 +
==== winetest improvements ====
  
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.
+
Improve the server and/or client side of the wine test framework. (?)
  
 
----
 
----
=== DirectWrite: Implement vertical text layout support ===
+
==== signtool.exe ====
Possible mentors: [[User:NikolaySivov|Nikolay Sivov]]
+
 
 +
A tool to verify signatures on MSI packages / EXEs(?)
  
Knowledge prerequisite: C
+
(Need to evaluate if effort matches GSOC effort scope.)
  
Difficulty: Medium
+
----
 +
==== tasklist.exe ====
  
DirectWrite is a text layout and rendering library available on recent Windows releases, starting with Vista. It provides several API layers to manage font file, process text, render it, and interact with GDI subsystem. A lot of basic functionality is already supported in Wine, this proposal is however about specific feature to process and render text in vertical mode. This touches every layer mentioned above, brief summary on what needs to be done follows:
+
A tool to list currently running programs.
  
* AnalyzeVerticalGlyphOrientation - this method analyzes input text and returns orientation for every part of the text;
+
(Need to evaluate if effort matches GSOC effort scope.)
* GetVerticalGlyphVariants - returns vertical glyphs for specified nominal glyphs, if font has any;
 
* vertical glyph metrics should be properly returned, that includes GetDesignGlyphAdvances;
 
* layout part has to support vertical direction when building lines, this implies baseline calculation, alignment logic changes, maybe something else;
 
* IDWriteBitmapRenderTarget1 and IDWriteGlyphRunAnalysis have to support sideways mode too.
 
  
=== AppDB improvements ===
+
See, e.g., https://bugs.winehq.org/show_bug.cgi?id=43990
Possible mentors: Jeremy Newman, Rosanne DiMesio
 
  
Knowledge prerequisite: PHP, HTML, MySQL
+
----
 +
==== DPI Resolution handling ====
  
Wine's Application Database (https://appdb.winehq.org/) is old and could use improvements. If you have ideas for improvements and new features please step forward!
+
We have some DPI resolution issues, some work in this area is needed.  
  
 
----
 
----
=== Uniscribe: Improve Indic language support ===
+
==== DirectPlay ====
Possible mentors: [[User:AricStewart|Aric Stewart]]
 
  
Knowledge prerequisite: C, familiarity with fonts and opentype a plus,  familiarity/fluency in Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada or Malayalam not required but a big plus.
+
Is there any work needed on DirectPlay... Identify missing things.
  
Difficulty: Medium
+
----
 +
==== Common Item Dialog Box improvements ====
  
Uniscribe is the text layout and rendering system for earlier versions of windows and much of the Wine UI.  The frameworks is mostly in place as well as a first pass implementation for many languages including the Indic languages. However nobody with more than a passing knowledge of the languages has dug into the details and issues in properly displaying these complicated languages.  Including issues around separate Indic matras. Ideally the student working on this will also be fluent enough to at least start doing some translation of the Wine strings into the target language as well, so that Wine's usability in those languages greatly improves.
+
Ask Vincent Povirk about details / ideas.
  
 +
Improvements of this dialog box framework.
  
 
----
 
----
=== Implement Unicode string normalization ===
+
==== Improvements of specific Windows applications ====
Possible mentors:
 
  
Knowledge prerequisite: C
+
Hard to scope the effort for specific applications beforehand to meet the GSOC effort range.
  
Difficulty: Medium
+
(brainstorm: Perhaps select some "known" apps that might be in the range?)
  
Unicode string normalization handles transformations between composed and decomposed character forms. Windows exposes this functionality with NormalizeString and IsNormalizedString functions.
+
----
 +
==== Tools - implement a wine diagnostic tool ====
  
Implementation should be based on publicly available character classification data provided by Unicode.org. Simple external program to check algorithm conformance using Unicode.org test data is also required, as well as some Win32 tests added to wine tests suite.
+
Collect data about the current installation that can be used for AppDB or bugreporting. Things like wine version, operating system, native dlls versions, etc.
  
 +
----
  
[[Category:Development]] [[Category:Summer of Code]] [[Category:ToDo]]
+
[[Category:Development]] [[Category:Internships]] [[Category:ToDo]]

Latest revision as of 04:31, 18 March 2020

Contents

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.

Direct3D 10 Effects

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

Difficulty: Medium

  • Direct3D 10 implements effects in d3d10.dll. Native d3d10.dll cannot be used in Wine; thus, it would be quite valuable to have a better support for Direct3D 10 effects.
  • The work would consists of writing more tests for Direct3D 10 effects and implementing missing functionality.
  • The project goal could be set to fix/improve Steam Big Picture rendering in Wine, see bug 44120.

VKD3D - Write more tests for Direct3D 12

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

Knowledge prerequisite: C, knowledge of Direct3D 11, 12 or any 3D graphics API is helpful

Difficulty: Easy

  • VKD3D is a D3D12 to Vulkan translation library. It has a test suite which verifies behavior of Direct3D 12 API.
  • The work would consists of writing more tests for Direct3D 12 API.
  • Direct3D 11 tests from Wine conformance tests are good candidates to be ported to Direct3D 12 tests.

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.


Make explorer.exe more useful

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

Knowledge prerequisite: C, Win32

Difficulty: Medium

Wine's file explorer allows a user to browse files but many features are missing. In particular, there is no support for drag & drop copying and moving of files and directories.

On many platforms, using a native file browser is a more natural alternative. However, on Android (and Chrome OS) machines, improving Wine's file browser could be better than using a native file browser. This is because of the Android security model and file system structure. Wine, when installed on Android, lives in a sandbox running as its own user, and on a non-rooted device, a native file browser will not have access to the files inside the Wine prefix. A user who wants to copy files from the limited areas of shared storage (i.e., the Downloads folder) into the c: drive, or vice versa, basically has to use a wine command prompt. Adding move / copy features to Wine's file explorer would provide a more user-friendly mechanism (which could also be used on other Wine platforms if desired).

Not being able to interact easily with the wineprefix is a major and basic usability issue with Wine on Android and Chrome OS. You can fix it!


Direct3DRM - Implement rendering for D3DRM

Possible Mentors: Stefan Dösinger, André Hentschel

Knowledge prerequisite: C, DirectDraw, Direct3D

Difficulty: Hard

  • D3DRM (Direct3D Retained Mode) is partially implemented, 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.
  • Basic object creation, ddraw initialization and stand-alone math functions are implemented. Very rudimentary display functionality exists.
  • The most notable missing features are geometry and texture handling, state management and actual 3D draws.

Applicants should have understanding of how 3D APIs work, and specific knowledge in old Direct3D / DirectDraw versions will be of an advantage. You will have to work with file formats for 3D geometry and textures, fixed function transformation and the really awful Direct3D 1 interface.


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
    • effect framework bits and pieces
    • drawing text in ID3DXFont
  • 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.

Tools - Winetest Scripting Interface

Possible mentors: 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.

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.


DirectWrite: Implement vertical text layout support

Possible mentors: Nikolay Sivov

Knowledge prerequisite: C

Difficulty: Medium

DirectWrite is a text layout and rendering library available on recent Windows releases, starting with Vista. It provides several API layers to manage font file, process text, render it, and interact with GDI subsystem. A lot of basic functionality is already supported in Wine, this proposal is however about specific feature to process and render text in vertical mode. This touches every layer mentioned above, brief summary on what needs to be done follows:

  • AnalyzeVerticalGlyphOrientation - this method analyzes input text and returns orientation for every part of the text;
  • GetVerticalGlyphVariants - returns vertical glyphs for specified nominal glyphs, if font has any;
  • vertical glyph metrics should be properly returned, that includes GetDesignGlyphAdvances;
  • layout part has to support vertical direction when building lines, this implies baseline calculation, alignment logic changes, maybe something else;
  • IDWriteBitmapRenderTarget1 and IDWriteGlyphRunAnalysis have to support sideways mode too.

crypt32: Implement DSS (digital signature standard) Provider

Possible mentors: Hans Leidekker

Knowledge prerequisite: C

Difficulty: Medium

Many .NET applications fail to run, because currently the DSS and enhanced DSS provider are missing in crypt32.dll. There are already some tests for that, but more might be necessary. See also Bug 10506


AppDB improvements

Possible mentors: Jeremy Newman, Rosanne DiMesio

Knowledge prerequisite: PHP, HTML, MySQL

Wine's Application Database (https://appdb.winehq.org/) is old and could use improvements. If you have ideas for improvements and new features please step forward!


Uniscribe: Improve Indic language support

Possible mentors: Aric Stewart

Knowledge prerequisite: C, familiarity with fonts and opentype a plus, familiarity/fluency in Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada or Malayalam not required but a big plus.

Difficulty: Medium

Uniscribe is the text layout and rendering system for earlier versions of windows and much of the Wine UI. The frameworks is mostly in place as well as a first pass implementation for many languages including the Indic languages. However nobody with more than a passing knowledge of the languages has dug into the details and issues in properly displaying these complicated languages. Including issues around separate Indic matras. Ideally the student working on this will also be fluent enough to at least start doing some translation of the Wine strings into the target language as well, so that Wine's usability in those languages greatly improves.


Implement Windows Media Player control

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

Knowledge prerequisite: C, COM+, OLE32, DirectShow?

Difficulty: Medium

A lot of apps and libraries use Windows Media Player COM/ActiveX control to implement media playback (Including MS .Net's System.Windows.Media.MediaPlayer class). Users can usually workaround this by just installing windows media player 9 or 10. However this technically requires a Windows license. Wine currently has a stub-only implementation of WMP. WMP can be used in a headless mode for media playback or could be used as a full UI component with full controls. For the purpose of GSoC scope could be limited to headless parts.

It would be nice to have a builtin implementation. Potentially media playback could be implemented using DirectShow.

This project should most likely have an end goal of "Have <insert app/game here> work with builtin WMP implementation and have audio/video media playback working".


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

Tools - Implement resource editor and / or dialog editor

Possible Mentors: Marcus Meissner

Knowledge prerequisite: C, some UI programming perhaps

Difficulty medium, might be bit large for a student project

  • We currently have no graphical dialog / resource editor
  • Free external ones are AdWare infected or Payware

CMD - implement more robust parser

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

Knowledge prerequisite: C, bison, flex, 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.

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: PowerPC64 (maybe POWER8?), Sparc64, RISC-V.
  • You will also need a test system. Qemu should be possible.


mspatcha - implement patch parser

Possible mentors: Zebediah Figura

Knowledge prerequisite: C

Difficulty: Medium

  • Many MSI installers ship patch files to update or install programs; see bug 12501. These patch files are in an undocumented binary format.
  • Project would consist of reverse-engineering the patch format and implementing a parser. Ultimate goal is a working ApplyPatchToFile() implementation.
  • A way to create new patch files (i.e. mspatchc.dll / mpatch.exe) could also be useful.

Testbot ideas

See the Wine Test Bot site and the source at tools.git

Javascript-ification of the site

Possible mentors: François Gouget

Knowledge prerequisites: Perl (server side), JavaScript, REST or equivalent

The goal would be to avoid reloading pages all the time, starting with the Job details page and moving on to other pages if time permits.

  • A prime target would be the job details page which reloads every time one shows / hides a log or a screenshot. Dealing with screenshots should be easy. The interesting part would be to have the website provide an API to retrieve the logs which the JavaScript code would then insert in the right place, taking into account that logs are not available until a task has completed. Also, instead of reloading the whole page regularly, the JavaScript code should query for changes to the Job status and update the page accordingly.
  • Similarly, instead of reloading all of the main page regularly, JavaScript could be used to retrieve just the new jobs and status changes, and then update the page.
  • The job submit page could also use JavaScript to have all operations happen on a single page and make uploading the patch / executable smoother.
  • Finally, refreshing the activity page could benefit from a similar treatment to the main page.
  • Note: As part of this project you will have to set up your own TestBot instance, that is the Engine, webserver and a QEmu VM.

Swap TestBot's Object Relational Mapper

Possible mentors: François Gouget

Knowledge prerequisite: Perl, SQL

  • The TestBot uses its own Perl ORM implementation which has a lot of issues: Bug 45023
  • These issues are currently not blocking the TestBot development but the performance is pretty bad: see for instance the load times for the main and activity pages. It seems likely that the current ORM is responsible for the poor performance.
  • So the goal of this project would be to switch the TestBot to a standard ORM, one with better performance and that does not need to be maintained as part of the TestBot codebase.
  • The first task will be to pick a replacement Perl ORM based on functionality, community support and performance. The next point can help for that last part.
  • To test the performance aspect, the project can convert access to the Records and RecordGroups tables since they are isolated.
  • The difficulty with the switch is that the rest of the TestBot's tables are all connected together: in $Task->VM the ORM takes care of returning the appropriate VM object for the Task, which would not work if the Task and VM tables are accessed using different ORMs. So an important part of the project will be to figure out how to handle the transition.
  • Note: As part of this project you would have to set up your own TestBot instance, that is the Engine, webserver and a QEmu VM.

Implement load balancing and fail-over

Possible mentors: François Gouget

Knowledge prerequisite: Perl, SQL

Difficulty: Hard

See Bug 39412 This implies:

  • Currently a VM, such as a Windows 7 VM, can only be present on a single VM host. If that host goes down, the corresponding tasks cannot be run: there is no fail-over. Similarly if the VM host is busy running other VMs, the task cannot be moved to a less busy host: there is no load balancing. The goal is to change that to improve the reliability and performance of the TestBot.
  • In the current schema a Task is associated to the VM that it will run on. However that model will need to be expanded:
    • We can already have multiple test configurations for a single VM. This is done by having one VM snapshot per configuration, for instance one per locale. Since there is a single VM, only one configuration can be tested at a time. This is currently represented as separate VM objects and it's up to the task scheduler to detect when two objects reference the same VM and thus to not try to use both at the same time. The new schema should probably find a better way to represent the relationship between the tasks, test configurations and VMs.
    • The VM object specifies the hypervisor instance, and thus VM host, used to access it. If a VM is present on multiple VM hosts it's possible to create one VM object for each. However since Tasks link directly to VMs, once created a task would be linked to the VM instance on a specific VM hosts, thus preventing failover. So a better are of representing the relationship between the tasks, VMs, VM instances and VM host / hypervisor is needed.
    • The new schema will also need a way to represent licensing restrictions. The TestBot typically has a single license for the Windows VMs, which means at most one instance can run at a time, even if the VM is present on two hosts. But the TestBot should be able to run two or more instances of the Linux-based VMs simultaneously.
    • While allocating hypervisor resources for specific VM instances is not part of this project, the new schema should be extensible so one can represent the hypervisor resources and the corresponding VM requirements.
  • So the project will need to:
    • Update the database schema to account for the above requirements.
    • Provide SQL code to update the existing tables.
  • Update the code impacted by the schema changes (essentially everything).
  • Update the task scheduler to implement fail-over and load balancing.
  • Note: As part of this project you would have to set up your own TestBot instance, that is the Engine, webserver and a couple of QEmu VMs.

Unsorted further ideas

Further cmd.exe improvements

Further work on the cmd.exe implementation. We need to scope / find out what is missing before offering.


Fix Windows theming / implement themes

After we fix Windows theming in Wine (project 1) we could implement themes (project 2).


Improve Wine's fonts

Improve our own fonts and/ or add new fonts. (This is not for GSOC usually, more for Outreachy)


Improve accessibility of Wine

Wines accessibility for e.g. blind people is lacking and can use improvements.


winetest improvements

Improve the server and/or client side of the wine test framework. (?)


signtool.exe

A tool to verify signatures on MSI packages / EXEs(?)

(Need to evaluate if effort matches GSOC effort scope.)


tasklist.exe

A tool to list currently running programs.

(Need to evaluate if effort matches GSOC effort scope.)

See, e.g., https://bugs.winehq.org/show_bug.cgi?id=43990


DPI Resolution handling

We have some DPI resolution issues, some work in this area is needed.


DirectPlay

Is there any work needed on DirectPlay... Identify missing things.


Common Item Dialog Box improvements

Ask Vincent Povirk about details / ideas.

Improvements of this dialog box framework.


Improvements of specific Windows applications

Hard to scope the effort for specific applications beforehand to meet the GSOC effort range.

(brainstorm: Perhaps select some "known" apps that might be in the range?)


Tools - implement a wine diagnostic tool

Collect data about the current installation that can be used for AppDB or bugreporting. Things like wine version, operating system, native dlls versions, etc.