Pages

Showing posts with label development. Show all posts
Showing posts with label development. Show all posts

Tuesday, January 22, 2019

Working on Wine Part 6 Sending Your Work Upstream

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide


This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

  • Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
  • Part 2 describes Wine's build process.
  • Part 3 describes how to use Wine as a developer.
  • Part 4 describes how to debug Wine in general.
  • Part 5 describes Wine's source tree layout and how to edit the source.
  • Part 6 describes how you can send your work upstream.

If you recall from Part 1, there are many forks of Wine. Where your fix belongs can vary depending on what fork of Wine you use, the nature of the bug you fixed, and how you fixed it.

 

 

Choosing the right place to send your fix


The ideal place for your fix is in upstream Wine. This is the origin point of all Wine forks. If you fix it in upstream Wine, then all users of Wine will eventually benefit from your work as the various forks pull in changes from upstream.

Sending your fix upstream should be the default choice for your work. If none of the exceptions below apply, or if you're unsure where your fix belongs, work with upstream first.

 

When upstream is the wrong choice


Your patch may be built on top of an existing patch in wine-staging. In that case, it should be sent to the wine-staging maintainers. If you, or they, think that the patch is ready to be sent upstream, then go ahead and do that instead.

If your patch fixes the issue, but you failed to fix the tests you wrote, or your patch causes some other test failures, it may belong on the bug tracker, or possibly in wine-staging.
If your patch provides a useful feature that upstream Wine is not interested in, it may belong in wine-staging.

If your patch is builds on a feature exclusive to some fork of Wine, like Proton or CrossOver, it may belong in that fork and not upstream. Work with the fork maintainers to determine if it's appropriate for upstreaming.

 

Upstreaming your fix


Hopefully, your patch is going upstream. Wine's patch submission process is done via email. Your patch should be sent in plain text to wine-devel@winehq.org. You should subscribe to this mailing list to avoid being placed into the moderation queue.

It is recommended to use git send-email to send the email through your mail server. You can also use git format-patch and attach the resulting file in an email client. Be careful that your mail client doesn't wrap, or otherwise corrupt, the attachment as if it were a text document.

Patches that are sent upstream should have your Sign-off. This can be applied by Git automatically with the -s switch during git commit and/or git format-patch. You must use your real name in the Author field when submitting a patch.

If you are submitting a series of patches, try to limit yourself to about four patches per submission. Your patches should be self-contained anyway, so there is no harm in submitting them in several batches. Smaller patch series are easier to review, and keep from cluttering up the mailing list if you have to re-send the series with changes.

 

Receiving feedback


Wine has a patch status webpage which will track the status of your patch. Your patch will be tested by the Wine Test Bot to ensure any new tests pass on various Windows versions. If the area of Wine changed by your patch has a maintainer, it will be assigned to that person for review. If not, it will be reviewed by the general community, or by the Wine maintainer.

Be patient, it may take a few days for your patches to receive review. Wine reviewers try to reply to every patch within a week, but if you don't get feedback you may send an email to wine-devel asking for a review. Be sure you are subscribed to wine-devel, as some reviews may be sent to that mailing list instead of directly back to the author.

If you received some suggestions, take those suggestions into account and send a new version of the patch. Feedback from Wine reviewers should not be seen as criticism or an attack. Wine is a very complicated piece of software, and it has a high standard of code quality for contributions. Rejections aren't made lightly—everyone wants Wine to improve. Instead, understand that there are reasons for the rejection, apply the suggestions, and resend the patch. If you do not have the time or interest in making the requested changes, consider sending your patch to wine-staging so some other person may take up the patch in the future and try to get it upstream. Or, attach it to a Bugzilla bug so it is not lost.

If your patch is accepted, then congratulations! You have just made Wine better. It's time to move on to the next bug.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

 

Thursday, January 17, 2019

Working on Wine Part 5 Fixing Wine

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide


This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

  • Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
  • Part 2 describes Wine's build process.
  • Part 3 describes how to use Wine as a developer.
  • Part 4 describes how to debug Wine in general.
  • Part 5 describes Wine's source tree layout and how to edit the source.
  • Part 6 describes how you can send your work upstream.

Once you've got some idea of what is causing the problem with your application, it's time to go understand how those APIs are implemented in Wine so you can fix it. You may also need to change Wine's code to debug the application in the first place.

 

Search for existing bugs


