WWN Issue 122

This is the 122nd release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

This week, 392 posts consumed 1145 K. There were 85 different contributors. 46 (54%) posted more than once. 43 (50%) posted last week too.

The top 5 posters of the week were:

41 posts in 163K by Michael Cardenas
33 posts in 87K by Alexandre Julliard
23 posts in 57K by Andriy Palamarchuk
18 posts in 49K by Steven Edwards
17 posts in 54K by Andreas Mohr

News: Xandros Beta, CodeWeavers Wine Preview 6	04/27/2002	Archive
News One company you don't hear a lot about (yet?) is Xandros. Xandros acquired Corel's Linux distribution when Corel got out of the Linux desktop business in August of last year. More importantly, they have some of ex-Corel guys working for them. You can still find an ISO image of the Corel distribution on their website but Xandros is in the process of creating their own product offerings now. They had a call for beta testers a while ago that I totally overlooked. You probably wouldn't have gotten in if you wanted to - 2,000 people applied and 150 were selected. On their about page they describe what they're working on: Xandros is developing a customized Debian-based Linux distribution that is derived from version 3.0 of the award winning Corel LINUX OS. It will support both the KDE and Gnome desktop environments. In addition to the features that Linux users expect, Xandros will be distributing significant additions and enhancements. Furthermore, Xandros is creating a server and enterprise management solution that will significantly reduce the total cost of ownership of computing environments. The overall solution is complete "off the shelf", but Xandros Professional Services can customize and integrate the products as well as provide enhancements to legacy systems as needed. Finally, all Xandros offerings will be backed by world-class support. Xandros plans on releasing their software within the coming months, so stay tuned. One thing I definitely missed last month was CodeWeavers Wine Preview 6 . Dated from April 11th, it came out shortly after the announcement of CodeWeavers Office. CodeWeavers wine is known for it's ease of installation, integration with Gnome and KDE, and having some of the fixes (or, sometimes, ugly hacks that work) that haven't made it into the official Wine CVS. Their releases are somewhat infrequent with the last being five months ago. However, if you haven't tried Wine in a while and aren't comfortable with CVS , tarballs , or even getting one of the daily builds you might want to try out their RPM. It's free, so if you break it you can keep all the pieces. Interesting trivia #1 - CodeWeavers Wine is the most downloaded piece of software by members of Mandrakesoft's Mandrake Club. Also this week, a review of TransGaming's WineX 2.0. Notable quotable, I haven't done much to optimize my Linux box for gaming...but I was happy to have a game that has not been ported for Linux running without hangs or crashes. And, also on the TransGaming front, there's a way for subscribers to get credit for their friends subscribing. If you follow this link: http://www.transgaming.com/create_accnt.php?referer=vinn and subscribe I get credit for it. This in no way endorses TransGaming, nor should it encourage or discourage you from subscribing. My only point is if you were planning on subscribing anyway , then maybe you'd find that useful. In case you're wondering, I'll probably only get a t-shirt out of it.

News: Xandros Beta, CodeWeavers Wine Preview 6

04/27/2002

Archive

News One company you don't hear a lot about (yet?) is Xandros. Xandros acquired Corel's Linux distribution when Corel got out of the Linux desktop business in August of last year. More importantly, they have some of ex-Corel guys working for them. You can still find an ISO image of the Corel distribution on their website but Xandros is in the process of creating their own product offerings now. They had a call for beta testers a while ago that I totally overlooked. You probably wouldn't have gotten in if you wanted to - 2,000 people applied and 150 were selected.

On their about page they describe what they're working on: Xandros is developing a customized Debian-based Linux distribution that is derived from version 3.0 of the award winning Corel LINUX OS. It will support both the KDE and Gnome desktop environments. In addition to the features that Linux users expect, Xandros will be distributing significant additions and enhancements. Furthermore, Xandros is creating a server and enterprise management solution that will significantly reduce the total cost of ownership of computing environments. The overall solution is complete "off the shelf", but Xandros Professional Services can customize and integrate the products as well as provide enhancements to legacy systems as needed. Finally, all Xandros offerings will be backed by world-class support.

Xandros plans on releasing their software within the coming months, so stay tuned.

One thing I definitely missed last month was CodeWeavers Wine Preview 6 . Dated from April 11th, it came out shortly after the announcement of CodeWeavers Office. CodeWeavers wine is known for it's ease of installation, integration with Gnome and KDE, and having some of the fixes (or, sometimes, ugly hacks that work) that haven't made it into the official Wine CVS. Their releases are somewhat infrequent with the last being five months ago. However, if you haven't tried Wine in a while and aren't comfortable with CVS , tarballs , or even getting one of the daily builds you might want to try out their RPM. It's free, so if you break it you can keep all the pieces.

