This week Francois Gouget took some time to discuss his involvement with Wine. This is our 11th interview with Wine developers. Check out the Interviews page for previous ones.
Francois grew up in France. He's spent the last five years living in California but he recently moved back home. He attended college at Ecole Centrale de Lyon studying engineering sciences. Francois explained that higher education is quite a bit different in France compared to the US (follow the link for more details.) He wanted to study more computer science and ended up completing a degree in that field at Cambridge. Besides Wine, Francois enjoys SciFi and comics, the "more varied european ones" .
BV: How did you get involved with Wine?
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.
BV: Wow, in 1995 both Linux and NT were fairly new. I imagine that app didn't run on Linux at the time. Did you try porting it to Linux at all?
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.
BV: Did you finish porting it to NT?
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.
BV: Do you remember the first patch you submitted?
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.
BV: What areas of Wine do you like to work on?
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).
BV: You've worked on winemaker and other tools a lot, could you explain what tools exist in Wine to help porting applications with Winelib?
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.
BV: I've never read through a .dsp file. Are they very complicated?
Francois: Not really. In particular they are regular text files which makes it easy to parse them.
BV: Have you actually ported an application using Winelib?
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.
BV: When did you start working for CodeWeavers?
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 :-( ).
BV: There's been rumors of a new CrossOver Plugin being released. Is this one based on the LGPL'ed version of Wine?
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...
BV: You mentioned integration with the desktop. How important do you think that is for Wine? I think you could easily argue that it's something for the distributions to worry about, after all, they're the ones screwing up the menus.
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.
BV: Is there anything that could be easily done to improve Wine's usability?
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.
BV: Is there anything you wish Wine could do, but can't?
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.
BV: What area do you think needs the most development right now?
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).
BV: That's true, there's really two different areas to focus on - the business users versus home users. On the one hand you've got someone who needs to run MS Office and then there's the guy trying to run KaZaA at home.
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.
BV: Do you think there's any applications Wine needs to focus on supporting?
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.
BV: Conversely, are there any areas Wine should just give up on? For instance, there's been talk of integrating a browser into Wine. Should that idea just be abandoned?
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.
BV: Do you ever wish there were just more developers?
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.
BV: I don't think many people involved with Wine are good at marketing, but I also think great strides have been made in the past year or so. Is there anything you think Wine should be doing to promote itself?
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:
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
BV: I think a lot of Wine is pretty daunting. It takes a fair amount of knowledge of both Unix and Windows tools/concepts in order work on it. Or is that a complete misconception? Could a Windows developer sit down with something like KDevelop and hack on notepad?
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:
BV: Last year at Wineconf you gave a presentation on regression testing. Since then, the test suite has gotten a lot bigger. Could you explain a little bit about how regression testing works in Wine?
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:
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
BV: Do you think it works well? Are there any changes to it you'd like to see?
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.
BV: Thanks for the interview!
Francois: Thanks for interviewing me. It's been an honor :-)