Interviews

Francois: I first learnt about Wine in 1995. I was relatively new to Linux and felt that it was a shame that one could not run Windows applications on Linux. Also, at the time I was porting a Unix application to Windows NT for work and it seemed like it would be interesting to compare these two aspects.

But at the time Wine did not support Win32 very well and I never managed to find time to either really use it or contribute to it. Then near the end of 1998 I came back to it and tried to compile some Windows applications with Winelib.

Francois: I only had access to the application (Emeraude PCTE) at work, and to Linux at home. So I did not get a chance to try porting it to Linux. But the application had been ported to many Unix platforms before (SunOS 4, Solaris, DEC OSF/1, HP/UX, etc.), so I'm sure it could have been ported to Linux as well.

Francois: I completed the port to Windows NT (3.51 initially) and then to Windows 95. There are different ways to explain what Emeraude PCTE is depending on whether you grab the trunk or the ear of the proverbial elephant. For me PCTE was an extension of Unix, with a very sophisticated, typed, distributed and transacted file system. Others would say it was a repository or an object database and they would be right too. So you could use esh (the equivalent of bash), start a transaction, create 'files' and 'directories' distributed across the nodes that comprised the PCTE system, together with links between them all, and then either commit or abort the transaction. If the transaction was committed then your changes got saved. If it was aborted, they were cancelled so that the 'filesystem' would be unchanged. The distributed aspect relied in part on NFS so the Windows port relied on third party Windows NFS client/server software. What was really cool was the day I could run esh (essentially bash) scripts on Windows NT and it all interoperated just right with the Sun and Alpha stations in the next room.

Francois: I thought my first contribution had to do with the COM interfaces but apparently I posted a patch fixing some LPPOINT/LPSIZE mismatches in the headers before that (Wine's changelog is really complete).

However, by my second patch I must have tried to compile the MFC using Winelib. I probably did not go far as at that time the COM interfaces were not usable in C++ programs. Mostly I think the header were just providing the C interface which is macro-based. So I set to adding the definitions needed by the C++ class-based interface. This lead to my first significant contribution.

So my initial patches all had to do with trying to compile Windows applications using Winelib. I think that at that time most of the work on Wine had been geared towards getting binary compatibility. The result was that the Wine headers were not very usable for Winelib. Many functions and types were declared in the wrong headers, some functions were implemented but not declared in the headers, header dependencies were incorrect, etc. So I had my work cut out for me getting the headers into shape. Now the situation is much better. Not just because of my work of course :-) The efforts to use Wine code on ReactOS and to compile using the Mingw headers helps keep our own headers straight.

Francois: Well, Winelib is definitely the area I prefer. But I have not had time to work on it for a long time. As I became more familiar with Wine I found problems here and there and set out to fix them. In time this grew to a todo list that I will probably never get through :-(

So besides Winelib there is not really a specific area that I like to work on. Usually I find something wrong that looks like it should be easy to fix. There's bonus points if the problem might be widespread. Then I try to fix that issue wherever I find it. For instance there were some problems with the way Wine was doing the conversions between the argc/argv and command line formats. So I wrote a test program and fixed the problem wherever I could find it (which was in 3 or 4 places).

Francois: There are two ways to port a Windows application using Winelib.

The first one is by using winemaker. winemaker will look through your sources and perform two main tasks:

• tweak your sources to make them more palatable to Unix compilers. This mostly involves performing CR/LF conversions, fixing the case of #include statements, replace pragma pack statements, etc. This can all be done easily by hand but doing so would be pretty tedious for large projects.
• analyze your sources to generate makefiles. I feel that this part is very important because most of the time Windows developers don't have makefiles at all.

Currently winemaker builds the makefile entirely from its analysis of the sources. This is nice because it means winemaker works no matter what Windows compiler (Microsoft / Borland / Intel / Other) was used for the project. It also means a Linux developer can put a C file in a directory and get an executable just by typing 'winemaker; ./configure; make'. But this is also winemaker's weakness. Because the source won't tell you what include path to use, which libraries to link with, etc. So in complex projects you may have to tweak the makefiles after the initial winemaker run.

Since most of the commercial Windows development is performed using Visual C++, one way to greatly improve winemaker would be to extend it to parse the Visual C++ project files (.dsp). This would give winemaker access to the include path, library path, exact list of sources for each executable/library, and even compiler options. This has been on my todo list for a long time but I never got the time to come back to it.

The other winemaker drawback is that it's not up to date with regard to all the changes that have taken place in the Winelib build process. So you may need to update winemaker first (hint: look at how Wine compiles its libraries and see what winemaker's makefiles do differently).