Interesting trivia #1 - CodeWeavers Wine is the most downloaded piece of software by members of Mandrakesoft's Mandrake Club.

Also this week, a review of TransGaming's WineX 2.0. Notable quotable, I haven't done much to optimize my Linux box for gaming...but I was happy to have a game that has not been ported for Linux running without hangs or crashes.

And, also on the TransGaming front, there's a way for subscribers to get credit for their friends subscribing. If you follow this link: http://www.transgaming.com/create_accnt.php?referer=vinn and subscribe I get credit for it. This in no way endorses TransGaming, nor should it encourage or discourage you from subscribing. My only point is if you were planning on subscribing anyway , then maybe you'd find that useful. In case you're wondering, I'll probably only get a t-shirt out of it.

Quartz.dll Removal	05/02/2002	Archive
Multimedia Has anyone ever said anything good about the DMCA? Don't worry, I won't be the first. Over the past 9 months Hidenori Takeshima single-handedly worked on recreating the quartz.dll responsible for implementing ActiveMovie and DirectShow. The codecs involved are a huge amount of code that's unfortunately questionable to distribute due to legal concerns. Without warning the code suddenly disappeared from both the X11 and the GPL trees. Questioned about why it was removed, Hidenori explained: My all MultiMedia codes are completely written from scratch. No disassembling. I believe there are no legal issues. But, I cannot warrant... I should protect myself from any potential problems now... The main issues for me are restrictions of EULA - some codes may be based on information from non-VS6. I don't want to battle with EULA. afraid to many pending patents. I cannot check all patents... and there are some other reasons I don't want to write... So, finally, I decided to solicite Alexandre... Andreas Mohr thanked Hidenori, I hope the reason for taking such rather drastic measures was important. Oh well, anyway, thanks for your contributions, Hidenori ! (I'm just assuming there are still some left ;-) Interesting trivia #2 - Hidenori is the first non-CodeWeavers person to expressly not allow his code into the X11 tree.

Quartz.dll Removal

05/02/2002

Archive

Multimedia

Has anyone ever said anything good about the DMCA? Don't worry, I won't be the first.

Over the past 9 months Hidenori Takeshima single-handedly worked on recreating the quartz.dll responsible for implementing ActiveMovie and DirectShow. The codecs involved are a huge amount of code that's unfortunately questionable to distribute due to legal concerns. Without warning the code suddenly disappeared from both the X11 and the GPL trees. Questioned about why it was removed, Hidenori explained:

My all MultiMedia codes are completely written from scratch. No disassembling. I believe there are no legal issues. But, I cannot warrant... I should protect myself from any potential problems now...

The main issues for me are

and there are some other reasons I don't want to write...

So, finally, I decided to solicite Alexandre...