Before digging into the source, it's always useful to first search for existing bugs. You can search Wine's Bugzilla for your application, or for the symptoms you're seeing. As you begin to debug your issue, you may find other search terms to try. If you find a bug, you may find some useful analysis or work has already been done for the issue.

You may also want to look through the Wine Staging patches, especially once you have some idea of what the problem is. You may find someone has already written a patch to fix this problem, but it isn't ready to go upstream yet. You can pick up the torch and try to upstream the work.

 

Wine source layout


Wine implements the Windows operating system, which is composed of libraries, programs, and kernel functionality. You can find the code for Wine's implementation of each of those components in dlls, programs, and server, respectively. To give you some idea of how different components of Wine work together, some important, core components are listed here.
  • dlls/ntdll – This is where many of the core OS APIs are implemented, like file handling, thread creation and synchronization, timing, and much more. Applications typically use kernel32 instead of ntdll directly.
  • dlls/kernel32 – This is the application-facing interface for the core ntdll APIs mentioned above.
  • dlls/user32 – This is where much of the Windows GUI handling lives, like window creation, message handling, terminal services, and so on.
  • dlls/winex11.drv and dlls/winemac.drv – These libraries map the Windows GUI interfaces, and some other platform-specific functions, to the native platform. user32 calls into these platform drivers.
  • dlls/d3d* and dlls/wined3d – These libraries implement the Direct3D graphics API on top of the platform's OpenGL implementation.
  • programs/services – This program manages background services, both those created by Wine and those provided by installed applications.
  • programs/wineboot – This program kicks off initial prefix creation and other tasks when a prefix is booted.
  • programs/winecfg – This is Wine's configuration program.
  • server – The Wine server implements all cross-process functionality, including message routing, multi-process synchronization primitives, registry handling, and much more. The Wine server is always running if an application is running.
While debug channels are often named after the component in which they are declared (e.g. the dsound channel is declared in dlls/dsound), this is not always the case. You can use git grep to find the relevant debug trace line if it isn't obvious.

 

Writing tests


In most cases, your work should be driven by tests. Study the documentation for the relevant APIs and write tests first to confirm that Windows's implementation behaves how you expect it to. Then, change Wine's source to pass the tests that you wrote.

Wine has an extensive suite of unit tests. The unit tests comprise well over one million lines of code as of this writing. Any patch you submit must pass all of these tests. Patches should contain more tests proving that the new behavior is correct.

In general, you should focus your work on what a real application actually does. That is, you don't need to implement a bunch of unrelated functionality if the application doesn't actually need it. You should write tests to show how an application is using an API, and how Wine fails to meet its expectations. Then fix Wine to also pass those tests without breaking any existing tests. Any change to Wine has the potential to break other applications. Simply passing tests that you wrote is insufficient reason to change Wine.

You can find the tests for a given component in the tests subdirectory. For example, the tests for dsound live in dlls/dsound/tests. You will find .c files in that directory. The tests start in the START_TEST function and exercise the component being tested. The ok function demonstrates correct behavior. Again, "correct" is defined to mean "like Windows." For example:

    hr = IDirectSound_CreateSoundBuffer(ds, &bufdesc, &primary, NULL);
    ok(hr == S_OK, "CreateSoundBuffer failed: %08x\n", hr);
 
Here you can see the return value from IDirectSound::CreateSoundBuffer is expected to be S_OK. If it is not S_OK, then the test will fail.

Your tests should demonstrate how your application behaves when interacting with that API. Since you are fixing a bug in Wine's implementation of the API, your tests should demonstrate that Wine will fail without your fix. It isn't necessary, or even recommended, to fully exercise all inputs to an API in the Wine tests. Instead, be thoughtful about how your application might use the API given different inputs from the user, and write tests that reflect those possibilities.

Your tests should be self-contained. They should initialize the necessary functions, test the APIs, and then clean up before continuing. If you need to create files on disk, create them in a temporary location and/or clean them up afterwards. If your test may leave changes to the system, expect to have to clean up after a previous run that crashed, before you run your tests.

After you have written some tests, you need to verify that they pass when run on Windows. To do this locally, run make crosstest, which will use your system's mingw-w64 compiler to build a Windows executable. Run this executable on Windows in the command prompt to verify Windows's behavior. If you do not have a Windows system or VM available, you can upload your patch or test binary to the Wine Test Bot.

