Interviews

Ove: Many years ago, back in the days Windows 3.11 was still relevant as a platform, and Linux was becoming a usable platform, I vowed never to turn over my soul to Bill by upgrading to Windows 95. For a professional like me, Windows 95 was nothing but pain. While my primary machine continued to run Windows 3.11, I planned to let its slow march to obsoletion give me sufficient motivation to research better operating systems than yet another Microsoft product.

I administered another machine that ran Linux, and while somewhat unpolished, I found it to work out for many things.

But on the Windows 3.11 machine, I had fun playing a MMORPG by Sierra, "The Realm", in my spare time. Then I thought, hmm, wouldn't it be nice if I could play this on the Linux machine, too? After considering it a bit, and finding the free time, I downloaded the Wine sources and started hacking. It took only a few weeks to get it to work, if I remember right. But by then, I was already hooked on the concept of Wine, and started trying to get Eudora to work, then Free Agent. Given that I had a level of experience with advanced Windows programming that few of the other contributors had at the time (and was able to fix the bugs that plagued Eudora and Free Agent), I soon decided to become a permanent member of the Wine team.

Ove: I don't remember. Maybe only a few months after that (after that my little brother inherited my account and characters).

Ove: Well, I had a dialup shell account on an ISP a couple of years before this (their PPP access was more expensive than the shell account). It was possible to write and compile programs on it. (Nowadays such accounts are mostly used to run IRC bots, of course.) I only needed shell access to do what I wanted (irc, pine, lynx), but I found I could compile and run a PPP emulator (slirp) (and rename it to irc so the admins wouldn't notice) if I really wanted to. Anyway, this was where I got my initial Unix experience before running my own Linux systems, which I also wrote a few things on before getting involved with Wine.

Ove: Not really. But I think some DIB fixes were among the first. Perhaps it was some palette stuff, too.

(looks in documentation/ChangeLog.OLD) Hmm, seems a winsock patch was first, makes sense since I'd have to get online before I'd see graphical glitches... and I'm pretty sure that the cursor fix was the last thing I had to fix before the game was playable.

Ove: Hmm, difficult, I've worked in many areas. But I think I used to favor the DOS support. I wanted to use Wine to run some DOS apps (particularly The Realm's patcher, in fact). I didn't like dosemu's model, it ran a real DOS in a virtual machine on a virtual hard disk. Since apps running in virtual machines are really hard to integrate seamlessly with the host OS (and with its other apps, like Wine), Wine's approach of implementing the emulated OS's API as a layer on top of the host OS, instead of running the original OS in a distinct virtual machine, was much more appealing. Unfortunately, Wine had no way to run DOS apps yet, but, you know, that was obviously nothing that couldn't be fixed... So Wine's support for running DOS apps became "my" part of Wine, and it was really fun to work on. Very challenging, yet not insurmountable.

Unfortunately I couldn't continue working on this part of Wine, as professional work took its toll on my time. Nowadays, I can't really point out anything that's really my favorite area. Almost anything can be fun to work on if it breaks new ground in some way, and I've worked on a lot of areas.

Ove: Yes.

Ove: I think that this is just DLL separation, but he's also aiming at getting DPMI programs to work, which means that DPMI interrupts must also be available in 32-bit protected mode, so he'll also try to get some infrastructure in, I think.

