December 2001 - Wine-devel - list.winehq.org

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 16 Dec '01

16 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Even according to a strict interpretation of the LGPL > > they would just have to provide their code in seperate > > files so everything could be relinked when new versions > > of Wine was released. > > It seems you really don't understand the LGPL. Modifications made to a > library released under the LGPL are a derivative work of this library, > and have to be LGPL no matter if they are in separate files or > not. Saying the ALL modifications gives rise to a derived works even if distributed seperately is a ridiculous proposition that is the main problem with (L)GPL. As I have been trying to explain is that the courts are unlikely to support this, at least not 100%. The question is where is borderline is. At the extreme end the courts might totaly reject the doctrine of derived work in favour of the doctrine of combined work what I have been talking about in previous mails. If somebody (A) only provide drop in files that replaces some functions say the Crypto API in ADVAPI32, they are not any combined work since they are 100% written by A. Sure the application/library as a whole is of course a combined work, but that doesn't matter if you do not distribute it as a whole. > This is the standard interpretation that just about anybody > except you agrees with. If you think everybody agrees what a derived work is you are badly mistaken. Even Richard Stallman himself admit that the power of (L)GPL is dependent on how far the courts will allow the doctrine of derived work. Note that I do not pretend to know how the courts will rule. But I do know that sticking the head in the sand and pretending that (L)GPL doesn't have large potential holes in it is quite naive and potentially dangerous.

3 2

Decision process on possible switch to LGPL
by Roger Fujii 16 Dec '01

16 Dec '01

Dan Kegel <dank(a)kegel.com> wrote: > > Who has to decide what in order for the Wine project > to switch to the LGPL? I believe the process involves all prior contributors allowing this, or have the non-LGPL code rewritten and that work be LGPLed. Pending on the number of authors, the effort can be non-trivial. Look at the license change discussions for mozilla and kde if you want to get the grasp of what is required. > Could it be as simple as the wine cvs tree accepting LGPL'd contributions > along with old-license contributions? Not if you want a "pure" LGPL distribution. > Or need one go so far as requiring all new contributions to the cvs > tree be under the LGPL? even further. > Would a valid way of voting be to open up a new cvs tree that > accepted only LGPL contributions, and giving maintainers the > choice of which tree (or both) to submit to? That would > within not too long show how contributors felt. This is going to encourage more development... NOT. What you definitely don't want is confusion over what license is being used. Unless you make a stipulation that the final license chosen will automatically convert the other license, it would just be a mess as you then will have 2 source trees which you have to go back and reconcile. -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

2 1

OSS stuff
by Duane Clark 16 Dec '01

16 Dec '01

The recent OSS stuff is working pretty good. I have one area, where one sound clip stops and the next starts, that sometimes has problems. Sometimes the second clip runs normally, and sometimes there is just a brief bit of the very beginning of the second clip. I think this is where the problem is. The difference I see is that when it breaks, some wodNotifyClient msgs are received before the wodGetPosition messages are set to valid values for the new clip. When it works, those values get set before the wodNotifyClient msgs. Then again, I really don't understand what is going on. A trace from when it fails: trace:wave:wodRestart imhere[3-RESTARTING] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_RESTARTING 0 trace:wave:wodPlayer_FeedDSP fragments=16/16, fragsize=1024, bytes=16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290cdf4.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce14.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 12288 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce34.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 8192 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce54.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 4096 trace:wave:wodPlayer waiting 46ms (132,46) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=0/16, fragsize=1024, bytes=-1226 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CDF4 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE14 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE34 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE54 dwParam2 = 0000 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=4294966070 trace:wave:wodGetPosition TIME_SAMPLES=134217421 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=1/16, fragsize=1024, bytes=742 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=742 trace:wave:wodGetPosition TIME_SAMPLES=185 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=3/16, fragsize=1024, bytes=2694 trace:wave:wodPlayer waiting 110ms (110,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=2694 trace:wave:wodGetPosition TIME_SAMPLES=673 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=5/16, fragsize=1024, bytes=4648 trace:wave:wodPlayer waiting 88ms (88,4294967295) It continues this way until the DSP buffer is empty, and nothing further is written to it. Here is when it works: trace:wave:wodRestart imhere[3-RESTARTING] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_RESTARTING 0 trace:wave:wodPlayer_FeedDSP fragments=16/16, fragsize=1024, bytes=16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290cdf4.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce14.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 12288 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce34.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 8192 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce54.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 4096 trace:wave:wodPlayer waiting 46ms (132,46) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=78 trace:wave:wodGetPosition TIME_SAMPLES=19 trace:wave:OSS_wodMessage (0, 0009, 0000001C, 4290CE74, 00000020); trace:wave:wodWrite (0, 0x4290ce74, 00000020); trace:wave:wodWrite imhere[3-HEADER] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_HEADER 4290ce74 trace:wave:wodPlayer_FeedDSP fragments=1/16, fragsize=1024, bytes=108 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce74.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 108 dwLength 4096 available space was 108 trace:wave:wodPlayer waiting 45ms (132,45) trace:wave:wodPlayer_FeedDSP fragments=0/16, fragsize=1024, bytes=-990 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CDF4 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE14 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE34 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE54 dwParam2 = 0000 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=2/16, fragsize=1024, bytes=928 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce74.108[4096] trace:wave:wodPlayer_WriteMaxFrags Written 928 dwLength 3988 available space was 928 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200