Once your tests pass on Windows, run them in Wine with make test. If your tests meaningfully demonstrate a Wine bug, they should fail. Now it is time to fix Wine to pass those tests, as well as all existing tests.

 

Working with Wine's source


As you develop your fix, there are some rules you should know if you intend to send your work upstream.

For better or worse, Wine does not have a coding style standard and likely never will. The rule is to try to match the surrounding code as best as possible. Especially in older code, you will find a horrible mish-mash of tabs and spaces and brace styles. Do your best to make the code no worse than it was. However, extraneous changes are discouraged as they make review difficult and looking up the source history in Git more cumbersome. If you are changing a line, or even one line in a short code block, it can be re-formatted to be less ugly than it was. But don't reformat an entire function to fit some style, no matter how ugly it is.

Wine only accepts code that adheres to the C89 standard, because some compilers that Wine cares about don't support anything later. The three most common snags here are that your code must declare its variables at the top of the block, you cannot use //-style comments, and function declarations with no arguments must be declared with void arguments:

    int some_function(void);
 
Resist the urge to gut an entire function or module and re-write it. Small, discrete changes that can be easily understood are the right way to fix Wine. Wine is more than two decades old. There is a lot of hard-won knowledge in much of Wine's source, and throwing out all of that history because it's easier than working in the existing code is not likely to pass review.

Make your changes as obviously correct as possible. Unrelated changes must be placed into their own commits. You should not introduce unused code in an early patch, which begins to be used in a later patch.

Write your patches with the reviewer in mind. It may be unintuitive, but understand that it is more important for your patch to be easy to review than make Wine's code perfect. Reviewer time is one of Wine's most valuable assets. Patches that are easier to review are more likely to pass that review.
Be aware that some tests are "flaky." This is an unfortunate reality of a system as complex as Wine. Ideally all tests would pass on all Windows and Wine environments, but due to bugs, differing platform behavior (especially window managers) and timing differences, they don't. Most modules have well-written tests that should always pass. Some, like the user32 messaging tests, and some audio and graphics tests, fail with some frequency, even on Windows.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Tuesday, January 15, 2019

Working on Wine Part 4 Debugging Wine

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide


This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.
  • Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
  • Part 2 describes Wine's build process.
  • Part 3 describes how to use Wine as a developer.
  • Part 4 describes how to debug Wine in general.
  • Part 5 describes Wine's source tree layout and how to edit the source.
  • Part 6 describes how you can send your work upstream.
If you've made it this far, then you should have a functioning Wine build and an application installed that has some problem that you want to fix.

Debugging Wine is unlike debugging an application or even most open source libraries and software. As a Wine developer, you typically don't have access to the source of the application. So you have to be able to guess at what the application is trying to do, and then figure out why Wine is failing to meet its requirements.

Applications are often debugged with debuggers, but this is of limited use with Wine. A lot of time is spent in application code, which isn't useful to us, or in OS library or kernel code, which is also often not useful to us. Wine is just the go-between from application code to library or OS code, so debuggers tend to spend a lot more time out of Wine code than in it. Problems in Wine are also often less about bugs than they are missing features. Debuggers don't help here.

 

WINEDEBUG


Instead, most Wine debugging is done with printf-debugging. Wine developers have introduced copious logging into the libraries. When you run an application with these debug traces enabled, it will spit out large quantities of information about how the application is using the library.

You enable these logs with the WINEDEBUG environment variable. This variable takes a comma-separated list of debug channels. While it has a more complicated syntax than this, usually you just enable channels entirely. For example, to debug a networking issue, you might start with:

    $ WINEDEBUG=+seh,+winhttp,+winsock,+wininet ~/src/wine.win64/wine Steam.exe
 
This will emit a ton of output on stderr. Usually you redirect to a file:

    $ rm -f out.txt && WINEDEBUG=+seh,+winhttp,+winsock,+wininet 
~/src/wine.win64/wine Steam.exe &>> out.txt
 
Notice that the redirect is in append mode, to allow for more readable multi-threaded logging. This requires that we delete any old log file first.

This is the basic Wine debugging loop. Run the application with logging enabled, demonstrate the failure, examine the log, add more logging if necessary, and repeat until you understand the problem.

 

Debugging channels


