My Experience Contributing to The WINE Project

Working on something as complex as WINE is not easy, and I’ve learned to be more patient, and now, appreciative of the patience of other maintainers of the project. This article does get quite technical, and I assume the reader has some understanding of this field, especially Microsoft’s COM standard, a kind of ABI, which is older than I am.

In case you don’t know what WINE is, it’s a compatibility layer for UNIX systems, namely, GNU Linux and macOS which has garnered a lot of attention because it’s a vital part for playing video games for Windows. Combined with the related DXVK libraries and the Proton distribution by Valve software, we are seeing popular titles now working on Linux.

Just quickly, DXVK translates DirectX family of API calls, specifically Direct3D, into Vulkan API calls. DirectX was an incredibly important piece of software made to ensure that Microsoft had market dominance in multimedia for Windows and the Xbox. It’s a family of API’s, with Direct3D being the most prominent, next to Direct2D.

Importantly though, WINE is used to run more serious, business style applications, and it’s incredible how much stuff works, and, compatibility is still improving. But, Windows is a huge operating system in terms of how much code it contains, that it dwarfs WINE in size. It has only grown over the years, and there are features going back to Windows Vista that still haven’t yet been replicated in WINE, mostly because many of them aren’t that important, as the usability or experience isn’t affected too badly by not including them. I made changes to improve the user experience.

Working on this was not easy. Writing code in C89 required care, and adding controls to the UI can be long-winded. It took me longer still to figure out how to convert a string to a PIDL, but as you can see below, I used GetFolderByName and GetIDList to try and match the string against a known folder name, such as “Trash”, or if that fails, use SHParseDisplayName, which, through trial I found only works on filesystem paths.

Git History for dlls/comdlg32/itemdlg.c, displayed in CLion

Those changes were based upon some test code I had written and built on Windows 10 with MSVC. In fact, the main test program I used for testing the common item dialog was also built with MSVC, because I found it easier, and cross compiling with MinGW failed because their headers were incomplete.

This is just some of the changes I’ve made. You can see more of them on my merge request:

Hopefully my changes will get merged in, pending the approval of the maintainers, users will notice a small improvement. In any case, I learned new things, and gave back to an opensource project that I’ve benefited from.

Leave a Reply

Your email address will not be published.