View source for Summer Of Code

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

* Do you:
** Know [http://kegel.com/academy/tutorials.html C]?
** Perhaps have done some Win32 low-level Windows programming already (below MFC)?
** Have an idea to improve Wine and make it more useful and popular?
** Perhaps improve a specific application to run under Wine? (it however needs to be predictable ahead in scope for Summer of Code)
** 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:
** 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
** 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]
** 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.
* Note: Applicants '''MUST''' have submitted a patch or testcase to wine-patches (see http://wiki.winehq.org/SubmittingPatches) to be considered for acceptance.
To apply, go to the [https://developers.google.com/open-source/gsoc/ 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 [http://en.wikipedia.org/wiki/Software_Freedom_Law_Center SFLC]'s advice)
* '''You are not allowed to reverse engineer Windows files by disassembling or decompiling them'''
* '''You are not allowed to analyze Windows files with the trace functions of Wine'''
* '''People who work or have worked for Microsoft should probably not participate'''
-----

== Ideas ==
=== Your own idea ===
Possible mentors: We'll provide you with the appropriate mentor

* If you have an idea, please post it on [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.


----
=== Implement ping.exe ===

(We could also forward to ping.exe ... ) Might not be doable.

----
=== Fix Windows theming / implement themes ===

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

----
=== Improve Wines 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.)

----

=== Calculator ===

Implement a calc.exe.

----
=== 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?)

----
=== 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 ===
Possible Mentors: [[User:AndreHentschel|André Hentschel]]

Knowledge prerequisite: C

Difficulty: Easy

* 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

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

* [[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
** 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.

----
=== Direct3D - Automated game benchmarks ===
Possible Mentors: [[User:StefanDoesinger|Stefan Dösinger]]

Knowledge prerequisite: Autohotkey, knowledge of common game engines

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.

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.

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.

----
=== 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 ===
Possible Mentors: We'll provide you with the appropriate mentor

Knowledge prerequisite: C, CMD commands

Difficulty: Medium

* http://kegel.com/wine/sweng/2010/ is a project to fix a number of small bugs in Wine's cmd.exe and friends, and to write testcases for it. It has helped bring to light certain flaws in cmd.exe's parsing of if/then/else and () blocks.
* Somebody could quite usefully spend a summer bulking up the test cases for cmd and friends, fixing any remaining reported bugs, and improving the parser.
----
=== Portability - Port WineLib to a new architecture ===
Possible mentors: [[User:AndreHentschel|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: [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].
* You will also need a test system. Qemu should be possible.
----
=== Implementing XACT sound dlls ===
Possible mentors: [[User:AndrewEikum|Andrew Eikum]]

Knowledge prerequisite: C

Difficulty: Medium

The goal here is to implement a subset of the Microsoft Cross-Platform Audio Creation Tool dlls, also known as xact. There are a few sections (xactengine, xaudio, x3daudio, 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.

----
=== WineCE: Implement the CommandBar ===
Possible mentors: [[User:AndreHentschel|André Hentschel]]

Knowledge prerequisite: C

Other prerequisite: ARM device with Linux or some Qemu experience

Difficulty: Medium

* WineCE targets to support Windows CE applications, an huge update to revive it will be pushed soon.
* This is an out-of-tree project, but obviously still related to Wine.
* The goal is to implement [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.

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: [[User:NikolaySivov|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.

=== 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: [[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.

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 Unicode string normalization ===
Possible mentors: 

Knowledge prerequisite: C

Difficulty: Medium

Unicode string normalization handles transformations between composed and decomposed character forms. Windows exposes this functionality with NormalizeString and IsNormalizedString functions.

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.


[[Category:Development]] [[Category:Summer of Code]] [[Category:ToDo]]