Wine trace logs have four "severities," called TRACE, WARN, FIXME, and ERR. TRACE is just general debugging, and is silenced by default. WARN indicates some suspicious, but non-fatal condition and is also silenced by default. FIXME indicates some missing feature of Wine and will be printed by default. ERR indicates a serious problem and will also be printed by default.

Wine lets developers output logs on specific channels. These are declared in the C source files with WINE_DECLARE_DEBUG_CHANNEL and WINE_DEFAULT_DEBUG_CHANNEL. Grepping the C files for DEBUG_CHANNEL works great.

It's not always easy to determine which log channels are useful to trace. If you know what general area your problem is in, you can add channels from the relevant Wine libraries. If you don't have any idea, then a log with just +seh is a decent starting place to dig for fixmes and errs.
There are some special debugging channels.

tid and pid will prepend each log line with the Thread ID and Process ID that outputted the log line. tid is enabled by default in recent Wine.

relay will output every API entry point that the application, or other parts of Wine, make a call to. This is extremely verbose, but can be very valuable, especially if you don't know where the problem lies.

timestamp will prepend every log line with a millisecond-resolution timer. This is great if you can estimate when in the log the problem occurred, or are working with timing-sensitive code like audio.

 

Working with log files


Most WINEDEBUG logs will grow to hundreds of kB and MB of plaintext. Logs of multiple GB are not uncommon, especially relay logs. Many GUI text editors will not handle files of these sizes very well. An editor like vim is recommended.

You should also get familiar with tools like grep, head, and tail to pare log files down to manageable chunks. In particular, grep -v can get rid of uselessly repetitive log lines.
When encountering a new log, a good first step is to grep for err:, warn:, and fixme:. These can indicate problems. You'll likely get a lot of fixmes and probably some warns. If you're getting messages from areas unrelated to the problem you're examining, you can usually ignore them. For example, fixmes from the d3d channel are probably unrelated to a problem with audio.

 

Log file techniques


One generally useful technique is to find the problem and then search backwards. For example, bad pointer dereferences are a common failure. These can be found in a +seh log by searching for c0000005. Once you've found the failure in the log, you can start going backwards and if you're lucky, find some fixme or err indicating a missing feature. Or in a relay log, you might find some API that is returning a failure, like a bad HRESULT instead of S_OK.

If you don't have an obvious crash point, you can also try to find where in the log things start to go bad. For example, most applications follow a pattern of loading libraries, initializing stuff, normal application processing, then uninitializing stuff and unloading libraries. If you have an application that is quitting unexpectedly, you can search for when shutdown-related code is happening and then start going backwards to try to find the culprit.

If you have an application that fails on some specific input condition (say, clicking on some UI element), you can actually write to the log at the same time that Wine is. While Wine is debugging, run:

    $ echo '@@@@@@@@' >> out.txt
Then perform your action and observe the failure. Then run it again:
    $ echo '########' >> out.txt
Now you know the failure occurred between the at-symbols and the hashes.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Thursday, January 3, 2019

Working on Wine Part 1 The Wine Ecosystem

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide


This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.
  • Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
  • Part 2 describes Wine's build process.
  • Part 3 describes how to use Wine as a developer.
  • Part 4 describes how to debug Wine in general.
  • Part 5 describes Wine's source tree layout and how to edit the source.
  • Part 6 describes how you can send your work upstream.

 

What is Wine?


Wine is an open source reimplementation of Microsoft's Windows operating system on top of various Unix operating systems. It primarily targets Linux and macOS, but can also be run on other systems like FreeBSD, NetBSD, and Solaris. What this means for users is that they can run software that was made for Windows on other operating systems.

Wine does not contain any Microsoft-owned code, so there is no need for a Windows license to run Wine. Instead, the Wine developers have rewritten components of the Windows operating system such that software run in Wine will think it is running on Windows, even though it is actually running on Linux, for example.

As a simple example, consider the Windows CreateFile API. On Windows, an application could call:

    CreateFileA(
        "C:\\some_file.txt",   //lpFileName
        GENERIC_WRITE,         //dwDesiredAccess
        0,                     //dwShareMode
        NULL,                  //lpSecurityAttributes
        CREATE_ALWAYS,         //dwCreationDisposition
        FILE_ATTRIBUTE_NORMAL, //dwFlagsAndAttributes
        NULL                   //hTemplateFile
    );
 
