wine-devel December 2001

wine-devel@winehq.org

86 participants
179 discussions

Re: overlapped ReadFile should ignore EAGAIN
by Alexandre Julliard 20 Dec '01

20 Dec '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a fix for the problem below. Since all COM port fds are > non-blocking, if we get an error (EAGAIN) return from the initial > read, we should just ignore it and let the wineserver poll on it. Shouldn't you check for EAGAIN then? It doesn't seem safe to ignore all errors. -- Alexandre Julliard julliard(a)winehq.com

1 0

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

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > There will be very little reason for companies to enter the market > > at that time and why try to make it difficult for the few > that might. > > On the contrary, there will be a lot more reasons. The main market is > not in developing Wine; frankly there isn't that much money to be made > on that. The main market is in using Wine to make money on > applications, and the more complete Wine gets the easier this will be. If the applications is are already proprietary I they can affort to pay to get the whole way to 100% functionallity. If they are open source they have an incentitive to work making Wine complete. I don't really see the problem. > But if Wine never gets complete because some parts are held > proprietary by other companies, it won't be possible to enter that > market. So you mean that all the people that are current voluntering to work of Wine won't work on Wine if it is almost complete just because somebody else have done the parts they need to run their applications and that they will happily pay for the right to use it. In that case it would be disasterous to make Wine run all Microsoft implemented non-core Wine DLL:s because then everybody would just be happy to use the Microsoft DLL:s and nothing beyond non-core would ever be implemented. You can't seriously believe this?

10 19

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

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > For example: > > void CryptFoo() > > { > > CRYPT32_CryptFoo(); > > } > > > > and release the code above under the LGPL. > > That's the square root example. If you do that, you have to make sure > that the use of CRYPT32_CryptFoo is optional and that the function > still behaves properly if your CRYPT32 function is not available. Forget for a moment I was trying to circumvent the LGPL. Lets say I just found a crypto library called CRYPTO32 under a proprietory license that I wished to use. It so happends that they had almost 100% the same functions as the Crypto API. So almost all functions would look like void CryptFoo() { #if HAVE_LIBCRYPTO32 CRYPT32_CryptFoo(); #else /* Old Wine code */ #endif } with a few minor exception. So you mean that I can't legally do that despite the fact that the LGPL is meant to allow linking to proprietary licenses. I think you have misunderstood something seriously. Please, this is the absolute worst argument from you as of yet. You can't seriously believe this. Also note that the code that I wrote above was supplied under the LGPL, so I don't see how you can claim that I violated the LGPL. The company that wrote the proprietory library neither knew about the me nor about Wine so how can they have violated the LGPL. > > They had a goal and I'm sure a lot of competent people did the best > > they could be accieve it. > > > > However, you can do the impossible no matter how hard you try. > > Strangely there are thousands of people, including lawyers, who seem > to think that the LGPL does what it claims to do. If the problems are > so obvious, how come no one else sees them? Could it be that maybe, > just maybe, it is because all these people are right and you are > wrong? Could it be that they rely on that that the dotrine of derived work will save them from people trying to use the lopeholes in the licenses?

2 1

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

19 Dec '01

> Now, here's another something to mull over. We've pretty > much established > that you could statically link something proprietary with > something LGPL. > One question I have is how much of the library are you > allowed to use. > Alexandre mentioned that while the CryptoAPI example would be > a pretty > clean-cut allowed case, a proprietary CreateWindow would not > be allowed. > His argument was that because it would necessarily use > internal functions > and data structures that it would be a derived work and thus > subject to > the license. > > I think what Patrick has been trying to get at is that that > is not very > clean-cut and that in fact there is little to no precedent on > what exactly > a derived work is. If Alexandre is indeed correct then we > are pretty well > protected. If it is at the opposite extreme and anyone could > statically > link in proprietary versions of functions then we have very little > protection and it really makes it not worth it to go LGPL. At > least that > is what I think Patrick has been trying to say. Yes, approximately. > Let me put it to you the way I see it. Whether a function or data > structure is exported or not does not matter. It would be trivial to > declare an internal structure or function as exported and thus the > proprietary function is simply making use of the library and > therefore not > a derived work. Indeed... > That is my argument that avoids all of > Patrick's doctrine > of derived work crap and gets right down to the fact that > it's trivially > easy to make your work fall under the work that uses the > library category, > so long as it is a seperate object file. That is, to put it > in Slashdot > terms, a "Big Gaping Hole(tm)" ..but you are wrong that just because it falls under use, it is clear from the doctrine of derived work. That is the main problem, I have with it. That it might potentially turn somekind of uses into derivation and thus potential infringement of copyright. > Look at section 5 in the LGPL. If you use (from the header > files) only > numerical parameters, data structure layouts and accessors, and small > macro and inline functions then regardless of whether it would be > considered a derived work it remains a work that uses the library. > > So that's great, after I had pretty much convinced myself > that the LGPL > was still good despite some minor problems, I now find myself > realizing > that the LGPL has major holes written into it! Welcome to the club. :-) > And so I emphasize my original statement now. The only thing > the LGPL > really prevents is the direct use of the source code. Anyone > wanting to > release a proprietary implementation of any function can do so fairly > easily simply by 1) writing that particular function from > scratch, and 2) > keeping it in a seperate object file. Agreed. > > > Try reading section 2C of the LGPL and tell me how it's good for > > commercial > > > companies. > > > To respond to Roger: I fail to see how 2c makes any > difference. It only > applies to derived works and only means that you have to release the > code. Yes, it only applies to derived works, but since it is pretty unclear what a derived work is makes it quite unclear for commercial commpanies what that are legal forced to release or not that can't possibly be good when they are deciding whether to use Wine.