Andreas Mohr thanked Hidenori, I hope the reason for taking such rather drastic measures was important. Oh well, anyway, thanks for your contributions, Hidenori ! (I'm just assuming there are still some left ;-)

Interesting trivia #2 - Hidenori is the first non-CodeWeavers person to expressly not allow his code into the X11 tree.

Bugzilla: A Call to Arms	04/29/2002	Archive
Debugging Andriy Palamarchuk put out a call to start using Bugzilla: We already had discussion on wine-devel about importance of polishing Wine, making a set of applications to work very well. Cruicial in this process is prioritizing of the issues, work distribution between developers. The companies already have internal testing and bug fixing process. Of course, each company has their own product-specific work, but most of the problems are general for Wine. I suggest to share this work more actively using Bugzilla. Recently there was some work done in cleaning the issues database and it is in pretty much usable condition. To start using bugzilla more actively I suggest following steps: define subsystem/direction owners. more formally define process of bugs handling and use this process Prioritize bugs Ask users to submit there problems in Bugzilla Jeremy Newman went ahead and set up an easy URL to remember that goes straight to Wine's Bugzilla: http://bug.winehq.org

Bugzilla: A Call to Arms

04/29/2002

Archive

Debugging

Andriy Palamarchuk put out a call to start using Bugzilla:

We already had discussion on wine-devel about importance of polishing Wine, making a set of applications to work very well.

Cruicial in this process is prioritizing of the issues, work distribution between developers. The companies already have internal testing and bug fixing process.

Of course, each company has their own product-specific work, but most of the problems are general for Wine. I suggest to share this work more actively using Bugzilla.

Recently there was some work done in cleaning the issues database and it is in pretty much usable condition.

To start using bugzilla more actively I suggest following steps:

Jeremy Newman went ahead and set up an easy URL to remember that goes straight to Wine's Bugzilla: http://bug.winehq.org

SafeDisc Support 04/28/2002 Archive

SafeDisc Support	04/28/2002	Archive
Patches Laurent Pinchart announced: Here's (at last) the (long awaited ?) SafeDisc patch. I want to thank Zsolt Rizsanyi who helped me with the CDROM ioctls (his implementation of IOCTL_SCSI_GET_ADDRESS has not been included in this patch, as I don't have the latest version), Alexandre Juliard for his help with the process suspension, Erich Pouech and Andreas Mohr for their help about how to handle the reentrant wine server calls (even if that has turned out not to be needed in the end), and all of those who answered my numerous questions on #winehq. To the ones I forgot (if any), please forgive me. If you help me with SafeDisc-1 I'll thank you twice :-) As I don't speak 'legalese', here's the usual disclaimer in nglish: This patch works on my system, and it will probably work for some of you. For those who can't get it to work, I'm really sorry, and I'll help if you ask nicely, but don't blame me or sue me. One caveat is the Wine needs to be run with `--winver nt40` Laurent added, For those interrested, here's a FAQs about my SafeDisc support implementation. Feel free to comment. The FAQs were attached to the email and can be found at: http://www.winehq.org/hypermail/wine-devel/2002/04/att-0616/01-safedisc.txt A few people were concerned about DMCA violations, but Laurent felt what he had implemented was within the guidelines.

Patches

Laurent Pinchart announced:

Here's (at last) the (long awaited ?) SafeDisc patch.

I want to thank Zsolt Rizsanyi who helped me with the CDROM ioctls (his implementation of IOCTL_SCSI_GET_ADDRESS has not been included in this patch, as I don't have the latest version), Alexandre Juliard for his help with the process suspension, Erich Pouech and Andreas Mohr for their help about how to handle the reentrant wine server calls (even if that has turned out not to be needed in the end), and all of those who answered my numerous questions on #winehq. To the ones I forgot (if any), please forgive me. If you help me with SafeDisc-1 I'll thank you twice :-)

As I don't speak 'legalese', here's the usual disclaimer in nglish:

This patch works on my system, and it will probably work for some of you. For those who can't get it to work, I'm really sorry, and I'll help if you ask nicely, but don't blame me or sue me.

One caveat is the Wine needs to be run with --winver nt40 Laurent added, For those interrested, here's a FAQs about my SafeDisc support implementation. Feel free to comment. The FAQs were attached to the email and can be found at: http://www.winehq.org/hypermail/wine-devel/2002/04/att-0616/01-safedisc.txt

A few people were concerned about DMCA violations, but Laurent felt what he had implemented was within the guidelines.

MinGW and ftruncate()	05/01/2002	Archive
Ports One item that doesn't get reported here much is the work being done to port Wine to ReactOS. Haven't heard of ReactOS? From their web page, ReactOS is an Open Source effort to develop a quality operating system that is compatible with Windows NT applications and drivers. Working on the Wine side of things are Steven Edwards, Casper Hornstrup, and James Tabor. Currently ReactOS works but the graphics interface (GDI) is not functioning properly. Win32 console apps run and the OS is self-hosting using mingw . The plan is to use Wine as the Win32 subsystem once DLL separation is complete. The main obstacles are: Building the DLLs under Mingw DLL separation - ReactOS can't use internal wineserver functions Interfacing ReactOS and the Wine debugger One area of concern is getting Wine to work with the mingw compiler. Steven Edwards had a question about why a patch he submitted for ftruncate() was not applied and wondered why. Alexandre replied, You'll either have to implement ftruncate in mingw, or change makedep to not require it. But making it silently broken is not a good idea. Steven replied: Ok. I got that from http://developer.gnome.org/doc/API/glib/glib-windows-compatability-functions.html and it works under mingw but I will try to find a better way of doing it or just fix makedep. Steven submitted another patch with the following changelog: Check for and use chsize instead of ftruncate if present.

MinGW and ftruncate()

05/01/2002

Archive

Ports

One item that doesn't get reported here much is the work being done to port Wine to ReactOS. Haven't heard of ReactOS? From their web page, ReactOS is an Open Source effort to develop a quality operating system that is compatible with Windows NT applications and drivers. Working on the Wine side of things are Steven Edwards, Casper Hornstrup, and James Tabor.