Wine will take that CreateFileA call and turn it into a Unix open call:
    open(
        "/home/aeikum/.wine/drive_c/some_file.txt", //path
        O_WRONLY | O_CREAT,                         //oflag
        0644                                        //creation mode
    );
 
The file handle will be returned back to the application, which can then write to the file with a similar implementation mapping WriteFile to Unix's write. Of course the actual implementation of CreateFileA in Wine is far, far more complicated than this (consider the path conversion, for example), but this gives you the gist of what Wine does.

Wine Forks


Since Wine is an open source project, anyone is free to make copies of it and modify it to suit their needs or the needs of their users. There are hundreds of Wine forks, but a few of them have gained prominence and are described here.

"Upstream" Wine


Website: https://www.winehq.org/
This is the "official" version of Wine, from which all other forks are derived. When someone refers to "Upstream" Wine, they are talking about this project. Wine is primarily focused on correctness. Wine contains extensive unit tests which demonstrate the behavior of Windows, and requires that most patches provide tests. All patches must pass the existing tests to be accepted. There is also a strong focus on code quality. Wine is a very large project (it is literally an entire operating system, including a GUI), so technical debt is strongly avoided to keep the project maintainable going forward.

Wine Staging


Website: https://wiki.winehq.org/Wine-Staging
However, Wine's strict patch acceptance requirements means that lots of patches that are unproven, wrong, or dangerous, but useful for users today, would languish in private forks or on the bug tracker. The Wine Staging project (also spelled "wine-staging") is an attempt to gather and maintain these useful patches so users can easily take advantage of them. The Wine Staging community also works to upstream these patches into Wine, so their benefits become available for all Wine users and forks, while also lowering Wine Staging's own maintenance burden. It can also serve as a "testing grounds" for patches which are difficult to prove with unit tests before they are accepted upstream.

CrossOver


Website: http://www.codeweavers.com/
CrossOver is a commercial fork of Wine sold by the CodeWeavers company. It contains many patches that are application-specific hacks and not appropriate for upstreaming. CodeWeavers also maintains an application compatibility database which will pre-install some software components and otherwise modify the Wine environment so that certain applications work better. However, CodeWeavers strongly prefers to implement features correctly and send that work to upstream Wine. CodeWeavers employees perform a significant portion of the work done on Wine.

Proton


Website: https://github.com/ValveSoftware/Proton/
Proton is a fork of Wine created by the Valve software company, which is integrated with their Steam software, a major video game and software distribution platform. Proton is focused on providing a seamless experience for Steam users to run Windows titles on Linux. Like with CrossOver, most of the contributions to Proton are also sent to upstream Wine.

Other forks


There are many, many other forks of Wine. Some are packaged with commercial software and sold as macOS and Linux software. Others are one-off forks created by users for a specific application.

Developing for Wine


Wine isn't perfect, and it's likely you will run into an inadequacy or a bug in your day-to-day Wine usage. Perhaps you are interested in fixing Wine so it will run your application or game, or maybe your employer would like to use Wine and pay you to fix it. This guide will introduce you to how you can build, debug, and fix Wine, and how to send those fixes upstream.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Monday, November 2, 2015

Wine 1.8 code freeze and Pulse Audio Driver coming soon

Alexandre Julliard WineHQ Wine maintainer sent a message to the wine-devel mailing list outlining the Wine 1.8 code code freeze schedule and possible release in time for Christmas 2015. Below is a copy of the email Alexandre sent, I would like to see the Pulse driver included in Wine 1.8 as well...

Folks,

We've decided at WineConf that there would be a code freeze and release every year in the fall. That means about right now...

However, there are a few things I'd like to get in first (*cough* Pulse driver), so my thinking is to do one more development release cycle, and start code freeze after 1.7.55. This should enable us to release 1.8 before the end of the year.

So if there are new features you'd like to get into 1.8, you have another two weeks...

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Friday, October 9, 2015

Wine 1.7.52 Released

The Wine development release 1.7.52 is now available.
What's new in this release:
  • Unicode data updated to Unicode 8.0.0.
  • Some implementation of the Web Services DLL.
  • More Direct3D 11 interfaces.
  • A few more functions in the C++ runtime.
  • Output standard glyph names in the PostScript driver.
  • Various bug fixes.