Ove: I think that has to be the InstallShield v6 support. It uses very advanced COM techniques, which needs very elaborate support from the COM framework (which has to be implemented in Wine since it's part of Windows), and implementing all of that is both very tedious work and very hard to get right. Though InstallShield v6 is functional now, after several months of work, Wine's COM support code is still not properly implemented (so e.g. repainting while installing is still a problem).

Unfortunately that work was also among the factors that drove the Wine project towards the license change; because that work was such a huge project, my employer, having ended up paying me a lot to do it, was trying to find someone to sponsor bringing it into Wine, instead of immediately donating it. But many Wine developers (including CodeWeavers, who had helped with the big InstallShield effort, so I can sympathesize with them) felt that this was a problem.

So, the Wine project eventually responded by trying to make it illegal to not donate code back. I suppose we could say that dealing with this unexpected situation was very challenging, too. For me personally too; if you dig up some old newsgroup archives, you can see that I was against Wine adopting the LGPL many years before I started to work for TransGaming.

But, ironically, since then, my DCOM work has been sponsored through the voting choices of the TransGaming subscribers, and released under the X11 license; some of this code can now be found in both the ReWind and Wine trees.

Ove: Apart from Alexandre Julliard himself? There are definitely some people who have chosen to submit their code under LGPL, but almost all have been willing to make deals when asked. You can see ReWind's list at http://www.ping.uio.no/~ovehk/rewind/contrib-list.cgi

Ove: Still is, there's a patch from Alexandre we haven't yet got around to reimplement.

Ove: TransGaming actually demonstrated WineX on PlayStation 2 a while ago (see http://www.transgaming.com/news.php?newsid=37 ), along with some state-of-the-art dynamic binary translation technology from Transitive Technologies. I didn't have anything to do with it myself, though (and if I did, I probably couldn't discuss the details anyway).

Ove: If it could run stuff like Monkey Island II, that would be cool. (Yeah, I did play MI2 recently with ScummVM, but you know what I mean.)

Ove: It's a DOS game. Last time I tried, it had problems with keyboard input. Perhaps it's fixed now, but even if it runs, it wouldn't be quite the same without the sound.

Ove: Simple. They asked me, and I said yes.

Well, the story is a little longer... I think it goes back to the days of Corel's Wine involvement, where Gavriel State, the CEO of TransGaming, worked at Corel as the project leader of the Linux application division. He had actually interviewed me and knew my qualifications, but couldn't hire me for Corel because of Canada's immigration system. When he left Corel to create TransGaming, though, it was a different story - he was now free to arrange me to work as an international contractor, working over the Internet, without setting foot in Canada. I could even continue attending university in Norway while working if I wanted, though I soon started working fulltime.

Ove: It depends. I can occasionally take the time to work on my own Wine projects if I want to, but it just doesn't fancy me as much as it used to. For one, Wine is now LGPL, which makes me less interested in working on it (I still occasionally submit code to it sometimes, but mostly for moral reasons, it doesn't feel as good as it used to). And working on WineX is usually enough, I can usually do the things that interest me with WineX, especially since they usually have no problems with me doing things far out of assigned priority order.

Ove: No, RPC doesn't particularly interest me, it's just there to support cleaner COM framework code, which is needed for InstallShield v6 to repaint properly while installing. It's a priority for TransGaming since good-looking user interfaces are important these days. The COM framework itself has a somewhat interesting architecture, and is surprisingly well engineered considering who made it. Then again, most of the ugly details remains undocumented.

It's not fun, but I guess that's what taking most of my time right now. Other than that I mostly work on various DirectX issues in WineX.

Ove: RPC (Remote Procedure Call) is an architecture for calling a procedure/function, usually on another machine, across a network. IDL (Interface Definition Language) is used to describe such remotable functions, such as what parameters they take, what interface they belong to, and various other things. COM (Component Object Model) is a standard for letting components talk to each other in a vendor-independent manner (and typelibs also help make COM language-independent), and DCOM (Distributed COM) builds on both COM and RPC to create an architecture where any object can talk to any other object elsewhere on the system or the network. Plain RPC isn't object-oriented, but DCOM is.

I'm not sure what goals he has, it looks like he's trying to implement plain RPC functionality, while I'm mostly interested in DCOM and the COM framework around it, needed by InstallShield. Since DCOM is designed as an extended RPC, we both have to work on RPC, but from different angles.

Ove: Sure. Given knowledge of the typelib format (which we have to some degree since Wine has code to parse such files), it shouldn't be too hard to add it. It may be somewhat tricky, and some care must be taken, but since widl has pretty much implemented the worst part, parsing the IDL, it just takes some data type conversions to generate the typelib. A typelib is basically a binary equivalent of a .h file, and widl can already generate .h files, so there shouldn't be any major hurdles in the way.

Ove: Not really. It wouldn't be too hard to decompile a typelib into IDL, there's even a tool that comes with Microsoft Visual C++ that can do it, just point and click. Besides, Robert Shearman recently submitted usable IDL (or ODL in this case) sources for this to wine-patches.

Ove: I haven't had time to tend to it much for a long time, so it's probably lagging a bit behind. But since there has been some interest in ReWind (even recently), I suppose I (or someone else) ought to start actively maintaining it again before it dies not of lack of interest, but of inefficient and unresponsive maintainers...