1 0

Adding protections in map_image
by Robert Baruch 16 Dec '01

16 Dec '01

Hi all, Uwe and I have been working on several executables which have been compressed by Shrinker. Basically, under win98 it tries to load a VXD which is disallowed. The prospects are better under nt40 mode, but it looks like Shrinker purposely causes read and write exceptions. After looking at this for a little over a week, I've found that there are two problems which need to be solved. The first is that the exception handler installed by Shrinker under Wine causes another fault and then a spin. Under WinDbg (in W2K/VMWare) the exception handler does not cause another fault, and execution continues nicely. The second is that WinDbg finds a write fault where Wine does not. To fix this, Wine must set protections on the executable's image map. I came up with a patch to do this, and it worked for my Shrinkered exe, but not for Uwe's. Uwe's exe loads MSVCRT20.DLL, and then Wine calls PE_fixup_imports, which attempts to write to that DLL's .idata section, which had been set read-only. Clearly Wine needs to write to that section to set up imports which haven't been implemented. Now, my patch put the protections on the mapped image right at the end of map_image. This works when map_image is called (eventually) from PROCESS_InitWine, so that the initial executable gets its protections set right. However, it doesn't work for PE_LoadLibraryExA (called by LoadLibraryExA) because it first checks to see if the library has already been loaded. If it has been loaded, it calls PE_fixup_imports. If it has not been loaded, it calls (eventually) map_image. So if the library has already been loaded, it has already had its protections set up by map_image at some point in the past. Then when PE_fixup_imports is called, a protection violation occurs. My current idea is to go into PE_fixup_imports, unprotect the .idata section, do the fixups, and reprotect the section. The bad thing is that if someone else in the future writes some code that does additional fixups to other sections, they are also going to have to unprotect and reprotect. This might turn out to be a good thing, though, if it forces you to do that. What does everyone think? Thanks, --Rob

2 6

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 16 Dec '01

16 Dec '01

> > Note that I do not pretend to know how the courts will rule. > > But I do know that sticking the head in the sand and pretending > > that (L)GPL doesn't have large potential holes in it is quite > > naive and potentially dangerous. > > Then if the LGPL holes are dangerous, the X11 license should be even > more dangerous; after all it's a much larger hole than the LGPL will > ever have. I still don't understand where you are trying to go with > your argument. Sure it has a larger hole. But at least it is obvious that is does. It doesn't make you believe good things will happend. The point is that you seem to wish some things to happend and I point out that LGPL provides not guarentee that it will actually will happend despite that LGPL at a quick glance looks like it in some meaning forces what you wish to happend. One the other hand the LGPL might scare away potential companies wishing to extend Wine. See below. > No, of course the LGPL doesn't provide absolute protection; nothing > does, and I don't think absolute protection is desirable either. There > are some things that the LGPL clearly allows, some that it clearly > forbids, and a number of border cases, that frankly are only > interesting to people who want to try to get around the license > restrictions. And what would be the point of doing that? Making their business model work. Trying to ensure investment return. > If the > license is not acceptable to someone, they don't have to use the > code. Who would risk bad PR and potential lawsuits just to prove that > they can find a loophole in the LGPL? So we lose some possible companies willing to help in two step. 1. Because they do not dare 2. Because you (or somebody else) sue them Great idea. NOT. > You really make it sound like the LGPL is some kind of unexplored > wilderness that we shouldn't venture into. We are not a normal software project and thus what really is a derived work when faced with a lot unimplemented stuff are much more difficult to know. I have tried to show that LGPL in itself is pretty weak and are likely to be even weaker then faced with Wine's special circumstances. > The fact is that a large > majority of free software projects use either the GPL or the LGPL, and > in practice it works just fine for them, just as I'm confident it > would work just fine for us. Normal software project doesn't have any large design with a lot of not yet implemented functions, there it makes sense for some company to say: Hey I could provide an implementation of this special part under this special business model. Face it we are not a normal software project and the arguments they used for chosing (L)GPL are not really relevant here. Note that I'm not denying that convincing arguements for choosing LGPL might exists, but reference to earlier success is not one of them. Your argument that LGPL forces good things to happend is not entirely convincing either for reasons stated earlier. The current license is something that is easy to understand and are unlikely to scare companies like Transgaming away, but can you really say the say same about LGPL?