The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.

 Bugs fixed in 1.7.52 (total 99):

   5771  Problems with Settlers III films (exotic Indeo RIFF chunks like ##iv are not detected in wine)
   6416  wineps uses custom encoded fonts
   7873  ConceptDraw cannot load project files
   9009  JewelQuest crashes after starting
  14193  Monster Truck Madness 2 Trial: crash in msacm32
  17543  Halo 2 for Windows Vista installer shows empty html user interface (jscript parser fails to recognize 'objectid::eventname' style function declarations)
  17647  TA Demo Recorder doesn't work
  18265  SIAP 3.1 (Argentinian tax software) crashes when entering menus, saving data or trying to exit a module
  20105  Fujiprint/Fotokasten fails to update (msxml3 missing support for special characters escaping and DTD nodes)
  21670  Flying Model Simulator - hangs at graphics card detection
  22067  c2 crashes on exit
  22511  Baldur's Gate 2: only takes up part of top left corner of screen, not full screen
  26122  valgrind shows several uninitialized variables in mscoree/tests/mscoree.c
  26211  Dragon Age II Demo launcher crashes
  26216  Lylian: can't play videos (quartz can't handle the AVI file header correctly)
  26875  Desperados: invisible UI
  27312  Requiem: Avenging Angel - Black artifacts in the main menù
  27513  Lord of the Rings launcher: 'Log in' button corrupted without native gdiplus
  27526  Field of view spins uncontrollably after switching from menu screen in Half Life
  27739  Multiple D3D example applications crash on unimplemented function d3dx10_43.dll.D3DX10CreateEffectFromFileW (NVIDIA D3D SDK 10 Sparkles, DirectX SDK GPUSpectrogram)
  28097  gdiplus fonts test fails unless Times New Roman installed?
  28191  winetest: No usage in wineconsole
  29379  VB6 textbox right click menu does not work
  29609  League Of Legends game client crashes after champion selection (failure to resolve hostname)
  29646  Microsoft Wine Guide crashes after playing one video clip (string sent to MCIWNDM_SENDSTRINGA needs previous translation from 16-bit)
  30180  winecfg hangs on drive actions
  31580  'Create Your Own Model Railway' crashes at 65% preparation after clicking 'Start Game'
  31684  Crash in winealsa driver when exiting World of Warcraft
  31748  Space Pirates and Zombies (Steam): system crashes/freezes when closing the game
  31826  warning: implicit declaration of function ‘isatty’
  32181  linux/videodev.h header is deprecated and unavailable on newer kernels
  32234  Missing dependencies on static / import libraries
  32582  WideCharToMultiByte: incorrectly handling of user specified DBCS "default character"
  32726  Starcraft II fulscreen app is still drawn when Alt+Tabing in KDE
  32959  Warcraft 3: Minimizing problems
  33376  Stick soldier 2 crashes on startup
  33481  Solidworks crashes on mouse action after 1 minute
  33704  Naviextras Toolbox 3.18.1 crashes or hangs (multithreaded wininet connections/races)
  33777  Clamwin doesn't show drive letters in filenames
  33870  Occasional crash during ie7 install
  33877  SimCity 4 Deluxe 'AutoRun.exe' crashes when clicking 'install'
  33935  graphics.c: identical sub-expressions '!(types[i + 1] & PathPointTypeBezier)'
  34172  Failure to install MiKTeX 2.9
  34422  Wizardry 7 Gold - Crash on starting a new game
  34607  When quitting the first area in Oddworld Munch's Oddysee CD, the game crashes
  34608  The character's 3D model in Oddworld Munch's Oddysee lacks body parts
  34750  Eleusis Demo some landscape parts are black rendered
  35219  Wine builtin Internet Explorer fails to authenticate with certain websites (GnuTLS error: Rehandshake was requested by the peer)
  35553  Warhammer 40,000: Dawn of War II: does not start, crypt:CertCreateContext dwFlags not implemented
  35574  gdi32:fonts test_EnumFontFamiliesEx_default_charset() fails on Windows 7 in the Japanese and Hebrew locales
  35708  Dassault Systemes CATIA v5R19 installer passes unsupported UI level 'b-!' to msiexec
  35716  Oblivion Mod Manager file not found although file-select window shows file
  36032  Colin McRea Rally 2005 - graphic glitches on second run/carrier mode
  36060  Hawking Control Center driver installer tool crashes (SHRegCloseUSKey crashes on NULL key)
  36110  Drakan: screen flickers and graphics are distorted (Mac OS X only bug)
  36237  valgrind shows a leak in comctl32/tests/subclass.c
  36276  dxdiagn/tests/container.c crashes when run under valgrind
  36281  valgrind shows an invalid read in gdi32/tests/path.c
  36367  w95_answ.exe (16-bit app) crashes on startup on Mac OS X 10.9 (Mavericks)
  36422  valgrind shows several possible leaks in qcap/tests/qcap.c
  36571  valgrind shows some invalid memory use in shell32/tests/path.c
  36626  dxgi/tests/device.c crashes under valgrind on i965/mesa
  36637  wininet/tests/http.c crashes under valgrind
  36725  Audible Manager crashes immediately on startup
  36732  mscoree PATH environment setup contains a potential stack buffer overflow
  36743  rpcrt4 tests fail when using widl "-Oif" option
  36876  Incorrect check for bad points in draw_poly()
  37018  Viber crashes when trying to make a video call
  37301  MyPhoneExplorer 1.8.6 installer crashes
  37814  NotePad++ 6.x freezes/crashes when copying text
  38217  wininet/tests/http.c hangs under valgrind-3.11.0-SVN
  38380  OSX Wine64 compile hangs on /dlls/ntdll/relay.c with gcc4.9
  38397  World of Warcraft 3.3.5a in D3D mode does not launch after wine 1.7.40
  38456  valgrind shows several uninitialized variables in programs/reg/tests/reg.c
  38678  valgrind shows uninitialized value dlls/kernel32/tests/path.c:test_CheckNameLegalDOS8Dot3
  38728  valgrind shows uninitialized memory in dlls/user32/clipboard.c
  38779  Homeworld 2: unusually long loading time (with built-in msvcr70)
  38871  Homeworld Remastered crashes when starting a new game, needs msvcp110.dll._FDtest
  38915  valgrind shows uninitialized memory in kernel32/tests/time.c
  38992  Chile timezones not detected: Chile/Continental and Chile/EasterIsland
  39021  Valkyria Chronicles (Steam) runs without audio (needs native xaudio2_7.dll)
  39189  Ableton Live 9: Adding Electric/Bass/Wobble Bass instrument causes a crash on unimplemented function msvcp120.dll._DTest
  39190  Ableton Live 9: Adding Impulse/Backbeat Room instrument causes a crash on unimplemented function msvcr120.dll.fminf
  39192  Warhammer 40k: Dawn of War II – Retribution (Steam) needs msvcr80.dll._wctime32_s
  39198  Etherlords 2 demo installer receives an exception after start
  39205  wordpad: paragraph didn't be repaint after undo setting of alignment
  39214  Crazy Machines Elements crashes on unimplemented function x3daudio1_7.dll.X3DAudioCalculate
  39241  msvcrt:string fails in a mixed locale configuration
  39243  oledlg:main fails in the Korean locale
  39256  msxml3/tests/domdoc.c crashes under valgrind
  39273  Quicken 2004 doesn't install
  39277  Enhance error diagnosis for DX10/11 games crashing due to missing support for Mesa OpenGL >= 3.2 core profiles, Shader Model 4, GLSL 1.50
  39280  German manpage claims WINELOADER defaults to @bindir@/wineserver
  39287  Huawei HiSuite 2.3.55 installer crashes
  39320  Unrest doesn't exit properly (hangs on exit) with built-in Xaudio2
  39321  Unrest doesn't play audio with built-in Xaudio2 (needs xaudio2_7)
  39333  TERA client 2015.09.24 crashes on unimplemented function bcrypt.dll.BCryptCreateHash
  39334  comctl32 status bar test crashes on Linux if Bubbler One font is installed
  39361  WildStar Launcher2 crashes immediately after startup

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Thursday, September 24, 2015

