wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

[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

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

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > 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. > > This is a very good point which in fact _promotes_ the LGPL. Not really. See below. > Let me > explain. > > There are two possibilities for copyright law: > > 1. The copyright law becomes stronger. > 2. The copyright law becomes weaker. It is much more complicated than that, but fair enough, lets assume this for the sake of argument. > I will assume, for the purpose of this discussion, that: > > A. Wine contributors wish for 2. I, for one, am very worried about the > direction of law these days (see: software patents, DCMA, > SSSCA, etc.) and > I fully agree with Gerard that it's an unfortunate situation > B. There doesn't seem to be any negative feedback loop that > will prevent 2 > from happening. That is, it is very probable that 2 _will_ > happen sooner > rather than later. I agree. > Now, let's just go through the possibilities: > > Let's look at copyright law. If our dreams come true and 2. > will become > reality, then Wine will be in no worse situation than it is > now in. The > LGPL will effectively become BSD, i./ii. become irrelevant, > and we're all > happy. This scenario is possible, but (unfortunately) not probable. Yes, but in the mean time it is likely that we scare away potential good companies and regardless of the LGPL be effected negativly by bad companies using the lopeholes in the LGPL. > On the other hand, if society moves towards 1., then the LGPL is the > perfect tool because it turns the stronger copyright law > against itself. > In this case, it is the only moral/ethical thing to do: to > turn an evil > instrument against itself, thus provides the > _negative_feedback_loop_ that > is missing at the moment. > > Moreover, if you are worried about the fact that open source > software is > so influential that it can influence the debate over the doctrine of > derived work, then even more so should we opt for the LGPL > because in that > case we would contribute to a negative feedback that will deter > politicians from making the copyright law arbitrarily stronger. So you want Wine to be the catastrofic failure, that was used to change copyright law. You can't seriously want this.

1 0

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

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > > 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. > > But if it's not, it's within a small constant factor to > replace the rest > with prorietary code and not release anything. See, if the > DLL is mostly > implemented, the changes are not that big, so they should be > contributed > back. If the DLL is mostly stubs, just rewrite the entire > thing, you're > not wasting that much effort in the first place, and you can choose > whatever licence you want. DirectX and DCOM fall in this cathegory. I have use the Crypto API as an example several times that to illustrate that the DLL:s isn't a relevant protection boundary for the LGPL, even Alexandre seems to accept this. In any case if the DLL is mostly implemented there is very little reason for a company to try to enter the market, it is simply to dangerous, so I don't see the problem. > > > I fail to see _any_ moral/ethical/philosophical problem with > > > this. Do you? > > > > Perhaps you have been more enlightend now. > > Focusing on obscure issues only is anything but enlightening. :) Well, the concrete issues like do we scare potential companies that wants to help way quite hard to argue about in a objective way and I do not really like subjective arguments. I leave them to for example Gavriels that IMHO has done a good good job at that. I have been trying to approach the problem from the other side, that the LGPL doesn't provide much protection at all.

1 0

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

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > You forget that some "independent"(*) parts like the Crypto API are > > parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. > > This is ridiculous: it is one of the few exceptions, it is > simply silly to > bring the Crypto API into this discussion. If this the Crypto > API is the > only problem, we can fix it in multiple ways. It is not the only problem it is just a symptom of the gaping hole in LGPL. > > > At this point, I would like to know if people agree up to > > > this point. > > > > I don't. > > That's informative. WHAT don't you agree with? In fact, if we > can agree on > WHAT we disagree, I think it would be a great step forward. "I don't" primarily refered to the previous argument concerning "independent"(*) parts. > > > 0. Isn't Wine's best interest to evolve and develop as fast > > > as it can? > > > > Yes. > > This is a fundamental point. A project like Wine is just like > a living, > breathing creature. And being need to be selfish to survive. Not too > selfish, but it is essential that they have a certain level of > selfishness. Your analogy is flawed, Wine is not living in the meaning that it, if it is to unselfish can die. The mechinisms are entirely different compared to normal life. > In Wine's case, that has to be: 'the licence > should be such > that it would maximize Wine's development'. Yes, but I don't believe that LGPL does, that I have being trying to explain in I forgot how many mails. > > > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? > > > > No, not nessararily. See different mail. > > 1 follows from 0. Period. You can not agree with 0 and > disagree with 1, no > matter what you write in other emails! :) Again, THE SPIRIT > of LGPL, not > the letter. Again, the spirit is: 'if you improve Wine in minor ways, > please contribute back your improvements'. Yes, and the key is minor ways and I believe that is a absolute non-issue as I have explained before. There is no profit in holding minor improvements. > > > 2. If so, why shouldn't we formalize it in the license? > > > > But it isn't nessarily so. > > And why is that? Quite the contrary, because: > > -- For people that contribute back, would chnage nothing > -- For people that don't contribute their changes, it's no > good to us, so > we don't care (which follows by point 0). > > Tertium non datur. That is, there's no other case. QED. OK, since you bring mathematics in to it, I will try to explain in mathematical terms: "The set of people is not invariant over a license change." In fact the set of people are likely to be considerly less. While I have no strict mathematical proof of that, I especially point to Gavriels' reply concerning Corel and Transgaming.

1 0

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

19 Dec '01

> On 2001.12.18 05:09 Patrik Stridvall wrote: > [snip] > > Dimitrie O. Paun wrote: > > > 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. > > > [snip] > > That's a piss poor example. The statement that something > would be from > each according to his abilities and to each according to his > needs sounds > to me at first glance like it would suck. And you don't have > to dig too > deeply to figure out why that would suck. But maybe that's > because I am > an American capitalist though and through and that blatantly > conflicts > with my core values that everyone should do for themselves. Perhaps. However, I think that if you move to Europe, especially northern Europe you will find that people have different opinions. While most people there certainly do not believe in Communism and to various degrees understand why is doesn't work, people are more inclined to be believe in this principle. Actually I think the reason for this is more Protestant Christianity than Communism, but why is not really that important. > And to get > off topic, why is that? Because that's what everybody will > do anyway, > might as well work with that rather than pretend that it is otherwise. So there is no such thing as morality? > This has lead me to another thought. We cannot pretend that > people are > going to release code back to Wine under the X11 license. > However we can > realize the obviousness of the truth that given the chance > people will > take whatever they can and give back nothing in return. Some > folks will > give back because it may make more sense to do so than to > not. But some > folks will be more than happy to take the whole codebase for > their own > good and provide nothing in return. > > We need to stop living in the dream world that everyone who > uses Wine will > contribute back. I have no illusions that everybody will. However there is no need to scare away potentially good companies by using a hard to understand license. > Yes, it is true that Corel, Codeweavers, > TransGaming, > etc. have given a lot to Wine. None of them was or is > required to give > anything. And yet they did. That is kind of shocking for an American Capitalist, isn't it? :-) > If the goal is to let people know that if they want to use > Wine then they > need to contribute back, then the only choice is to put that into the > license. By "use" I am obviously not referring to simply porting an > application using Winelib. I am referring to incorporating > source code > from wine into their own products. > > This is exactly what the LGPL was meant to address. And if they borrow some obscure functions, they might even supply some bugfixes in hope that at a later stage there will be more bugfixes waiting for them when they borrow again (resync) a year later. And if they don't, who has been hurt? If Wine was LGPL:ed they certainly wouldn't have borrowed at all, so no chance at all of getting any bugfixes back at all. > I recall Uwe's usual .sig which is: > Free Software: if you contribute nothing, expect nothing. Indeed and what is your hypotetical sig? "LGPL:ed Software: if you contributed something, use the law as a tool to force others to contribute as well." > Maybe we should have one for wine: > Wine: If you contribute nothing, well, there isn't shit we > can do about it > since we are X11 licensed. I don't think that one came out the way you hoped. Try again.

1 0

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