wine-devel

wine-devel@winehq.org

5 participants
84465 discussions

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

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

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