WineHQ WineConf 2015 Group Photo

WineHQ WineConf 2015 Group Photo

From left top to right bottom: Sebastian Lackner, Aaryaman Vasishta, Austin English, Rosanne DiMesio, Ulrich Czekalla, Michael Stefaniuc, Henri Verbeet 

Aric Stewart, Piotr Caban, Jacek Caban, Caron Wills, Christian Inci, André Hentschel, Jeremy White, Alois Schloegl, Andrew Eikum, Huw Davies, Hans Leidekker, Robert (Focht)

Stefan Doesinger, Dmitry Timoshkov, Alexandre Julliard, Francois Gouget, Andrei Podoplelov, Nikolay Sivov, Michael Müller 

Marcus Meissner, Jactry Zeng, Qian Hong, Josh DuBois, Vincent Povirk, Józef Kucia, Matteo Bruni

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Monday, May 25, 2015

GSoC 2015 WineHQ projects

This is from the WineHQ developers mailing list.

Matteo Bruni 

Hey all,

tomorrow the coding period of the Summer of Code begins and I though it might be a nice idea to let the community know about the projects we've got this year. Actually, I though it would be even better if the student themselves wrote a short summary of their own project for the mailing list.

So, with no authority backing me, I'm kindly asking that. No need to write anything too fancy, just a few lines explaining what are you going to work on over the summer and maybe what are the expected benefits for Wine.

