- Wine-devel - list.winehq.org

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

19 Dec '01

> On Mon, 17 Dec 2001, Patrik Stridvall wrote: > > > > This has been my argument against Patrick exactly. Some > > > protection is better than none at all. > > > > As a general rule, yes. > > > > However this time the protection comes with a price. > > And what might that price be? You fear that we are going to > alienate the > commercial ventures developed around Wine? Yes. > > The problem is not whether LGPL is well written or not the > > problem it is the doctrine of derived work. That is very > > unclear because of lack of good case law. > > Oh, come on, for crying out loud! The LGPL is the best thing > we have -- we > can't wait for a good case law to adopt a license. Yes, there may be > problems, but that's life. We take our best shot -- this is what we're > doing with Wine in the first place! The main problem is that using the LGPL introduces uncertainty to what is allowed and that advantages is not good enough IMHO to outweight the disadvantages. > Patrik, your entire arguments are based on such obscure > assumptions that's > scary! I must tell you, both the GPL and LGPL have received careful > scrutiny from FSF's legal council (and a bunch of other law > professors, > I'm sure). The problem is the doctrine of derived works. Nothing else. Even if their understand of other parts of law are perfect it matters not. IIRC their arguments always seen to assume that the doctrine of derived works is unproblematic if applied to source code. > It's the best we can hope for now. You come along > with a bunch > of 'it is possible' type of scenarios (doh, everything is > possible!), and > say that 'well, everything's in vain, we're doomed, there's > no point in > doing anything, actually...'. In all honesty, it just looks > stinks. Badly. To connect again to the example of the spirit of Communism: I am sure it was very popular to dismiss to fear of the opponents by saying what you have been saying. Trivialising the problems and clinging to clean, pure and uncomplicated spirit of it.

2 1

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

19 Dec '01

> Patrik, > > The more I read your posts, the less I understand what you > are trying to > say. You argued over many hundreds of lines over weird > technical details > and various dubious assumptions about what courts will do in > the future. The main point is that what is legal allow is very unclear. I'm not primarily trying to explain what is legal allowed or not, just pointing out some difficulities in understand what the law really means. > Stop for a movement and tell me: are you against the letter > or the spirit > of the LGPL. Asking that question is like asking whether I support the spirit of Communism: "From each according to his abilities - to each according to his needs." Well, it sound nice doesn't it? However doing a little deeper analysis I realize that the price for being able to do this is not worth paying. Note however that I'm not equating GPL or LGPL with Communism. It was just an example from real life, that you get more that you wish for. See below. > The spirit is simple: > > Here is this thing, we give it to you for free, use it for your own > benefit however you see fit. But it's a labor of love, and > many people put > thousands and thousand of hours in it, together with their hearts and > souls. As such, they hold it dear, and they want it to survive, and > thrive. All we ask is: if you've made _small_ improvements to > it, to make > it useful to your purpose, please contribute those back such > that our baby > can grow and develop together with your business. I'm against the fact that the GPL or to a smaller extent LGPL tries use the doctrine of derived work as a weapon to achieve their goals. It is a very dangerous weapon, since if the courts or the policitians decide that a strong doctrine of derived work is good it might be disasterous for society as a whole. Various commerical intrest might (read: will) for example try to use this to stop 3rd party additions to their works and I don't want that to happend. In short: Be careful what you wish for: "The road to hell is paved with good intentions" > Note that I said "_small_ improvements" because of the > modular nature of > Wine. If the improvements are big, the DLL separation would > allow them to > keep those changes proprietary. I don't think small improvements is a problem anyway and beginning an implementation of say DCOM is probaly not a small improvement and DirectX certainly isn't. > I fail to see _any_ moral/ethical/philosophical problem with > this. Do you? Perhaps you have been more enlightend now.

5 5

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

19 Dec '01