2 1

[SHrinker] gdb still doing funny things
by Robert Baruch 19 Dec '01

19 Dec '01

I got around the problem of gdb unprotecting the write protected page by not setting the breakpoint until after the write fault occurs. When I stepped through the Shrinker exception handler, I got to the point where it calls ReadProcessMemory with a handle of -1 to get the 8 bytes around the EXC_CallHandler's call. ReadProcessMemory fails with an ACCESS_DENIED, and trips a landmine. 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: read_process_memory() = ACCESS_DENIED { data={} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000000 ret=0075f1c3 However, when I run wine alone, without gdb, that particular landmine is not tripped: 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: *attached* 0806d9e8: *signal* signal=19 0806d9e8: read_process_memory() = 0 { data={ff,75,08,ff,d1,64,8b,25} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000001 ret=0075f1c3 BTW, the data returned by ReadProcessMemory is correct, and also will not trip the "Have I been called from Microsoft's NTDLL.DLL method" landmine. I'll have to think about this for a while, how to use gdb without getting ACCESS_DENIED for ReadProcessMemory. That usually means going off and doing something else until an idea hits me. --Rob

2 2

[Shrinker] Modified EXC_CallHandler
by Robert Baruch 19 Dec '01

19 Dec '01

Well, the assembly-coded EXC_CallHandler works (to my surprise), with a little modification from what I described because after all, no plan survives contact with the enemy. However, we're still getting hit by one of the landmines in Shrinker. The awful thing is that I can't debug this easily with gdb. The first exception that's supposed to take place is a write fault to the code area. But if I set a breakpoint in the process's code area, gdb is going to remove the write protection from the code area because, I guess, it needs to put a breakpoint in there (I thought it would use breakpoint registers instead of int $3?) Anyway, I don't want to release the EXC_CallHandler code until I find out which landmine we're hitting, since I can't be certain the rest of EXC_CallHandler works -- the stuff past calling the exception handler. But if you're interested in a morbid "I-love-assembler" way, here it is: static DWORD EXC_CallHandler( EXCEPTION_RECORD *record, EXCEPTION_FRAME *frame, CONTEXT *context, EXCEPTION_FRAME **dispatcher, PEXCEPTION_HANDLER handler, PEXCEPTION_HANDLER nested_handler) { DWORD tmp = 0; __asm__ __volatile__( "push %1\n\t" // ebp-1c = nested_handler "push %2\n\t" // ebp-18 = handler "push %3\n\t" // ebp-14 = dispatcher "push %4\n\t" // ebp-10 = context "push %5\n\t" // ebp-c = frame "push %6\n\t" // ebp-8 = record "push %%ebp\n\t" // ebp-4 "push %%ecx\n\t" // ebp-0 "movl %%esp,%%ebp\n\t" "movl 0x18(%%ebp),%%ecx\n\t" "pushl 0x1c(%%ebp)\n\t" "pushl %%fs:0\n\t" "movl %%esp,%%fs:0\n\t" "pushl 0x14(%%ebp)\n\t" "pushl 0x10(%%ebp)\n\t" "pushl 0x0c(%%ebp)\n\t" "pushl 0x08(%%ebp)\n\t" "call *%%ecx\n\t" "movl %%fs:0,%%esp\n\t" "popl %%fs:0\n\t" "movl %%ebp,%%esp\n\t" "popl %%ecx\n\t" "popl %%ebp\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "movl %%eax,%0\n\t" : "=&g" (tmp) : "g" (nested_handler), "g" (handler), "g" (dispatcher), "g" (context), "g" (frame), "g" (record) : "memory" ); return tmp; } --Rob

2 2

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

19 Dec '01

> David Elliott <dfe(a)tgwbd.org> writes: > > > Now, here's another something to mull over. We've pretty much > > established that you could statically link something > proprietary with > > something LGPL. One question I have is how much of the library are > > you allowed to use. Alexandre mentioned that while the CryptoAPI > > example would be a pretty clean-cut allowed case, a proprietary > > CreateWindow would not be allowed. His argument was that because it > > would necessarily use internal functions and data structures that it > > would be a derived work and thus subject to the license. > > Actually the fact that they are internal or not doesn't make a > difference, I wasn't clear on that point. Agreed. It doesn't matter. > If your code is linked to > the library it is considered a derivative work, and by default the > whole has to be released under the LGPL. Now there are cases where you > don't need to do that: one is if your app is considered a work that > uses the library (section 6), the other is if you are placing your > code side-by-side with the library (section 7). > > So if you don't want your code to fall under the LGPL, you have two > choices: one is to put it in some part of your app that only links to > the library, but in that case you cannot have other parts of the > library depend on your code (this is the square root example). This > would work for the crypto API, probably not for CreateWindow since the > rest of user32 needs CreateWindow. Well, only if it made CreateWindow work different that it was supposed to. Note that supposed to it pretty vague, however, if you leave it out you can't even apply bug fixes since it would change the behavior. > The other solution is to put your code side-by-side in the library; > but this is only possible if your code is not covered by the license, > which means it isn't a derivative work of the library, which in turns > means it cannot use any functions or data (exported or not) of the > library. This would work for the crypto API as long as you don't use > anything from the rest of libadvapi32. So what you basicly saying is that a Crypto API that is a part of ADVAPI32 can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can. Isn't that quite an absurd state to make? Or rather the perfect illustration of the absurdities of LGPL. Of course, I assume that you by use a function mean call a function not cut and paste from a function.

3 2

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

19 Dec '01

[David Elliott explaination snipped] > Thanks for explaining what Patrik has been going on about. Yes, it was quite a good explaination. However... > In summary: > > Consider a proprietary application which ships as a > proprietary library > which is statically linked with LGPL libraries at install > time in a way > that lets users supply new versions of the LGPL libraries. > This lets them > fix bugs in the LGPL'd code and thus in the proprietary app. > The harm you see is that a vendor could, once he found a > Winelib function > with a bug, simply do his own clean-room implementation of > that function, > and use it instead of the Winelib version of it, and keep the > improvement > to himself -- which would also deprive the user of the ability to fix > bugs in the proprietary reimplementation of that particular > WineLib function. ... while this is an entirely possible scenario there is little profit in doing what you suggest so while it is one of the holes in LGPL it is not really a problem in pratice I think. No, the problem as far as Wine is concerned, is that somebody might do proprietary extension of some important part of Winelib that enough people want so much that most people uses the proprietary extension and under such circumstances there won't be any incentive for people to work on Wine. However, I neither believe this to be true, nor do I believe that the LGPL will help to stop it other than very marginally.

1 0

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

19 Dec '01

> >> 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. :-) > > What problem? A GPL program is the same as any other - GPL > protects the > code, not the use of said code. Indeed. It is a not a use license. However because of the doctrine of derived work that GPL depends upon, some use (read: linking) are considered derivation and thus a possible violation of the GPL. > There's nothing to stop a > GPLed program > such as, say an amiga emulator (UAE) running the emulated non-free > software. As geoffs example rightly points out. You think (read: hope) that it is not so because it would be quite absurd wouldn't it? However if the doctrine of derived work is strong enough to prevent want the GPL hopes it will prevent namely linking, I see no reason to assume that emulation would be considered differently. After all from a technical point of view essentially that same things that happends. > And in any case, we are talking about the LGPL - a totally different > matter. Not entirely whatever power the LGPL have also derives from the doctrine of derived works eventhough is doesn't try to use it to the extent that the GPL does. > Which is my response to Rogers comment above - sure the GPL > prohibits linking with a nonfree component. Yes, but what is linking? Don't you understand it is the vagueness of linking that is the problem. This is further made worse by that fact that the doctrine of derived might possible, and are very like to do, at least to some extent, place some kind of limit on what linking legal extends to. > That 'closes' the > source and > provides far too many ways to cheat the license. > > The LGPL allows dynamic linking with a nonfree component. > Remebering that > the LGPL is meant to apply to LIBRARIES (hence allowing a > libssh library > to use nonfree crypto routines for example) not for an application. You can cheat with both the GPL and the LGPL at I have tried to illustrate in earlier mails, but the LGPL at least as applied to Wine is a gaping hole, that hardly provides any protection at all.

3 5

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

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > The problem is the doctrine of derived works. Nothing else. > > And to you truly believe that our choice for Wine's license > will have any > influence over the doctrine of derived works? Of course not. But it _will_ effect our abillity to attract companies. Eventually I think the courts, possibly with the help of the politicians will realize that only a very weak doctrine of derived work could every service society without introduces needless uncertainties and/or absurdities. For example I think that some cases where the doctrine of derived work has been used like IIRC in some case considering unauthorised Star Trek books. Using the Star Trek characters in a book without Paramounts(?) permission, would be much better served using trademark law instead. This might or might not require changing trademark law but that is a different issue. Don't expect it to happend soon though. > If not, there > really is no > point in discussing this any further. If yes, than even more > so should we > chose the LGPL, as it will help settle the debate the right way. See reply in previous mail.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2001