Currently ReactOS works but the graphics interface (GDI) is not functioning properly. Win32 console apps run and the OS is self-hosting using mingw . The plan is to use Wine as the Win32 subsystem once DLL separation is complete. The main obstacles are:

One area of concern is getting Wine to work with the mingw compiler. Steven Edwards had a question about why a patch he submitted for ftruncate() was not applied and wondered why. Alexandre replied, You'll either have to implement ftruncate in mingw, or change makedep to not require it. But making it silently broken is not a good idea.

Steven replied: Ok. I got that from http://developer.gnome.org/doc/API/glib/glib-windows-compatability-functions.html and it works under mingw but I will try to find a better way of doing it or just fix makedep.

Steven submitted another patch with the following changelog: Check for and use chsize instead of ftruncate if present.

Use Xrender From XFree86 4.2.0+ 05/01/2002 Archive

Use Xrender From XFree86 4.2.0+	05/01/2002	Archive
Fixes Duane Clark ran into a problem, The xrender CVS patch of 4/23 is causing one of my apps to crash . Huw Davies replied, I think you have a buggy version of libXrender.so. Could you check that this patch stops the crash? Unfortunately it will disable client side font rendering. Jeremy came up with a truly horrible hack to work around this problem but for some reason that I can't possibly imagine Alexandre left it out when he committed the last xrender changes <g>. Duane reported, That does fix it, though I was getting used to the client side fonts :( What version of XFree86 is needed to get a good xrender? I am running version 4.1.0. Jeremy White replied: You need 4.2.0. You can also just build libXrender.so, which is not that hard to pull out of CVS and build by itself. Finally, I have attached the king daddy of all kludges that may let you use your Xrender without modification, but use at your own risk... (you'll probably also need to hand assemble the patch, it's a delta from our internal tree and is not likely to apply). Jeremy's patch can be found at: http://www.winehq.org/hypermail/wine-devel/2002/05/0053.html Mentioned in the patch is: ` Xrender.c bug. (Version 1.4 of Xrender.c had a bug where an uninitialized stack variable could cause this to fail. This is fixed in version 1.5, which seems to correspond to Xfree >= 4.2 In the meantime, we do a total kludge to attempt to address this: we call it twice, and pray that the second time it is initialized (and nudge the stack while we're at it). If it doesn't, we just bail.` Duane still had problems with the patches, but then mentioned: In any case, I just downloaded the binary tar file: http://ftp.xfree86.org/pub/XFree86/4.2.0/binaries/Linux-ix86-glibc22/Xbin.tgz and took out just the libXrender.so.1.1, and installed it. Everything seems to work fine with that.

Fixes

Duane Clark ran into a problem, The xrender CVS patch of 4/23 is causing one of my apps to crash . Huw Davies replied, I think you have a buggy version of libXrender.so. Could you check that this patch stops the crash? Unfortunately it will disable client side font rendering. Jeremy came up with a truly horrible hack to work around this problem but for some reason that I can't possibly imagine Alexandre left it out when he committed the last xrender changes <g>.