Thank you!

Aaryaman Vasishta

Hello!
Thank you for inviting me to this opportunity! I will try my best to keep it short, though it might be a bit long for some. There's a TL;DR at the end, though. :)
A bit about myself. My name is Aaryaman Vasishta and I'm currently studying in my third year of Computer Engineering in Pune Institute of Computer Technology, India. My interests lie in game programming and computer graphics.

My project focuses on implementing the rendering backend for the D3DRM API [1].

D3DRM (Direct3D Retained Mode) is basically a scene graph API running on top of Direct3D's Immediate Mode API. You can say it's more like a rendering engine API which encapsulates Immediate Mode functionality in order to make it easier for programmers to develop 3D scenes using it, making it a possible competitor to OpenGL at the time.

At the moment wine's implementation of this API is mostly full of stubs, and there's quite a bit of work left before something can be drawn on the screen. My role here mainly focuses on implementing object Creation/Initialization functions for some of the main interfaces, mainly devices, textures and viewports, all of which are COM based. If time permits, I will also work on implementing some frequently used frames and lighting functions.
The API is quite old (it has been removed since DX 8 SDK, and the dll doesn't come included with vista onwards) but there are a few popular games that used it. Namely, Lego Rock Raiders and Steel Beasts, and applications as well, like FMS (Flying Model Simulator). So there is some merit in working on this. Implementing these functions will help accelerate further development of this API to get some long-awaited apps to run on wine (I can see quite a few threads on google of people trying to get FMS running, and a couple for LRR too, so there is some demand for it). As an added bonus, I also get to interact with wine's ddraw implementation for this one, which could potentially help ddraw's implementation via possible bug detection/fixes and implementing any ddraw functionality that d3drm requires.


TL;DR: I'm implementing a main chunk of a graphics API called Direct3D Retained Mode, which is based on Direct3D Immediate Mode. The API is mostly a stub in wine and this project should help get things going.

Thank you!
Aaryaman Vasishta

Zhenbo Li

 Hello!

I'm glad to working on Wine GSoC this year. My project's focus is IHMLTXMLHttpRequest. Many websites would use hacks to determine whether the browser was IE6.0 or IE 7+. As XMLHttpRequest object identifier was shipped in IE 7.0[0], the web developers would use ActiveX to access IXMLHttpRequest object. Wine IE implements some new features, so it is common that Wine IE is treated as a IE 7+ browser(like Firebug Lite[1])

Mozilla has implemented nsIXMLHttpRequest[2], and my approach is to call the wine-gecko functions from wine code. I can't tell how many applications' status on appdb will change from "garbage" to "silver/gold", but IMHO, implementing XMLHttpRequest is necessary to make wine IE more usable.

Thanks

 Iván Matellanes

 Hi all!

I'm looking forward to contributing to Wine.
My project consists on implementing part of the legacy Visual C++ iostream runtime, which was shipped with Visual Studio versions up to 6.0 and is currently a stub. I'll work on as many functions as time permits, and one of the key points is to reuse code from the modern Visual C++ runtime library that is already implemented.

Some old applications and games (like MS Reader and Tron 2.0) would benefit from this, as they would run with the built-in library. A quick search on Bugzilla for 'msvcirt' shows several bugs related to unimplemented functions.

Cheers,
Iván.

YongHao Hu

 Hi, all.

Sorry for the late reply. I am happy to join this discussion.

My project focuses on implementing all the functions from tr2 namespace, which was included in the header and being proposed for standardization. Though there are many methods to implement the functions like _File_size and _Equivalent etc, the hard part is finding the most appropriate one.

New applications like MSVC12[1] would benefit from this.


Thank you!

-----

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.