2 1

Decision process on possible switch to LGPL
by Dan Kegel 15 Dec '01

15 Dec '01

Who has to decide what in order for the Wine project to switch to the LGPL? Could it be as simple as the wine cvs tree accepting LGPL'd contributions along with old-license contributions? Or need one go so far as requiring all new contributions to the cvs tree be under the LGPL? Would a valid way of voting be to open up a new cvs tree that accepted only LGPL contributions, and giving maintainers the choice of which tree (or both) to submit to? That would within not too long show how contributors felt. - Dan

1 0

configure broken?
by Oliver Sampson 15 Dec '01

15 Dec '01

Howdy, I just tried to update my CVS version and I get the following: checking size of long long... ./configure: line 6355: syntax error near unexpected token `<<<<<' ./configure: line 6355: `<<<<<<< configure' Really, all is did was type 'cvs update' :-) Thanks, ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

6 7

Re: Various OSS fixes
by Ian D . Stewart 15 Dec '01

15 Dec '01

On 2001.12.12 15:27:16 -0500 eric pouech wrote: > this patch should fix a lot of last OSS bugs > thanks to all the people which reported issues and took time > for the testing... Eric, I tried applying this against build 20011108, and got the following error message: 23 out of 41 hunks FAILED -- saving rejects to file dlls/winmm/wineoss/audio.c.rej Do I need to upgrade (or downgrade) Wine before applying this patch? Thanx, Ian -- "Looney?! I'm just as sane as the rest of you. Never mind..." --DaemonThread, comp.lang.java resident looney Get my GNU Privacy Guard public key at ftp://ftp.stewartcastle.com/pub/idstewart.key

2 2

Problems with FreeLibrary winmm.dll
by Uwe Bonnes 15 Dec '01

15 Dec '01

Hallo, somewhere in the MS Encarta99 installation the programm tries to start /dosd/windows/temp/~GLJ6675.tmp d:\\wine95\\system\\SWFLASH.OCX In the flow of that program, it calls FreeLibrary(Handle(winmm.dll)). After that, a GetModuleHandle16("user.exe") leads to a crash, indicating that the linked list of 16 bit dlls is disturbed. Denying FreeLibrary on a handle to winmm.dll circumvented the problem and let the program continue. Any ideas for a clean solution? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 15 Dec '01

15 Dec '01