Duane reported, That does fix it, though I was getting used to the client side fonts :( What version of XFree86 is needed to get a good xrender? I am running version 4.1.0.

Jeremy White replied:

You need 4.2.0. You can also just build libXrender.so, which is not that hard to pull out of CVS and build by itself.

Finally, I have attached the king daddy of all kludges that may let you use your Xrender without modification, but use at your own risk... (you'll probably also need to hand assemble the patch, it's a delta from our internal tree and is not likely to apply).

Jeremy's patch can be found at: http://www.winehq.org/hypermail/wine-devel/2002/05/0053.html Mentioned in the patch is:


        ** Xrender.c bug.  (Version 1.4 of Xrender.c had a bug where

        ** an uninitialized stack variable could cause this to fail.
     
        ** This is fixed in version 1.5, which seems to correspond to 

        ** Xfree >= 4.2

        ** In the meantime, we do a total kludge to attempt to address this:

        ** we call it twice, and pray that the second time it is

        ** initialized (and nudge the stack while we're at it).  

        ** If it doesn't, we just bail.

Duane still had problems with the patches, but then mentioned:

In any case, I just downloaded the binary tar file: http://ftp.xfree86.org/pub/XFree86/4.2.0/binaries/Linux-ix86-glibc22/Xbin.tgz

and took out just the libXrender.so.1.1, and installed it. Everything seems to work fine with that.

Native user32 DLL?	05/03/2002	Archive
Integration Michael Cardenas wondered: I'm still trying to fix aol so it can communicate with the web proxy, and I think I've narrowed down the problem to user32.dll, kernel32.dll, and ws2_32.dll. Is it possible to use the native user32.dll? I know kernel and ws3_32 don't work native. This has actually worked in the past, but because of the address separation going on it's no longer a "feature". A bunch of people jumped in to debate it, but Alexandre squashed it with, I agree it would help for finding bugs. Unfortunately the Win95 architecture is completely brain-damaged, and trying to support it would introduce so many new bugs and instabilities than the end result would be much worse than what we have today. So no, native user is not going to happen. Ulrich Weigand explained in detail: Well, there's Windows and then there's Windows ;-) In Win9x, address spaces are handled in a peculiar way: the lower 2 GB of the address space are changed on context switch, while the upper 2 GB remain the same across all processes. In particular, all 16-bit segments and certain 32-bit DLLs are de facto mapped shared across all 32-bit processes. The user.exe implementation relies on this fact, as I mentioned previously. Before address space separation, we were handling things somewhat like Win 3.1 (with win32s), in that everything shared one space. After address space separation, we are handling things more like Win NT, in that nothing is shared between processes by default, except for explicit shared mappings (and shared PE sections). In particular, 16-bit segments are not shared between processes (like they aren't in Win NT), which means that user.exe won't work. Implementing the weird Win9x address space handling exactly under Linux would be difficult, and in any case we want to be more like Win NT for stability reasons ...

Native user32 DLL?

05/03/2002

Archive

Integration

Michael Cardenas wondered:

I'm still trying to fix aol so it can communicate with the web proxy, and I think I've narrowed down the problem to user32.dll, kernel32.dll, and ws2_32.dll.

Is it possible to use the native user32.dll? I know kernel and ws3_32 don't work native.

This has actually worked in the past, but because of the address separation going on it's no longer a "feature". A bunch of people jumped in to debate it, but Alexandre squashed it with, I agree it would help for finding bugs. Unfortunately the Win95 architecture is completely brain-damaged, and trying to support it would introduce so many new bugs and instabilities than the end result would be much worse than what we have today. So no, native user is not going to happen.

Ulrich Weigand explained in detail:

Well, there's Windows and then there's Windows ;-)

In Win9x, address spaces are handled in a peculiar way: the lower 2 GB of the address space are changed on context switch, while the upper 2 GB remain the same across all processes.

In particular, all 16-bit segments and certain 32-bit DLLs are de facto mapped shared across all 32-bit processes. The user.exe implementation relies on this fact, as I mentioned previously.

Before address space separation, we were handling things somewhat like Win 3.1 (with win32s), in that everything shared one space. After address space separation, we are handling things more like Win NT, in that nothing is shared between processes by default, except for explicit shared mappings (and shared PE sections).

In particular, 16-bit segments are not shared between processes (like they aren't in Win NT), which means that user.exe won't work.

Implementing the weird Win9x address space handling exactly under Linux would be difficult, and in any case we *want* to be more like Win NT for stability reasons ...

Geography Lesson: Rumantsch	05/07/2002	Archive
Internationalization Sylvain Petreolle was working on converting winhelp for NLS (native languange support) use and ran into a problem, I have to problems to use Va.rc,since I don't know whis country this file is associed to. (probably due to the fact I was asleep in history & geography :) ). I looked in dlls/kernel/nls but didn't see it. Johan Gill thought it could be the Vatican, and Francois Gouget thought so too. Eric Pouech was suspicious of the naming, looking on google for some of the words used in the file seem to indicate that this is in fact "suisse roman" (romanche in English ?), perhaps Alexandre could give an hint on this very important issue ;-))) I don't think that Vatican guards being Swiss Guards is the explanation of the Va name Alexandre supplied the answer: It's apparently "Rumantsch" (not sure about the English name) which is the 4th Swiss national language (after German, French and Italian). It is only spoken by perhaps a few thousand people in the eastern parts of Switzerland. It should not be confused with "suisse roman" which is the language spoken in the western part of Switzerland (where I'm from), and which is basically French except for a few strange words that make us sound funny when we go to France. In Windows terms I think Rumantsch should be LANG_RHAETO_ROMANCE (though this constant only appears in Wine headers so I'm not sure if that's an official Windows definition). The file is named Va.rc apparently because this is the "Vallader" variant of Rumantsch; there are at least 5 variants according to http://www.christusrex.org/www1/pater/JPN-rumantsch.html (you sure find strange things on google...). Don't ask me what are the differences between the variants <g>

Geography Lesson: Rumantsch

05/07/2002

Archive

Internationalization

Sylvain Petreolle was working on converting winhelp for NLS (native languange support) use and ran into a problem, I have to problems to use Va.rc,since I don't know whis country this file is associed to. (probably due to the fact I was asleep in history & geography :) ). I looked in dlls/kernel/nls but didn't see it.

Johan Gill thought it could be the Vatican, and Francois Gouget thought so too. Eric Pouech was suspicious of the naming, looking on google for some of the words used in the file seem to indicate that this is in fact "suisse roman" (romanche in English ?), perhaps Alexandre could give an hint on this very important issue ;-))) I don't think that Vatican guards being Swiss Guards is the explanation of the Va name

