Ospp Summer Code

From WineHQ Wiki
Revision as of 02:03, 15 May 2021 by Zhenbo (talk | contribs) (Page Order, Suggestions)
Jump to: navigation, search


Summer 2021 of Open Source Promotion Plan (OSPP) is jointly organized by Institute of Software Chinese Academy of Sciences (ISCAS) and openEuler community. OSPP Summer is very similar to Google Summer of Code (GSoC) and Outreachy.

OSPP opens to all projects with OSI-approved licenses, and worldwide students. When students finish their projects, both students and mentors will be paid. OSPP committee will process international wire transfers if needed.

Student Guide

LEGAL REQUIREMENTS

You must state that you will follow these minimal legal requirements :

  • 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

For more information, please read Developer_FAQ#Copyright_Issues, Clean_Room_Guidelines

How to Apply

  1. Introduce yourself on the wine-devel mailing list
  2. Discuss your ideas with other wine developers
  3. Submit your final proposal on OSPP Summer portal

Suggestions

    • Have a look at the developers page on the wiki and grab Wine's source code, try to get acquainted with it
    • Look at Previous Summers Of Code for previously accepted proposals / their results
    • It's encouraged to propose more than one idea. But only one proposal will be accepted per applicant.
    • HIGHLY RECOMMEND applicants submit a patch to wine-devel (see Submitting Patches). It can be a stub dll or adding a test case. We want you be comfortable with Wine's Git Workflow.

Differences With GSoC

  • OSPP is providing three different levels, with different awards. That might make it easier to find projects/students. If an idea is interesting but too easy for GSoC, it might be suitable for OSPP summer with medium/low difficulty.

Projects

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. Showing initiative and willing to discuss your idea greatly improves your chances of getting accepted.
  • 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.
  • Don't be afraid that you don't have a perfect idea - take advantage of the time before the proposal deadline.

Implement keyboard shortcut support for Datetime Picker Control

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

The idea is to add support of all/some of the keyboard shortcuts mentioned in this MSDN page, so that we can select a day by the keyboard.

Wine bug 50511 will also benefit from this work.



Fix Tests on Your Windows Machine

Possible mentors: Depends on the libraries you pick

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

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

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

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


Upstream changes from winevdm

Possible mentors: Stefan Dösinger

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

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

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


Improvie HiDPI support

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

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


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

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

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

AVFoundation video capture support

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

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

DirectShow audio capture

Possible mentors: Zebediah Figura

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

Implement robocopy.exe

Possible mentors: Zebediah Figura


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.


Brain Storming

Please feel free to drop immature ideas here. It's okay if you post an idea here while you're not participating as a student/mentor. It may be the start of some high-quality discussion


Coordinator

Zhenbo Li
IRC: @zhenbo:matrix.org
Email: litimetal -at- gmail dot com


Austin English
IRC Nick: austin987
Contact: austinenglish -at - gmail dot com


Name: André Hentschel
Email: nerv -at- dawncrow -dot- de
IRC: Andre_H