> Technicalities aside, the LGPL spirit seems to be accepted by most > people. We've heard no end of discussion of what represents > the code, and > so on, but in reality (please Patrik :)), Wine is a > _well_defined_ piece > of software. In fact, it's defined by Microsoft, and well > accepted by the > world at large. > > Now, that being said, there seems to be two camps: > -- the BSD camp, which maintains that BSD is good enough, and that > people will in fact do what the LGPL wants. > > -- the LGPL camp, which says 'well, if that's the case, why > not have it > formalized in the license'? No, I think you misunderstand. I'm not in the BSD camp as you define it. I do not nessarily believe that everybody will follow what the LGPL wants or at least that they will do things that they are certain would have been allowed if it was LGPL. And that is an important part of my objection: It makes it less clear what is allowed. > Before I go any further, I would like to stress a very important > point: Wine is in fact a collection of independent projects. > These are the > DLLs, and they nicely (and unequivocally) partition Wine into lovely > little, independent components. And this means that the LGPL is > independently contained to each and every DLL. It is the _perfect_ > position to be LGPLed. You forget that some "independent"(*) parts like the Crypto API are parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. Actually large parts of the Windows API are "independent"(*). They are just helper function wrappers around other functions. (*) By "independent" mean that they just use other parts of the Windows API like normal applications do and claiming derived work for this would be absurd, just like claiming it for normal applications would be absurd. > At this point, I would like to know if people agree up to > this point. I don't. > The > discussion has been going all over the place, so I would like > to keep this > email short and to the point: > 0. Isn't Wine's best interest to evolve and develop as fast > as it can? Yes. > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? No, not nessararily. See different mail. > 2. If so, why shouldn't we formalize it in the license? But it isn't nessarily so. > When answering these questions, let's try to leave the > commercial aspect > out of it for a second. That is a separate discussion. You > see, the reason > we care about the commercial aspect is that we hope (from > Wine's selfish > point of view -- as it should be!), that the commercial world will > actually _help_ in the development of Wine (that is, having a > commercial > universe around Wine would be in Wine's best interest). Now, > I claim that > the LGPL is _way_better_ for the commercial interests in the > long term, > but I will leave that to a future email (if people care to > discuss it). Claiming that it is better for Wine as a whole is one thing, but claiming that limiting commercial intrests choices is good even for them, requires a explaination.

2 1

implementation of ImageList_*Drag*
by Michael Stefaniuc 19 Dec '01

19 Dec '01

Hello, the attached patch (it's my first wine gui patch, that's why wine-devel is CC'ed) implements the dragging part of the ImageList functions. It works quite well with FreeSolitaire besides the dragged image isn't drawn semitransparent. But how do I draw a semitransparent image? IMO this isn't possible with the BitBlt functions. The ImageList_*Drag* functions shouldn't produce flickering as per the MSDN documentation, but ImageList_SetDragCursorImage (at least in Win9x) produces a short flickering when called. I implemented this function to match the behavior of the native comctl32.dll, but it would be very easy to stop the flickering. Should I change it or keep the Win9x behaviour? bye michael Changelog: Michael Stefaniuc <mstefani(a)redhat.com> fixed/implemented the ImageList_*Drag* functions -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

does mingw include share.h
by Bill Medland 18 Dec '01

18 Dec '01

I'm just off home now so I haven't time to learn sourceforge and download 100M. I need a share.h to go into the msvcrt (for two lousy symbols). I see that much of the msvcrt is based on mingw. Does it include share.h? TIA Bill

1 0

Re: Big Bummer for running Shrinkered files!
by Robert Baruch 18 Dec '01

18 Dec '01

Uwe: > showsehframes.exe from the examples there foinds an endless loop even with > native msvcrt: That was a good idea, to try out that program. I'll have to review how that whole program works. Maybe it has something to do with the fact that scopetable is only valid inside MSVC code -- anything in a frame past the handler and prev ptr is compiler-dependent. Maybe it will work once I finish the EXC_CallHandler code. --Rob

1 0

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

18 Dec '01

> Patrik Stridvall wrote: > > > > > Patrik, > > > > > > The more I read your posts, the less I understand what you > > > are trying to say. You argued over many hundreds of lines > > > over weird technical details and various dubious assumptions > > > about what courts will do in the future. > > > > The main point is that what is legal allow is very unclear. > > Hogwash. I feel the LGPL is extremely clear. It allows > you to dynamically link to LGPL code without worries. Full stop. The clearness of the LGPL in itself is a non issue. The issue in the foundation that LGPL rests on namly the doctrine of derived work. > Patrik, it might be good for you to create a web page outlining > the problems you see in the LPGL; that would give you a > chance to explain > them more clearly than is possible in this forum. Do try to > be succinct. > I'd like to understand your point of view. Hmm. I think I already spend to much time trying to explain my point of view. I would rather answer questions concerning details insteed. Perhaps I will someday, but don't hold your breath.

1 0

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

18 Dec '01

> > But most apps wine will run *cannot* use a GPLed component. GPL > > expressly forbids being linked to a nonGPLed component. > *GPL does not > > only cover the source, but rather the USE of the components > as well. > > Read the > > license. It's quite an eye opener. > > I'd argue (though IANAL) that a nonGPLed win32 executable > running under > wine is not being "linked" to any GPL component - wine itself may be > linking to its own GPL components at run-time depending on > what's going on > with the win32 executable. But in terms of true linkage, I'd > have viewed > the win32 executable as more like a document that causes the host > application (wine) to load appropriate sub-components with > which to process > the document. MS Word (to use an example) might have to > dynamically link in > a special MS Word component to process specifics in my > document, it doesn't > mean my document is "linked" with the MS Word component does it? Ah, you are beginning to see the problem. :-) This is the spot on one of the main problem with the GPL. Proponents of the GPL are trying to use the doctrine of derived work as a means to achieve their goal without realizing (or rather ignoring) that if the doctrine of derived work supported want they wanted it would also, as a logical consequence, support to the absurdity you meantioned above. This is why I firmly oppose the doctrine of derived work and instead hope that the courts will embrace the much more senisible doctrine of combined work that I have been talking about earlier. Of course a strict doctrine of combined work would make the GPL and for that matter the LGPL largely meaningless, since you could distribute the LPGL work, the proprietory patch and a combining script seperately and let the user do the combining as thus no combined work is distributed and thus no violation of copyright law. Note that a doctrine of combined work doesn't effect normal commercial software at all since the end user is legally required to pay for the software if he uses it, regardless of whether the user used some patch offered under whatever license. It ONLY effects viral licenses. > Of course, we could all ask RMS his opinion but we all know > he'll interpret > it (once again) to mean whatever is required to spread his > GPL tenderhooks > as far as possible. Living in Wellington, NZ I'm having to > fight back hard > the temptation to make a "Sauron" joke here ... :-) I don't believe RMS is evil, quite the opposite, just that: "The road to hell is paved with good intentions"