Alexandre supplied the answer:

It's apparently "Rumantsch" (not sure about the English name) which is the 4th Swiss national language (after German, French and Italian). It is only spoken by perhaps a few thousand people in the eastern parts of Switzerland. It should not be confused with "suisse roman" which is the language spoken in the western part of Switzerland (where I'm from), and which is basically French except for a few strange words that make us sound funny when we go to France.

In Windows terms I think Rumantsch should be LANG_RHAETO_ROMANCE (though this constant only appears in Wine headers so I'm not sure if that's an official Windows definition). The file is named Va.rc apparently because this is the "Vallader" variant of Rumantsch; there are at least 5 variants according to http://www.christusrex.org/www1/pater/JPN-rumantsch.html (you sure find strange things on google...). Don't ask me what are the differences between the variants <g>

Trading Patches	05/06/2002	Archive
Licensing It's funny how mentioning InstallShield provokes lively threads. One of the last mentions of InstallShield lead to the call for an LGPL'ed Wine tree. This time Andriy Palamarchuk pointed out BugZilla bug #629" concerning InstallShield v6 support. Ove Kåven replied: Oh, well, it's a known problem. It's not easily fixable in the official Wine tree without, say, half a man-year of work. There's an ugly hack (an one-liner) to make it work (in conjunction with a stdole32.tlb file from real Windows), but since Alexandre never yet applied this hack to the official Wine (though it might be in CodeWeavers CrossOver), I presume he never will before there's a "real" solution (which will take man-months of work, and writing an IDL compiler to let us generate our own .tlb file instead of using the native one, maybe another month or two). After the WineX 2.0 release, I've once again been working on completing my version of the real solution (I'm close to have it working now), but of course, Gav probably still wants a fair chunk of LGPL-ed code relicensed in exchange... Several people wondered what the "ugly hack" was to make it work. Marcus Meissner, author of the out of process COM code in the LGPL'ed Wine tree replied with a patch you can find at: http://www.winehq.org/hypermail/wine-devel/2002/05/0171.html Alexandre thought the COM code was going to be exchanged with the ALSA driver. However, Eric Pouech did the development of the ALSA stuff and he clarified his position by stating: When I decided starting coding the ALSA driver, TG offered to sponsor the work. I turned down the offer (don't need sponsor for what I'm doing) and suggested using the money for some other use. Furthermore, I'm not for or against Wine nor for or against WineX. I'm just trying not to let an important gap being created between all the different projects. The ALSA driver has been started on a X11/MIT license, some people currently are giving an hand to shape it better (David Hammerton did some testing and bug fixing for 0.5, Marco Pietrobono is currently fighting with the awes of the 0.9 interface, but that's another story), and will remain under the X11/MIT license. Ove replied to Alexandre's original inquiry about trading patches with, What is most important for TransGaming now, is to see the DLL separation work get into ReWind. He's making a list of things to trade it with, such as a DIB drawing engine, fast DIB sections using ShmPixmaps, this COM stuff I'm working on, and of course various DirectX things. Since I've researched and worked on this COM thing (with undocumented stuff all over) for months, I doubt TransGaming would settle with just an ALSA driver, now that their development costs have increased from the forking. The thread turned rather ugly at points, with Alexandre and Jeremy White both stating that they're not interested in the patch trading business. Everyone agrees that the code should be publicly available, but the licensing was once again the divisive point. Gavriel State jumped in to mention: What we are proposing is not "blackmail" but trade. Really, the economic problem in this licensing situation comes down to a question of accounting (most economic problems do). What value do you place on a contribution to the project, whether it is your own or someone else's? The LGPL license that Wine is currently using is effectively saying that the value of your current contribution is equal to the expected value of any future contributions. IE: All contributions and contributors, current and future are equivalent. Certainly this simplifies the accounting, but at a serious loss in accuracy. As we've already stated, TransGaming can't operate within that framework, for a wide variety of reasons. Instead, we're going to be making the value picture more specific. We would like access to some code that's currently licensed under the LGPL by copyright holders like yourself and CodeWeavers. In particular, we would like to see address space separation work made available under the X11/ReWind license. That would be a boon for everyone, as it would allow easy interchangability between Wine and ReWind (and WineX) DLLs. There are a few other things that would be nice as well. In exchange, we have a number of things that we would be happy to contribute to ReWind, and thus to the Wine tree. These things include our new DIB engine work, COM/DCOM work, selected portions of our work on copy protection, and a number of other significant features. We're also quite happy to work on any DLLs that need additional separation work. What has to get figured out is simply this: exactly what do current Wine copyright holders want to have for the things that we want from you? I'd like to resolve this question soon, and establish some kind of ongoing framework for how to manage this cooperation in the future. I hope to have a detailed proposal for the Wine LGPL-only contributors shortly. Alexandre came up with analogy in reply: The problem is that you are seeing this in economic terms. That's not how it works. The real value is not in the individual contributions, it's in the collaboration, where everybody works with everybody else on building the best possible Windows emulator. Consider you are organizing a party with your friends: someone who has a large music collection will bring his CDs, some will cook something, others will spend time decorating the room, etc. What value do you place on each contribution? How many cakes do I have to bring to be allowed to listen to the music? That's not how it works. Everybody helps according to his time and ability, and then we all enjoy the party. What you are doing is you come to the party, you eat and drink from what others have brought, but when people want some of your stuff you charge them for it. And when they complain you ask them to start charging for their stuff too, and transform the party into a shopping mall. Sorry, but for me that would take all the fun out of it. If you want to join the party you are expected to participate according to your abilities. And yes, with your full-time programmers you can (and should) contribute more than people who just have a few hours a month to spend on it. That doesn't mean you are somehow entitled to get more fun out of the party than they do. So far we have welcomed you to the party, even though you contributed much less than you could have; but the problem is that you are actually preventing others from enjoying the party, and this can't go on. So you can either start participating and sharing like everybody else, or you can stay home and cook your own dinner. But if you want to eat some of what I've brought, the only way is to join the party. Look for a continuation of this thread.

