wine-devel December 2001

wine-devel@winehq.org

86 participants
179 discussions

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

Re: Installshield 6 (inter-proc) patches
by Roger Fujii 18 Dec '01

18 Dec '01

Alexandre Julliard <julliard(a)winehq.com> wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > As for the license of Wine, I was among the ones opposing the LGPL last > > time it was discussed, and I have not changed my mind. I feel that Wine is > > most widely useful if it keeps the X11 license, and usefulness is more > > important in my mind than making it 50% harder for companies to "steal" > > the code. If X11 is so bad for large projects such as Wine, why is the > > largest project of all, XFree86 (and associated projects like DRI), still > > using it, even though its maintainer would have the power to switch to > > e.g. the LGPL or even GPL with a snap of the fingers ("sublicensing" it)? > > A thing to keep in mind is that X11 got almost killed by licensing > issues and the proliferation of closed source vendor versions. You understanding of X11 is pretty flawed. X11 had closed parts of its implementation practically from the very beginning. Look at the original X11 contributers. It was DEC, SUN, IBM... The main reason for the dry spell was that it became a mature product. Why tinker with stuff that basically works? Vendors, quite unlike the GNU people, really resist changing things without a good reason. I think the current interest in the X project was due to the advent of so many graphics cards plus 3d/video. Look at gnuemacs - it's GPLed, and had a really long dry spell. Was the lack of interest the result of the licensing? > If the XFree86 team hadn't picked it up, there probably wouldn't be a free > version of X11 available today. What are you talking about? What do you think is sitting on www.x.org? > This is something that could happen to Wine; Wine should be so lucky as to be accepted like X11..... > and if it does happen, will we find enough people to do what > XFree86 has been doing for X11? Maybe, and maybe not. When I hear > people like Patrik saying that it's OK for parts of Wine to become > proprietary because we can't do everything anyway, I'm worried. If wine was even CLOSE to being complete, I would agree with you. But given its current state, I think that a *gpl license would just discourage companies from even looking at wine (I can't see why any company would like *GPL over X11 so long as they are not the givER - this is not to say they won't accept *gpl, just as to what the preference would be). And given that IMHO, a lot of wine work to be done (looking at Direct* and other M$ stuff) falls under the unpleasant column (ie, most people won't do this for fun), discouraging commercial work doesn't seem to be the way to go. -r

5 6

Re: Installshield 6 (inter-proc) patches
by Mike McCormack 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. Mike http://freshmeat.net/browse/16/?filter=&orderby=popularity_percent+DES C > 0. Isn't Wine's best interest to evolve and develop as fast as it can? ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

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

18 Dec '01

> > 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. > > > 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. > > You really make it sound like the LGPL is some kind of unexplored > > wilderness that we shouldn't venture into. 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. > > > Agreed. The LGPL is a very well-written fairly clear > license. There are > some borderline cases as mentioned, but this does not mean > that we should > thus throw the possibilty of LGPL completely out the window. 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.

2 1

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

18 Dec '01

> David Elliott <dfe(a)tgwbd.org> writes: > > > The crypto part of ADVAPI32 was the example I used. Let's > say I were > > to write a CryptoAPI implementation as a set of seperate > source files. > > With the LGPL I could compile all of that stuff and refer to it as a > > library. What is a library? I would say one or more object files > > linked together form a library. I could then take my CryptoAPI > > library, link it with the rest of Wine's ADVAPI32 and distribute a > > libadvapi32.so that could be dropped into a wine install. > > If it is a completely separate library that doesn't contain portions > that are derivative work of ADVAPI32, then yes you can do that. But > you cannot for instance decide to reimplement CreateWindow and not > release it simply by putting it into a separate file, which was what > Patrik suggested; because your new CreateWindow will necessarily use > internal functions and variables of USER32, and thus would be > considered a derivative work. It takes more that use to be considered a derived work, but the doctrine of derived work is central to the discussion. One thing that is very important to note is copyright only protects expression not fact or ideas. In this case we are talking about use which I guess is better to talk about in terms of functionality. Functionality on the other lies closer to fact or ideas than to expression so I would consider it doubtful for the courts to extend the doctrine of derived work to protect this.

2 1

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

17 Dec '01

> Alexandre Julliard wrote: > > > > Gavriel State <gav(a)transgaming.com> writes: > > > > > There are several factors to that equation, and I'm > afraid we don't have > > > a firm ETA yet. > > > > Well, this worries me. It sounds like you are planning to > do the same > > thing you did with your DirectX stuff: by making the code > available on > > your site, and promising to release it at some hypothetical future > > date, you remove all incentive for other people to spend time > > improving the main Wine, thus ensuring that it always lacks some > > features. I don't like this at all. > > > > If you can't/don't want to release your code, I'd strongly suggest > > that you reconsider your strategy of making it publicly > available. If > > it was only available to paying customers, there would at least be a > > reason for other people to work on a free implementation. But if > > everybody who needs some feature in Wine can simply download WineX > > instead, no one will spend time re-implementing that > feature. This is > > beginning to seriously hurt the project, and we need to > find a way to > > address this issue. > > The DCOM issues had been ignored by other Wine developers for YEARS > before we came along. Yes, but that is because it hasn't been needed for anything but obscure application until now. > It's not at all clear that our work there has > discouraged anyone else from working in that area. Granted. > To say that > our work is preventing anyone from doing a free version of DCOM is > completely incorrect. To the contrary: we have already contributed > substantial amounts of this code to the public tree - thousands of > lines, in fact. That can only help anyone with a sudden and > unexpected > interest in recreating our work. That is absolutly true and would make any decision not to release it under a free license even more strange. Note however that I'm not accusing you of not releasing it. Not yet, but I reserve the right to do so in the future. Anyway, see below. > Now, it is our firm desire to see *all* of that code end up > in the main > version of Wine. The fact is, unfortunately, that we simply cannot > afford to give everything away as soon as we write it. We only got a > minimal implementation of the DCOM code working six weeks ago. We are > not a rich company, with millions in VC funding to burn; this > means that > our DCOM work has to remain under the AFPL until we can find a sponsor > willing to defray some of the tens of thousands of dollars it cost us > to develop it. I think that you look a things the wrong way. Think of the expense as an extra cost you pay for being early to the market. Sure it won't make your accountant much happier but thats life. :-) What I mean by that is that the DCOM code aiming to get InstallShield to work is not really something that has very much to do with the product you that your customers want to buy. Installation is done only once and can be made in the real Windows if you dual boat and beside it is really something that Wine should have supported already. In short, it was something you had to do because Wine was not mature, because you wanted to be early to market and holding it as proprietary code are unlikely to give you any advantage for very long. If you won't release it somebody else will implement it before long. > Furthermore, we are committed to writing quality, robust > code. We don't > think it's in anyone's best interest for the current version > of the code, > which is effectively limited to the requirements of > InstallShield, to be > used as the basis of future DCOM related work. We in the midsts of > working on a much more flexible architecture which will permit more > than just typelib based proxying. > > I don't really think this affects individual users at all. They can > simply download and use the code from our website, or apply the > necessary patch to WineHQ wine. They can even redistribute it all > non-commercially should they wish. > > Without a doubt, we are committed to the Wine project and have already > contributed a great deal of code to support it. However, to > maintain the > quality and integrity of the project, we stand by our decision of only > contributing code when it makes sense to do so (in order to > allow us to > continue developing quality code) and when it reaches a > certain minimal > degree of quality. Yes, I fully understand that, I'm grateful for all you have done and I'm not making any accusations right now. However I reserve the right to do so in the future. > Publicly questioning our ethics is certainly not the right solution > nor is it in the spirit of the project, especially given how much we > have supported it to-date. We believe that we ARE doing the Wine > user and developer community a service and propelling it further. I don't think Alexandre is questioning your ethics. I think he is question what relation the Wine project should have with you based on praticial issues and not on ethical issues at all. In short: Should the Wine project wait until you release or should it not? > The > only people that our lack of haste in contributing code back really > affects are organizations that want to make immediate commercial use > of the code. These organizations include the one you work > for, and its > clients. If you want to see the DCOM code Wine-licensed soon, you > need to talk to your boss and your clients, not me. :-) I fully understand that you wish to take every opportunity to get some extra income but I think your analysis is partly wrong. Sure it is possible you might get some sort of one time payment from somebody if you are a little clever, but realize the following. A significant part of your potential customers consists of, I guess, people who would very much like to not to dual boot any longer and their first priority is that their normal productivity applications installs and works. Games are their second priority and so as long InstallShield doesn't work in normal Wine you risk losing them since they will continue to dual boot and presumably continue to play their games in Windows. > At this point, I think it would be best if we were to take this > discussion off-line so that we can determine a solution that works > for everyone. For any discussion concerning milking some money out of CodeWeavers or their clients, absolutely. Not my problem. :-) However one important problem that really can't be discussed off-line, is what your relation you wish to have to the Wine project. In fact, it can't be discussed at all, only your actions can determine it. I will be blunt: Do you see yourselves as a complement to Wine or a competitor to Wine? Because not releasing important core code like code needed to install important applications especially non-games might be interpreted as really wish to compete with Wine instead of being a completement. Note again (the third(?) time) that I'm not accusing you of anything, at least not yet, but I wish to point out that it might hurt your public image if people see as a competitor instead of a complement to Wine. Being vague and saying: "There are several factors to that equation, and I'm afraid we don't have a firm ETA yet." will not help your image.

10 16

← Newer
1
...
6
7
8
9
10
11
12
...
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