1 0

Re: Big Bummer for running Shrinkered files!
by ek sqrl 18 Dec '01

18 Dec '01

On Mon, 17 Dec 2001 14:49:35 +1000 Mike McCormack <mike_mccormack(a)start.com.au> wrote: > Did you try running wine with -winver win98? Yes, Shrinker tries to load a VXD which is not allowed under Wine. At first I was going to implement a special Shrinker VXD replacement for Wine, but then I found that it wouldn't try to load the VXD under --winver nt40. Thus, I figured I would try to resolve the problems with running under nt40, since that would (at least theoretically) improve the existing functionality of Wine, rather than add new functionality. > > Did you try finding an Un-Shrinker? A quick search using google turned > up a few candidates. Haven't tried any out though. Yes, I've looked at them. They all seem to be h4x0r toolz with no source code. Some new news on the Shrinker front. I've managed to determine, for the most part, what Shrinker's exception filter function does. It's a minefield! Recall that earlier I said it was looking for a magic signature in ntdll.dll. I found all of the landmines. The first landmine makes sure the exception handler was called with the code "call ecx". If not, the process dies. Next, we read 8 bytes from the process around that location. If the read fails, the process dies. If the code starting with the call is not FF D1 64 8B 25 or FF D1 64 8B 0D, the process dies. It then tries to allocate some memory, and copies some of the process code into that memory. If the allocation fails, the process dies. With that in mind, it seems that the only thing it's really looking for is that signature. So one idea that I had is a "Shrinker fixer". When Wine loads an executable, it would look for this specific exception handling code, and then NOP out the checks. Is that a reasonable approach? --Rob

4 9

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

18 Dec '01

> Did anybody mention that if wine moved to an LGPL license, we would be > able to borrow code from a wider variety of other projects? > > That would include KDE, libXML, Bochs, OpenOffice, GTK+, Atheos, jCIFS > and any other LGPL (or compatable) projects. Sure, but I would much rather use them by linking them to Wine than borrowing code and having to maintain it. Whether Wine is LGPL or BSD matters not in such cases.

1 0