Trading Patches

05/06/2002

Archive

Licensing

It's funny how mentioning InstallShield provokes lively threads. One of the last mentions of InstallShield lead to the call for an LGPL'ed Wine tree. This time Andriy Palamarchuk pointed out BugZilla bug #629" concerning InstallShield v6 support. Ove Kåven replied:

Oh, well, it's a known problem. It's not easily fixable in the official Wine tree without, say, half a man-year of work. There's an ugly hack (an one-liner) to make it work (in conjunction with a stdole32.tlb file from real Windows), but since Alexandre never yet applied this hack to the official Wine (though it might be in CodeWeavers CrossOver), I presume he never will before there's a "real" solution (which will take man-months of work, and writing an IDL compiler to let us generate our own .tlb file instead of using the native one, maybe another month or two).

After the WineX 2.0 release, I've once again been working on completing my version of the real solution (I'm close to have it working now), but of course, Gav probably still wants a fair chunk of LGPL-ed code relicensed in exchange...

Several people wondered what the "ugly hack" was to make it work. Marcus Meissner, author of the out of process COM code in the LGPL'ed Wine tree replied with a patch you can find at: http://www.winehq.org/hypermail/wine-devel/2002/05/0171.html

Alexandre thought the COM code was going to be exchanged with the ALSA driver. However, Eric Pouech did the development of the ALSA stuff and he clarified his position by stating:

When I decided starting coding the ALSA driver, TG offered to sponsor the work. I turned down the offer (don't need sponsor for what I'm doing) and suggested using the money for some other use. Furthermore, I'm not for or against Wine nor for or against WineX. I'm just trying not to let an important gap being created between all the different projects.

