This week's interview is with Eric Pouech. Eric hails from France and has been involved with Wine for a number of years. His involvement has centered around multimedia work, the wine console, and the debugger. Most of the questions below center on one of those areas.
BV: How did you get involved with Wine?
Eric: It was in late '97 or early '98, when I first installed Linux on my home PC, and a friend of mine told me about Wine. So, I installed it, and started running a few apps... (Un)fortunenately, a part of the Windows app I wanted to use (mainly MIDI sequencers & edition program) didn't work on Wine. So, I waited a couple of months to see if someone was tackling the issue, and when I understood no one was actually working on it I decided taking a spin.
BV: So had you been using Linux/Unix for a while at that point?
Eric: yes... since a couple of years
BV: Do you remember the first patch you submitted?
Eric: Yes, it was about implementing Midi playback on the OSS driver.
BV: Do (did?) you use the commercial OSS drivers from 4Front?
Eric: no, just the plain Linux one.
BV: You've worked a lot on Wine's multimedia architecture. What parts do you really like?
Eric: There's actually no part I like more or less. After fixing a bit the MIDI playback, I wanted to be sure that I got it right, so I started testing some more multimedia apps, which showed lots of flaws in Wine (unimplemented features, need for architecture improvement), so I kept on going...
BV: Last year you wrote ALSA driver. What advantages does ALSA offer over OSS?
Eric: Not exactly. Marco Pietrobono and David Hammerton did most of the work. I gave them a hand on some implementation details. Marco wrote most of the audio part on ALSA 0.9. But the mixer and midi pieces are still missing in the current ALSA driver.
From a technical point of view, ALSA is a better defined interface (for example, there are lots of cards which don't behave in the same way to the same API, which can give you a lot of head-aches). From a driver implementation point of view, ALSA's shall be a bit cleaner than OSS but we should end up with the same results. There's still one area which is currently not well covered by Wine ALSA driver.
Before explaining it, we need to look at a couple of MM architecture. In Wine, there's only one place where a sound card/interface is implemented: the multimedia driver (surprise!!). This driver is called from two different places:
The later requires a COM interface we export thru (as of today) undocumented interface. The dsound driver interface allows the driver to expose the hardware buffer (basically the DMA region from which the sound card plays its data). We use this possibility (it's not mandatory) with the OSS driver for better performance. This is not done yet for ALSA (and the feasibility studies are not finished yet, so we're not even sure we'll be able to do it). To finish on this technical bits, note that latest Windows version no longer use this hardware buffer exposition, mainly because they allow mixing of output streams from different applications (which you cannot easily do on the DMA buffer).
BV: But isn't that the point of aRts and esound? I know there's been a preliminary aRts driver floating around, is something like that necessary? Or does Wine need to directly access the hardware?
Eric: For some games & dsound, adding another mixing level increases latency. On the other hand, as CPU power increases, OS latency decreases, we may in a near future drop that requirement (see also the ALSA bits)
BV: Do you see this as the future sound backend for Wine, or will OSS continue to be the dominant driver?
Eric: As more and more Linux distributions now ship with ALSA enabled, and ALSA will be in Linux 2.6, ALSA will become the standard on Linux. But, before we do anything on the matter, we need to have the decent configuration utilities for selecting the appropriate driver. It's still sane to assume today that most PC boxes (at least on Linux and BSD) will have an OSS interface (if they have a soundcard). It won't be sane to suppose the same for ALSA, even for a couple of coming years. So, the automatic configuration is the way to go (it would also allow to support correctly non Linux boxes, and also let Gnome or KDE users choose EsounD or aRts drivers).
BV: Will the ALSA driver work with the new 1.0 ALSA interface? Or does it need to be rewritten?
Eric: Current ALSA driver only supports the audio part, not the mixer and midi interfaces. We have a audio driver for 0.5 and 0.9 interfaces. I hope (even if I didn't check it in all details) that we'll manage easily the 0.9 => 1.0 move.
BV: The other area you've worked on is the Wine debugger. Did you write most of it, or just end up maintaining it at some point?
Eric: Since many years, Wine had an internal debugger. At the times when Wine was a monolithic application (no separated DLLs, all Windows processes running in the same Unix-address space), the internal debugger had a direct access to all the memory (Wine internals, Windows-process memory). When Wine started to be split (wineserver to allow interprocess exchange, each (32bit) Windows-process having its own unix-address space), debugger needed some heavy rewriting. Alexandre Julliard wrote most of the Win32 debugging API (generation of debug events, cross (Windows)-process memory access...). I then ported the existing Wine debugger to this API (instead of direct memory access it was using at that time). Since then I (more or less) maintain what became winedbg, Wine's debugger.
BV: You did some work to hook it into GDB with a remote stub. Have you continued that work at all? Does it make debugging easier?
Eric: Work on this area (the proxy: conversion of GDB remote stub protocol into Win32 debugging API) is almost finished (in terms of protocol). The good side of this is that gdb is far more powerful (and has fewer bugs) than winedbg. So, IMO this should become more and more used. The real need for winedbg is for 16 bit applications and native Windows modules debugging, where gdb is of no help.
We also plan to add MS debugging information reading to gdb, so that winedbg would only be meaningful for 16 bit apps.
BV: Would things like ddd start working too? Personally I've always sucked at programming so I find things like graphical debuggers helpful.
Eric: I tried it once (on top of proxy and it worked), but never spent too much time on it. Debuggers are good for catching error conditions & context, you usually gain more by thinking and looking at the code than running things inside the debugger.
BV: If Wine was to convert over to using pthreads would that make integration with GDB easier?
Eric: In that case, we should use gdb directly over wine processes without using the proxy. The proxy would have only one advantage: providing Wine specific command to explore Wine's internal state (process, memory...) that gdb wouldn't know about.
BV: How's the work going on adding a ncurses backend to wineconsole? and how does that change it?
Eric: finished. As of today, if you start a program with wineconsole foo instead of wine foo, it will display its content in the unix-console where you typed the command line. but you'll get a real windows-console, whereas the 'wine foo' form, only works for printf-like output. if the program requests the creation of a console, we'll get back to what's called user-backend for the console => a standalone window, managed by wine.
BV: You're listed in the to-do list as working on Winhelp. It hasn't worked well in a while, what problems are you running into?
Eric: Well, I assume it works way better know!!! Most of the .HLP files I know of are correctly loaded. There are still lots to be done in the rendering part: for example, help format allows for information rendering on a matrix base (row x columns). This is currently not supported at all, and you end up will all text/information as if no column was present, so below each other. Also, help files contain macro invocation under certain events (file opening, page opening, link click...). There are a long list of predefined macro, out of which a few are currently implemented.
BV: I'm caught.. I haven't tried to open any help files in a long time. Back in November you rewrote the macro engine and there's now a bunch of FIXME's for the various events. Do those macros hook directly into common dialogs? Or is there yet another layer of abstraction going on?
Eric: It depends on the macros. some are really basic things, some other are pretty much more complex (like presenting all the pages in the help file...). And I also started by working on the simplest macros :-(
BV: Doesn't Windows have many different versions of help files? How many are supported right now?
Eric: The latest .HLP files are well supported. The really early ones are not (but I never came across one of those, they should be for Windows 2.0)
However, since MS help format evolved from .HLP files to .CHM (compressed HTML), Wine has also to implement a decent .CHM reader. Work is under way, but not finished yet.
BV: So what are your plans for the future? More multimedia work? Or are you going to tackle something else?
Eric: well,
BV: So what's going on with all these NTDLL patches lately? How close is the kernel32/ntdll separation from being done?
Eric: I'd say at least a hundred, if not a couple of hundreds I don't think we're going to reach it before summer anyway (especially if only Alexandre and myself are working on it)
BV: How does kernel32 differ from NTDll?
Eric: kernel32 provides the system level interface (files, memory management, process, thread, synchronisation...) for the Win32 API. kernel has existed since the very beginning of windows. Starting with NT, a new architecture has been put in place, which allowed several subsystems to be run on the same box (Win32, POSIX, OS/2, Win16...). In this architecture, all common system code now lay in ntdll. Kernel32 provides the API for the Win32 subsystem. So basically, from a functionnality point of view, ntdll and kernel provide quite the same items. However, interfaces are rather different. As Wine evolved from a Win3-like architecture to a NT-like one, we still need to go the same way Windows already did.
BV: Why did you guys decided to tackle that one? Why not user or GDI since they have the same problem?
Eric: User and GDI don't have the same problem. Dll separation focuses on two separate items:
Providing #1 allows to do all the DLL imports only on a single way (the Windows' one), which simplifies and cleans up the implementation. Providing #2 allows a better portability of DLLs (to ReactOS for example), but also a better isolation for testing a single DLL (on windows for example).
ntdll/kernel32 suffers from those two items. User32 and GDI32 are (mostly) done with #1, and still have to go thru #2. Ntdll/kernel32 still have several hundreds of entry points to go thru #1, which will take some time.
One of the criteria to reach 0.9 is to have achieve the stage #1 described above.
BV: What issues have you run into?
Eric: No serious issues so far, more a matter of being sure we don't break everything in the process. Moreover, the split may also be the opportunity to rework some existing parts of Wine which really need this. I'm thinking of:
Since, all of this touches the core of Wine, it's rather a touchy matter, so extreme care is given for going on step by step basis.
BV: It looks like Alexandre recently started that with the winevdm app. At first glance it looks pretty complete. Have you used it yet? Besides cleaning up some code, does it offer other advantages?
not yet, but it seems quite promising. Basically, it only splits (a bit) wine into:
there are still a couple of points to be addressed (like separating kernel32 from krnl386, support for shared/separate VDMs in CreateProcess to name a view), but that's a good starter!!
BV: How's Rewind doing? I know various bits from TransGaming have made it in there, are there any significant additions in there?
Eric: IMO, ReWind's goal is to ease the bridge between Wine and TG. So, there's not (as of today) something in ReWind which is not either in Wine or WineX.
BV: Do you miss writing the Wine Weekly News?
Eric: It was really fun writing WWN. I, in fact, started it just to improve my knowledge of some parts of Wine I didn't know well (covering wine-devel every week ends up with a very wide area of subjects). I really enjoyed it. On the other end, it's something very time consuming (moreover for non native English speaking person), so I also enjoy the time I "recovered" from WWN to do some other things (like working more on Wine ;-).
BV: Do you think this year Wine might actually hit 0.9? Dimi's to-do list is starting to look fairly complete. A lot of the bigger items are starting to seem like user interface issues and documentation. Do you see any major architectural issues?
Eric: For me, 0.9 is more a matter of will (pushing for it) than technical issues. In other words, we have to really decide what's in 0.9 and what's not (as of today, lots of work doesn't really fit in reaching the 0.9 goal). Dimi's trying to push a bit, at least to track what remains to be done, it doesn't mean it's going to be done. 1.0 won't be done this year :-(
BV: Thanks for the interview!
