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

1. restrictions of EULA - some codes may be based on information from non-VS6. I don't want to battle with EULA.
2. 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...

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:

1. define subsystem/direction owners.
2. more formally define process of bugs handling and use this process
3. Prioritize bugs
4. Ask users to submit there problems in Bugzilla

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.

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).

** 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 mean time, 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.

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.

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.

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 ...

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>

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...

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.

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 seperation 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.

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.

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.