The ALSA driver has been started on a X11/MIT license, some people currently are giving an hand to shape it better (David Hammerton did some testing and bug fixing for 0.5, Marco Pietrobono is currently fighting with the awes of the 0.9 interface, but that's another story), and will remain under the X11/MIT license.

Ove replied to Alexandre's original inquiry about trading patches with, What is most important for TransGaming now, is to see the DLL separation work get into ReWind. He's making a list of things to trade it with, such as a DIB drawing engine, fast DIB sections using ShmPixmaps, this COM stuff I'm working on, and of course various DirectX things. Since I've researched and worked on this COM thing (with undocumented stuff all over) for months, I doubt TransGaming would settle with just an ALSA driver, now that their development costs have increased from the forking.

The thread turned rather ugly at points, with Alexandre and Jeremy White both stating that they're not interested in the patch trading business. Everyone agrees that the code should be publicly available, but the licensing was once again the divisive point. Gavriel State jumped in to mention:

What we are proposing is not "blackmail" but *trade*.

Really, the economic problem in this licensing situation comes down to a question of accounting (most economic problems do). What value do you place on a contribution to the project, whether it is your own or someone else's?

The LGPL license that Wine is currently using is effectively saying that the value of your current contribution is equal to the expected value of any future contributions. IE: All contributions and contributors, current and future are equivalent. Certainly this simplifies the accounting, but at a serious loss in accuracy.

As we've already stated, TransGaming can't operate within that framework, for a wide variety of reasons. Instead, we're going to be making the value picture more specific. We would like access to some code that's currently licensed under the LGPL by copyright holders like yourself and CodeWeavers. In particular, we would like to see address space separation work made available under the X11/ReWind license. That would be a boon for everyone, as it would allow easy interchangability between Wine and ReWind (and WineX) DLLs. There are a few other things that would be nice as well.

In exchange, we have a number of things that we would be happy to contribute to ReWind, and thus to the Wine tree. These things include our new DIB engine work, COM/DCOM work, selected portions of our work on copy protection, and a number of other significant features. We're also quite happy to work on any DLLs that need additional separation work.

What has to get figured out is simply this: exactly what do current Wine copyright holders want to have for the things that we want from you?

I'd like to resolve this question soon, and establish some kind of ongoing framework for how to manage this cooperation in the future. I hope to have a detailed proposal for the Wine LGPL-only contributors shortly.

Alexandre came up with analogy in reply:

The problem is that you are seeing this in economic terms. That's not how it works. The real value is not in the individual contributions, it's in the collaboration, where everybody works with everybody else on building the best possible Windows emulator.

Consider you are organizing a party with your friends: someone who has a large music collection will bring his CDs, some will cook something, others will spend time decorating the room, etc. What value do you place on each contribution? How many cakes do I have to bring to be allowed to listen to the music? That's not how it works. Everybody helps according to his time and ability, and then we all enjoy the party.

What you are doing is you come to the party, you eat and drink from what others have brought, but when people want some of your stuff you charge them for it. And when they complain you ask them to start charging for their stuff too, and transform the party into a shopping mall. Sorry, but for me that would take all the fun out of it.

If you want to join the party you are expected to participate according to your abilities. And yes, with your full-time programmers you can (and should) contribute more than people who just have a few hours a month to spend on it. That doesn't mean you are somehow entitled to get more fun out of the party than they do.

So far we have welcomed you to the party, even though you contributed much less than you could have; but the problem is that you are actually preventing others from enjoying the party, and this can't go on. So you can either start participating and sharing like everybody else, or you can stay home and cook your own dinner. But if you want to eat some of what I've brought, the only way is to join the party.

Look for a continuation of this thread.

CrossOver Office under FreeBSD	05/01/2002	Archive
CodeWeavers Karel Bosschaart mentioned that he got CrossOver Office to work with FreeBSD: FWIW, I installed the linux version under emulation in FreeBSD and made a little write-up of my experience: http://wop21.wop.wtb.tue.nl/cxoffice Except for the flood of unimplemented ioctl's messages it runs quite OK, but of course I'm looking forward to the FreeBSD version. I'll add more of my experiences while using CrossOver Office. Karel mentions he tested FreeBSD 4.5-R, 4.5-S, and 5.0-DP1 with linux_base 6. Francois Gouget was pleasantly surprised it worked, but concerned about the ioctl's performance impact.

CrossOver Office under FreeBSD

05/01/2002

Archive

CodeWeavers

Karel Bosschaart mentioned that he got CrossOver Office to work with FreeBSD:

FWIW, I installed the linux version under emulation in FreeBSD and made a little write-up of my experience:

http://wop21.wop.wtb.tue.nl/cxoffice

Except for the flood of unimplemented ioctl's messages it runs quite OK, but of course I'm looking forward to the FreeBSD version.

I'll add more of my experiences while using CrossOver Office.

Karel mentions he tested FreeBSD 4.5-R, 4.5-S, and 5.0-DP1 with linux_base 6. Francois Gouget was pleasantly surprised it worked, but concerned about the ioctl's performance impact.

World Wine News