At 07:47 PM 13/12/2001 -0800, you wrote: > >What do others think? I feel rather dismayed by the whole discussion. First to all you lawyers who have already posted their legal opinion, you can dismiss all that I will say : I'm not a lawyer and I don't want to be one. It's only a low-level common sense point of view, what I think is right or wrong. First a link : http://www.gnu.org/gnu/thegnuproject.html This is the philosophy of the gnu project, from the guy who designed the cornerstone : the Gpl (I will say Gpl even if what is in question here is LGpl : from my point of view, it is only a technicality) You will notice the enormous number of terms evoking public rights, user rights, help your neighbour philosophy. I have nothing against that by itself. However, what I find surprising is the use of this philosophy. You'll find many examples of that, in another of this thread's posts for example : >A few years back, Ingo Molnar >(or Linux Kernel fame), wrote to the wine-devel list saying that he really >wanted to contribute the project but didn't because of the lack of >protection of his work from the licence. Here is the keyword in my opinion : *his* work. in this particular case Ingo Molnar could mean the right thing of course, I can't say for sure from a short citation - but there is so much more of this stuff. Here is more if you want, from another poster : >I -have- had to deal with companies stealing my GPL code Here this is so much more clear. *My* code. They have stolen from *me*. Where are the users's right ? I don't want to say that it is all right to use Gpl code in proprietary works. But I think that any legal (real) action should - morally - only be done when an user has been really wronged. I think that a user getting proprietary work including gpl'ed code could ask for a court to order the release of the full code of the app he bought. He could ask for getting his money back for all the licenses (beyond the first) that he bought, since he had the right to manage the installation of additional copies himself. He could ask the court to sweep aside any Eula limiting the company responsibility since the hiding of Gpl code removed his right to fix the bugs himself. All this means civil litigation, damages, money. >From my - common sense, not legalistic - point of view, that would be entirely appropriate. In this context, the Gpl developer could associate to the first legal action, so that his *moral* right could be recognized and - more importantly - the infringement proved. But a 'pure' Gpl (not the double licensing sort) developer suing for himself, without any actual user wronged, is not morally acceptable in my opinion. The usual argument about Gpl, that courts would not accept the action because there is no material interest (money) for Linus Torvalds, for example, in Linux, is akin to mine, but my point of view is not legalistic. This is not right because if he asks for money, he is doing a pitiful mockery of the generous philosophy expressed in the Web page I referenced. If he asks for the society to punish the deed, a penal action in opposition to a purely civil action, he is doing something even more distateful. He is asking the society to consider the infringement on his rights something so important that the doer should be punished even in the absence of any tangible damage for anyone. I think that he is justifying the idea of 'intellectual property' : copyright infringement is stealing, infringers are thieves (criminals?) (words quoted because I refuse the idea entirely - and yes, I'm aware that Gav State himself approves of it :-)), like the society can punish an (old-fashioned) thief even if by mistake what he stole was entirely valueless. I believe that in your approach (I mean here you, Alexandre Julliard), as in the case of the developers I quoted, I have not heard much about users rights. If you cared that much for users, as is implied by the Gpl license, the work made by Codeweavers for Borland would be repellent : yes, the code (all of it ?) has been released to Wine. But Kylix users don't have the possibility to get the Wine source code used; they don't have the right to get latest Wine code and maybe fix bugs. This is scandalous from a Gpl point of view, yet no Wine developer has ever said anything against it. Why what was a mere possibility before has become urgent now ? Transgaming, of course. Transgaming is, in your words, taking away the 'mindshare' of users and developers. Gav replied that end-users were not harmed since they got the source anyway, but it has not mollified you - to the contrary. I'm sorry but this sounds rather selfish. You have entirely the right to be selfish about your (enormous) work of course, but a proprietary license is more logical in this case. You want to use the Gpl as a tool, but I don't see a lot of respect for the philosophy that is behind it. What I find even more disturbing in what you said is the allusion (when replying to Patrick) to a future tightening of copyright laws, a tendency that is in my opinion directly linked to the idea of copyright, patents, etc being 'intellectual property' assets, and infringers thieves stealing them. You seemed to welcome the additional protection it would give Wine. What I hear is : more Dmitry Sklyarovs. More programmers in jail. Is this what you want ? Are you really so eager to send legal injunctions to people ? No one should think that in a legal action the programmers doing the actual work will be left alone and the 'suits' will go to jail. This is not how this world works (not that I think that the 'suits' deserve it anyway) Don't think also that you can avoid that easily : it's said that Adobe never intended for Dmitry to be jailed, and they backed away as soon as it happened. But he stayed in jail nevertheless. I believe that the freedom privation that someone sent to jail is suffering is more grievous that the privation that an user suffers when he has no access to the code of his application (in most cases - there may be exceptional cases, but certainly not *computer games*) and is not proportionate to the deed. That's a very important reason for which I am afraid to hear Gpl developers brag about threatenings they can make to people 'stealing' 'their' code. I have two more practical remarks to finish my ramblings : 1) if Wine turns into a legal machine hunting 'intellectual property' 'thieves' (and there is *a lot* of money involved with Win32 api of course), it could get some really bad public opinion. I think that one of the frail walls protecting Wine from legal harassement is public opinion disliking people using lawyers instead of competition. Be done by as you did, could say the public opinion later - when the MS lawyers come. 2) You seem to think that Transgaming or similar companies are or could be responsible for the low Wine mindshare among developers I don't think this is explaining even 1% of the problem. There are much more bigger reasons for Wine not attracting and - more importantly - not keeping developers. I don't think this particular discussion is important now, though. Gerard

4 3