I am less familiar with the other approach. But basically it consists in first getting the application to compile with MinGW, which implies writing MinGW compatible makefiles. To ease the pain you might be able to generate the makefiles from Visual C++ projects and you should even be able to use winemaker to fix your sources (winemaker --nogenerated-files). Then a very small change to the makefiles to use the winegcc tool developed by Dimitrie O. Paun will give you a Winelib application.

One advantage of this approach is that you can then use the same makefiles to build on Windows using MinGW, and to build a Winelib executable on Unix (though that's not very useful if you want to use another compiler on Windows). Also the build procedure won't go through all the mutations that the normal Wine makefiles went through.

The big drawback of this approach is that currently you cannot use it to generate dlls so it's quite limiting. But once that limitation is solved it would definitely be the best approach for MinGW-based / open-source projects. Whether it's the best approach for projects not based on MinGW will depend on how much work it is to generate the makefiles...

I think that ultimately the best solution is to modify winemaker so it generates MinGW compatible makefiles, and so that it supports Visual C++ project files.

Francois: Not really. In particular they are regular text files which makes it easy to parse them.

Francois: I worked a lot on sample applications found in the Petzold programming books. I used them to develop winemaker and to fix the Wine headers. I believe initially only 30% of them would compile and in the end more than 90% compiled out-of-the-box after a simple winemaker run.

I also got the MFC library to compile but that required some tweaking of the MFC itself, mostly to compile out those parts that used functionality not implemented in Wine. Then I tested the MFC library with some simple applications but I did not get to port any complex MFC application.

CodeWeavers used Winelib to port MusicMatch Jukebox 5 and was also involved in the Kylix development which was a Winelib port too. Kylix was pretty interesting because it mixed Winelib and QT components in a single application. But I did not get involved very much in these projects.

Francois: I started working for CodeWeavers in summer 2000. I'm doing a bit of everything. Obviously I do some Wine development, and I have also done a lot of work on our CrossOver Plugin.

I think one of the main strength of our CrossOver products is that they make it easy to run Windows applications, and that they integrate really well with the user's KDE/Gnome desktop environment. But there is still room for improvement so lately I have mostly been working on these aspects: making CrossOver even easier to use, more flexible and powerful, and keeping up with the desktop evolution (for instance each new Linux distribution changes the way menus work :-( ).

Francois: Yes, there is a new version of CrossOver Plugin in the works. When it comes out it may not look like a big revolution but to us it's a pretty big deal.

Due to historical reasons CrossOver Plugin and CrossOver Office currently have completely separate codebases. In particular CrossOver Plugin is based on the pre-LGPL Wine which makes it obsolete in Wine's fast-evolving world. So the big deal for us is that the new CrossOver Plugin uses the same codebase as CrossOver Office, including a Wine tree that is less than a month old. Hopefully this will mean less work for us and a more stable CrossOver Plugin with more features for our users. Once we have rooted out all the regressions that is...

Francois: I think desktop integration is very important to end-users. End-users want to solve the task at hand and will try to select the best tool for the job. If the fact that some of them are made for Windows makes their behavior so inconsistent with the other tools that they become awkward to use, then users won't use them. In a way Wine will have failed to reach its goal.

But it's also possible that some usability problems are best solved at the distribution level rather than at the Wine level. Integration with the system-tray is a clear case where we must add the required support to Wine. In the case of menus it's not so clear cut. We need mechanisms in Wine -- and we have them, see winemenubuilder and wineshelllink -- but part of the problem can also be solved at the distribution level or at the packaging level.

For instance Debian provides a generic menuing system that makes it possible to create menus for whatever window manager the user has installed. A unique menu declaration will create a menu for fvwm, windowmaker, etc. Even Gnome and KDE are supported but the menus end up in an awkward place which makes them relatively worthless. Mandrake uses that system too... but users may bypass it to use the regular KDE menus while RedHat and other distributions don't support this system at all. And Gnome 2 has abandoned the notion of hierarchical menus entirely!

Because with CrossOver we have to offer a polished product with great desktop integration, we have to deal with each menuing system individually. But in my opinion it would not make sense for Wine developers to spend so much time on it. In fact it does not make sense for any Linux developer to have to spend so much time on this mess. It's a case where we (and here I mean the Linux community) clearly need a cross-distribution cross-desktop standard.

Francois: Packaging Wine to minimize how much users have to deal with configuration issues is pretty important. For instance users should not have to manually tell Wine which sound driver (OSS, Alsa, aRts, etc) to use. If that cannot be determined automatically, then the Linux distributions should leave hints that can be used by applications (Wine, xmms, mplayer, etc).

But in the long term the best way to improve Wine's usability is to keep improving Wine so applications install and run without trouble. Because as long as Wine cannot run the application a user needs, Wine is not usable to that user.

Francois: I wish Wine would take advantage of Xv. Xv is an X extension that makes it possible to offload video scaling and YUV conversion to the graphics card. So Xv support would really help for Windows multimedia player such as QuickTime, Windows Media Player but also DVD/DivX players.

It would also be great if it could provide better multi-user support. The problem currently is that if you have multiple users they must each have their own .wine directory. Otherwise there would be conflicts when trying to access the registry. You would also have permission problems or no access control at all, etc. But solving these issues would require pretty big architectural changes and is very far off. There are more important things to work on right now.

I would also like unmanaged windows to work better, desktop mode to work like one would expect and better support for Alsa and aRts.

Francois: It's hard to say as it really depends on what you want Wine to do.

Direct3D was a big hole in Wine's capabilities. I'm not playing games so I have not had a chance to test the new code. But from my neophyte's point of view, it certainly looks like there is a lot of great work being done in that area. I hope it will continue that way.

If your goal is to have Wine run more office-style applications, then improving COM/DCOM so we depend less on the native ole* dlls is probably more important (but certainly much less interesting to most).

Francois: It's more than just office versus home users. A secretary will mostly use Microsoft Office and related applications, a graphics designer will use Phostoshop & co, while an engineer may use AutoCAD. Similarly a home user that uses Quicken may not be using the same applications as a gamer. So I think a more useful way to categorise users is by activity / task, with each user drawing applications from two or three categories.

Francois: If we are to focus on specific applications (and given the distributed nature of open-source development that's somewhat unlikely), then the best targets are the most popular applications, the likes of MS Office, MS Money, CorelDraw, etc. These are the applications that will bring the most users to Wine, and some percentage of them are bound to contribute. These are also the applications that will bring the most respectability to Wine, which leads to people taking Wine more seriously, and eventually either deploy it or be willing to fund its development.

Francois: The only area that I think Wine should avoid is server applications. This is an area where Unix is pretty strong and often has better solutions that Windows. Furthermore I think it does not make sense to run such applications on Wine given its level of development.

Concerning the browser issue, I don't really know. I'm not too keen on integrating a browser in Wine but it's true that many applications depend on Internet Explorer. So I guess it's something we will have to deal with sooner or later.

Francois: I think Wine is a very important open-source project, not just for the success of Linux, but also for the greater good. If we rank open-source projects by importance, then Wine is definitely right there with the Linux kernel, KDE, Gnome or Mozilla. Yet Wine has a much smaller developer base. Despite this handicap it has made enormous progress, but it would still be great to have as many developers as some of these other projects.

I have tried to find ways to improve the appeal of Wine. That's the idea behind the 'Why Wine is important page?' and the task lists for new developers. But I am not much of a marketer so I'm probably not the best person for this.

Francois: I can't point to anything specific, just throw a couple ideas out there.

The web site is certainly a major aspect of Wine's perception. After all it's most likely the first thing potential Wine users see. From that point of view I think we have made lots of progress.

While Wine is relatively well-known, I think there are still a lot of misconceptions about Wine and many people who don't understand its importance. So, 'marketing-wise', fighting these misconceptions and explaining the importance of Wine should be our priority. How to do that is a harder issue. As a start we have the following two pages on the web site:

• Why Wine is so important
• Debunking Wine Myths

But it's likely only converts read these pages. Maybe offering to make a presentation about Wine to your local LUG could help. For instance I addressed some of these issues on the presentations I made: CrossOver and Wine

Francois: I don't know about KDevelop but a developer should be able to take Visual C++ and hack on notepad on Windows. That's not true of all of Wine of course.

It's true that Wine can be pretty daunting. Also, the traditional approach -- try to run an application and try to fix the first bug you hit -- has its share of flaws. Besides your skill-level and perseverance, whether you succeed or abandon in disgust depends a lot on how hard the bug happens to be: whether it's an interprocess messaging problem or a missing NULL pointer check on the first line of a Windows API for instance.

But I think that, like any large project, there are both easy and hard tasks. The (not so easy) trick is to make it simple for potential contributors to find a task they can tackle. We still have not reached this nirvana but a lot of progress has been made already, especially thanks to the last web site update. Particularly relevant are the following pages:

• Contributing to Wine
• To Do Lists
• Fun Projects
• Janitorial Projects

Francois: Since then the regression test suite has been renamed to the conformance test suite. That's because the reference is not the buggy behavior of old Wine revisions, but the behavior of Windows. That is, its goal is to make sure that Wine behaves just like Windows. In other words that Wine's behavior conforms to that of Windows. Of course it also allows us to detect when we introduce a bug so it also performs well as a regression test suite.

Here's how it works. For each dll we create a tests subdirectory and start writing C code that tests the APIs exported by that dll. The tests are typically split into a few files, with each file testing a specific area of the functionality exported by the dll. For each group of tests we create a file and an entry point. For instance:

START_TEST(scanf)
{
int res;
sscanf("42", "%d", &res);
ok(res==42, "sscanf failed. Got %d instead of 42", res);
}

When placed in a file called 'scanf.c', the above declares a group of tests called 'scanf', i.e. really just a function. That function does a single test which is to make sure sscanf (e.g. from the msvcrt dll) correctly parses the string 42. Of course one can build more complex tests by having multiple functions, etc. The Wine build system then turns these into a Winelib application, one per dll being tested. 'make test' also runs these applications and if any of the tests fails, the Winelib application print an error message and causes 'make test' to fail.

You can also go into a specific test directory and run just a group of tests. For instance, for the msvcrt library we have tests for the file APIs and scanf. Typing 'make scanf.ok' will run just the scanf tests, while 'make file.ok' will run just the file API tests.

For more details about writing Conformance tests, see: http://www.winehq.org/docs/wine-devel/testing

Francois: I think the framework is pretty good. It has a couple of weaknesses for cases where you have to test file APIs because you have to make sure to cleanup after yourselves. Otherwise, if the test fails and leaves a file behind, it could cause the next run to fail long after the bug has been fixed. It can also be tricky to write networked or multi-process tests. But it's really not clear how we could modify the framework to make these cases really simpler. At least in its current form, the testing framework is simple and thus very easy to grasp which is good.

One thing it needs is more testing on Windows. Apparently most of the tests a written on Linux using Wine. That's certainly to be expected since that's exactly what most Wine contributors are using.. Unfortunately it means the tests tend to just describe how Wine behaves, not how it is supposed to behave. This can be counterproductive if for some reason a developer modifies one of the tested API and realises it no longer passes the tests. He may then spend a lot of time trying to tweak the new algorithm to pass the test while in fact it is the test that was wrong and not the new implementation!

This is why it is very important to verify the correctness of these tests by running them on Windows, and preferably, at least one Win9x and one NT, 2000 or XP flavor. Unfortunately that's a bit harder than just running them in Wine and is not as well documented. In particular, when compiling them on Windows one tends to run into header incompatibilities, or even missing APIs on older platforms which prevents some tests from running entirely. The fixes are not very complex but can take some time. Also it requires actually having access to a Windows computer. So I think Wine needs a few dedicated volunteers who will regularly make sure the tests written by other Wine developers compile, run and are correct.

Francois: Thanks for interviewing me. It's been an honor :-)