wine-devel

wine-devel@winehq.org

84463 discussions

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 17 Dec '01

17 Dec '01

At 02:20 PM 16/12/2001 -0800, you wrote: >Well, this sounds like an argument for the LGPL. There is absolutely >no guarantee of stability with the X11 license; anybody can start a >Wine tree under another license, and if developers think this is a >good idea there is nothing I or anybody else can do to prevent it. Theoretically yes. The project leader has a much higher chance to do it successfully in fact. Since he is fixing the rules in the first place he has to be more responsible IMO. >It's simply part of the existing rules that the rules can change. trusting people is always a problem, yes. >You know, that's exactly why we are having this discussion. If I was >as selfish as you seem to think, I could change the license today >without asking anybody. > I'm not doing it precisely because I *do* care >what people think, and I won't make the change unless it is acceptable >to at least a large majority of the people affected by the change (and >yes that includes Transgaming). it's for them (and possibly others professionals) to say then. Gerard

3 2

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

17 Dec '01

> It would help us in several ways. First, since we've > always effectively > treated the Wine code base as though it were LGPL, we would gain > the protection that the LGPL offers. If someone else takes > the code we've > worked on, and competes with us, we would gain back > any improvements that they make. For example, if Wine had been LGPL, > then Transgaming would have been oblidged to release > Installshield fixes > back > (after all, they do follow on work that we did). Not according to the David Elliot and I agree. Even according to a strict interpretation of the LGPL they would just have to provide their code in seperate files so everything could be relinked when new versions of Wine was released. > With better > InstallShield > support, for example, our CrossOver customers might have a > wider range > of plugins > that would successfully install. This is a pretty minor problem; I > can't think of a > significant plugin affected by this. :-) Of course you claim that. Even if it was a problem you probably wouldn't admit it since it might raise to price in any possible negotions with Transgaming. :-) > Further, I think I > understand why > Gav has > has hesitated on this issue, and I firmly believe that Transgamings > intentions > with regards to the Wine project are honorable and good. As said above the only thing it would enforce would be file seperation so you more easily could integrate the part from Transgaming in your CrossOver product. Of course distributing it after that would violate Transgamings copyright, so you really need their permission after all. The point is LGPL wouldn't help you here. > However, I can imagine alternate scenarios where we could > have all of > our hard work > used against us by others who are more ruthless than Gav, and so the > LGPL would at least offer us some protection from that threat. Does it? It seems you overestime any advantages of LGPL. > A second benefit is simplicity. I spend a lot of time discussing > license > issues with my customers, and fighting very difficult battles to > preserve the integrity of the Wine code base (and while that sounds > noble and all bear in mind that a single, coherent source > code base that > I can fully > use is a key part of my business strategy). So, if the > license were LGPL, > my negotiating requirements would be simplified. In fact, I > would feel > free to > encourage my clients (and my company) to ruthlessly take > advantage of every > possible opportunity to create competitive advantages, because I feel > that the LGPL would protect the integrity of Wine. The same question here: Are you sure you are not overestimating the protection LGPL provides? > Of course, there are a number of downsides. First of all, it is > possible that > I would have fewer clients; the LGPL is complex license, > and it's core premise can deter many people. That is one of my objections as well. > It is widely > believed in the > Wine community that Corel would have never touched Wine if it had > been LGPL, and Corel's contributions to Wine were very significant > (the irony of course, is that AFAIK, Corel treated Wine as though > it were LGPL). Side note: I am one of them. > Second of all, the LGPL does, oddly enough, take away some freedom > on my part. Today, I have a full range of choices available > to me with > every product I release or help a client to build. After a > switch to LGPL > (and after enough time had passed for the LGPL'd pieces to be > significant), I'd have to be very cirumspect every time a > public release > of a product was made to be certain that I had all of my licensing > ducks in a row. Exactly, it increases your cost of doing business. > For example, right now, we don't provide a copy of the > source code contained within our CrossOver Plugin Wine tree. The only > changes we have not published back into the main WineHQ tree are > ones specifically required to interoperate with a > Linux/Netscape plugin. > The changes we made to Wine would never have been accepted by > Alexandre as being good or generally useful patches, and yet > they could > conceivably give someone who wished to replicate our proprietary > Linux plugin code a good insight into how to go about doing > so. To be > honest, > we sweat a lot of blood and tears to learn how to do that > right, and it > would > hurt if someone were able quickly knock off CrossOver Plugin > because we were > forced to show that code. To be honest and actually say something in support of LGPL: This wouldn't be required even with a strict LGPL interpretation. You would have to provide object files for relinking but that would not be much worse than providing the binary. Reverse enginerring it will be almost as hard. > On the other hand, we also had a > heck of a lot > of work on the Plugin code that has nothing to do with Wine, and I'd > like to see someone knock that off quickly <grin>. :-) > With all that, speaking on behalf of CodeWeavers, I would neither > call for > nor oppose a switch to the LGPL. Since that change would > impact me and my > customers somewhat slowly, I think I could make the necessary > adjustments in time. Perhaps the clarifications above might make you change your mind? > The most important thing is for us to continue to have a vital and > thriving Wine community. Agreed. > Finally, speaking strictly on a personal basis, and with > no corporate > considerations whatsoever, I would welcome a change to the LGPL; > I have always preferred it to BSD style licenses (and to the GPL, > for that matter); with LGPL projects, I feel more certain that I know > exactly > where I stand and how my code will be used. Well, perhaps it is because you misunderstood what the LGPL means?

6 7

Wine and Baldur's Gate
by Ian D . Stewart 17 Dec '01

17 Dec '01

Well, Now that I've made it through the actual install, I figured I'ld take Baldur's Gate for a spin. The main screeen, where you select to play the game, change the configuration, etc, comes up fine. There's a slight pause after clicking 'Play' while BGMain.exe starts and X is set yo 640x480 (I'm guessing this has something to do with DETACH_PROCESS?), but that's no biggy. The opening credits and movie play just fine. I'm able to create the main character without any noticeable problems. The first 'problem' I ran into was at the opening of the 'Prologue' chapter. Under windows, a narrator's voice reads the opening text as it scrolls across the screen. Under wine, the text is scrolling, but sans naration. A bit annoying, but no biggy. The real fun starts when the game actually begins. First off, the sound, when there is any, cuts out quite a bit, with no apparent rhyme nor reason. Secondly, the left and bottom panels are covered by the main section. You have to click on the various buttons to make them display. The third 'error' appears to be related to X's virtual desktop. Moving the cursor to the left or bottom side of the screen moves the 'viewport' away from the window, instead of scrolling the view in the Baldur's Gate window. After shutting down Baldur's Gate, I noticed a whole slew of error messages in the xterm window I launched it from. Here are a few examples: fixme:module:CreateProcessA (BGMain.exe,...): DETACHED_PROCESS ignored fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403f8034,00020021,3):stub fixme:dsound:IDirectSoundBufferImpl_QueryInterface Unknown GUID {31efac30-515c-11d0-a9aa-00aa0061be93} fixme:ddraw:Main_DirectDraw_CreateSurface App didn't request a valid surface type - assuming offscreenplain err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX Any help in getting any of these issues resolved would be greatly appreciated! Thanx, Ian

2 3

Big Bummer for running Shrinkered files!
by Robert Baruch 17 Dec '01

17 Dec '01

The plot sickens... Here's the background info. I have a file, power-structure-demo.exe which can be obtained from www.write-brain.com. Uwe has another file, tar2001.exe. Both have been compressed by the commercial Shrinker utility. When these exe's are run under Wine, Wine will spin. A look at the +all debug messages shows that the app tries to write into its own code area in order to purposely throw an exception. Kind of like this: void my_function() { try { *(char *)&my_function = *(char *)&my_function; } catch (access violation) { } } Shrinker was written using Visual C++, since this article at MSJ (http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0197/exception/exce…) describes the code's exception handler perfectly. The Visual C++ exception handler, which gets control of the app from ntdll.dll, first calls a filter function corresponding to the catch clause to see if the handler associated with the catch will handle the exception. If so, it passes control to that handler. Otherwise it moves to the next catch clause. Here's the weird thing. The filter function looks at the code which called the exception handler, which is in ntdll.dll. Under Windows, this code is FFD1 (call ecx). The filter function compares that code to the call ecx instruction. At first the only difference between Wine and Windows is this comparison. A register gets decremented if the comparison fails. However, then the function calls ReadProcessMemory with a handle of -1 (what does that do?) to read 8 bytes, and compares some of the data returned to FFD1, and to 648B25 (which is the beginning of the next instruction after call ecx, mov esp,fs:[00000000]). Things rapidly deviate from there, resulting in Wine spinning and Windows continuing execution. Given that the application appears to look into ntdll.dll's code to compare it against essentially a magic number, is there any hope of getting Shrinkered exe's to run under Wine? --Rob

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 16 Dec '01

16 Dec '01

At 02:09 PM 16/12/2001 -0800, you wrote: >Gerard Patel wrote: >> I'd have no objection to Gpl *if* people having invested >> money in Wine success accept the move without problem.... > >I believe Gerard meant to write LGPL, not GPL. >There hasn't been any proposal to the the GPL on >wine, as far as I know. (The GPL might be too restrictive >IMHO.) Yes, correct. I said in my first post that from my (particular) point of view the licenses were similar. Gerard

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 16 Dec '01

16 Dec '01

At 11:35 AM 15/12/2001 -0800, you wrote: >I think that's quite unfair. I have stated that I personally don't >care about games, I don't have a single application that even uses >DirectX. The only reason I think DirectX is an issue is because I see >users complaining that Wine doesn't run their favorite game, and I >want Wine to be useful for as many people as possible. This has nothing to do with license, Transgaming or anything. All that is needed is a developer writing code. If there is none, nothing is written. Before Lionel Ulmer, there was no big DirectX game that could be played under Wine I think. Now Lionel is not contributing anymore - did he say to you privately that this was because of Transgaming ? There are many other top developers who have faded away like he did since I began on Wine, so it could be for many other reasons. Now, game users can as well subscribe to Transgaming as far as I am concerned. The vast majority of them seem to need professionnal - paid - support anyway. <snip> >> You want to use the Gpl as a tool, but I don't see a lot of respect >> for the philosophy that is behind it. > >I must say I'm quite offended by your comments. The only reason I >raise the issue is because I want Wine to remain as useful as possible >for everybody. <snip> you are the leader of this project since 8 years : the Gpl already existed when you began to work on Wine. You could have switched the license at any time. I don't remember you ever expressing any interest in Gpl for Wine since 3 years I am following - and I have read also quite a few of your interviews. Looking from the outside, this has more the appearances of a knee-jerk reaction, not the result of a long reflection. > What I find even more disturbing in what you said is the allusion >> (when replying to Patrick) to a future tightening of copyright laws, >> a tendency that is in my opinion directly linked to the idea of >> copyright, patents, etc being 'intellectual property' assets, >> and infringers thieves stealing them. You seemed to welcome >> the additional protection it would give Wine. > >Absolutely not, and I don't know how you got this impression. I'd love >for copyright law to get back to sanity, but I don't see this >happening in the near future. Yes, there are a lot of abuses done in >the name of intellectual property these days. Does this mean we have >to let people hurt us and do nothing? You seem to think that users >rights are important, but how are you going to defend their rights if >not by using the only tool that we have, namely copyright law? No, that not what I was saying. If I am here, that's because I think that having Win32 Api outside of Windows is important. User rights have never got in the figure, since it was always acknowledged that people could take the stuff and turn it proprietary. Now that someone seems to succeed, you want to change the rules. Transgaming is playing by the existing rules, the rules you have enforced for a long time. If they are hurting you, that's surprising. They are not hurting me, since I have accepted your rules. What you are planning will hurt Transgaming business plan, by spreading Fear, Uncertainty and Doubt in their business discussions with potential customers. Business plan that they did and implemented in good faith, perfectly conforming to your rules and expecting their stability. I'd have no objection to Gpl *if* people having invested money in Wine success accept the move without problem. I think you should feel more responsibility towards people investing in Wine, not only responsibility towards the project - in other words you, because you are the Wine project. <snip> >I'm not planning to send anybody to jail, and I find that suggestion >insulting. What you are planning I don't know but in this context Gpl seems more a weapon than anything else. What happens when weapons are drawn can be anything. <snip> > I do think that given the lack >of developers, discouraging even a few of the existing ones can cause >a lot of harm to the project. I think that you will discourage one. Gerard

3 2

Re: create more window data structures before calling WH_CBT hooks.
by Uwe Bonnes 16 Dec '01

16 Dec '01

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> The right patch attached this time. Rein. -- Rein Klazes This patch superceded my patch "Check WND structures before accessing", as it solved the problem with encarta99 startup Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: wine-devel digest, Vol 1 #584 - 10 msgs
by Roger Fujii 16 Dec '01

16 Dec '01

I tried to resist.... really..... "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> wrote: > Possibly, however remember that license may not always be for the > application - it is for the product, including any proprietary works not > GPL'ed, or support rights. It is also however true that the GPL'ed > portion of the code may have no other restrictions placed on it's use. other than the restrictions that the GPL imposes... > Going back to the user, how could a user who brought this infringing > product be benefited from the developer suing? Mostly, they may not. In > other cases, they benefit from the fact the code is again public, and they > have a far easier way to see about getting bugs fixed, etc.. the usual > benefits a good open-source project has. Here is a good counter-example. Sun Microsystems developed a toolkit that would convert linux network drivers source to function with Solaris (their proprietary OS). It was just a toolkit. They weren't distributing driver binaries. AFAIK, this use is perfectly legal to do with the GPL. What happens? The GPL GNUts get all bent out of shape because it allowed use of their drivers under a proprietary OS, so Sun yanked it, even though they were not in violation. As a *USER*, this is a negative impact placed on me by the linux developers to exercise my rights, since it impedes my ability to USE GPLed software. > > The usual argument about Gpl, that courts would not accept the > > action because there is no material interest (money) for Linus > > Torvalds, for example, in Linux, is akin to mine, but my point of > > view is not legalistic. > That's a load of bull, of course. A copyright has been violated.. it's > like with a trademark - if someone violates a trademark, the owner comes > very likely to forgoing his rights on that mark for not enforcing it. You are confusing copyrights and trademarks. A copyright is not invalidated due to lack of an active defense. A trademark would. > All I wanted was installshield support! :p All I want is for VirtualDub to work! :) "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > > I feel rather dismayed by the whole discussion. > Maybe this is so because the way you approached the issue. > See, you are concerned with the semantics of things, the 'why', I think the better question is "what" as in what is trying to be accomplished? > centuries. Second, even suggesting that a LGPL Wine will the an evil > 'intelectual property' monster is ridiculous. Just a reminder, most open > source projects are (L)GPL and _that_ community is the only significant > force in today's society fighting against such things as software patents, > DCMA, SSSCA, etc. I would not equate the LPF with the FSF. They have very different agendas. > If we agree up to this point, what is the 'syntax' I was referring to? > Well, IMO this is a stronger Wine that keeps evolving and that has a life > of its own. Wether this is good or not for users it's irrelevant. You probably meant something other than what you wrote here. Existence for the sake of existence is useless. I would presume the point of wine is to provide a WINXX environment on top of x86 platforms. If M$ was sued into oblivion tomorrow, and Wine was a *perfect* 95/98/ME/XP emulator, there would be no need for future development (other than to port to new platforms). The point is that the end goal is to attempt to be the perfect emulator for the USER - not to keep wine going indefinitely. > Some may say yes, others (e.g. Microsoft) may say no. I submit that we that this > goal as axiomatic and we go from there. > > Now, I can argue that this very axiom eliminates any sort of proprietary > licence, but I will not do it since it's understood by everybody here. I > will just look at the two possible options: BSD vs. LGPL. There are two > points in my axiom: > 1. we should try to make Wine stronger (e.g. evolve faster) > 2. Wine should have a life of it's own > > Let's look at the first part: make Wine evolve faster. > LGPL > pros: > -- _far_ bigger code base for sharing/reuse and how to do arrive at this? the modified BSD license is professed by FSF to be compatible with the GPL. > -- _far_ bigger developer base Can you actually say for certain that the gain of developers by using LGPL is less than the loss of developers by using BSD? > -cons: > -- we may lose developers that are opposed philosophically to the > GPL ideals > -- less commercial freedom when using the code base Setting philosophy aside, there are many companies that will not touch *anything* with the letters GPL in it, due to what is perceived (rightly or wrongly) to be its consequences. It is not an overstatement to say that *GPL is a net discouragement to commercial development - the GPL and FSF are openly hostile to proprietary software - PERIOD. Anyone who claims otherwise must also believe that M$ is "encouraging innovation". I can also add a few more cons: -- FSF discourages use of LGPL -- Discourages commercial companies for its use/development. -- Adds more confusion to the mix - LGPL ramifications is less understood than the GPL. > BSD > (just negate the above) > > And now for the second part: Wine should have a life of its own. This is, > to my mind, the crucial part. The problem with a BSD licence is that it > does not ensure that. and how do you arrive at this conclusion? I would say that apache, X11, BSD would disprove what you are saying. > The cool and amazing thing about the (L)GPL is that > it puts in place the right feedback loop (or vicious circle if you > will) that ensures a project a life of its own independent of who's > developing and maintaining it: the bigger the project becomes, the more > people will use it, (up to now BSD and GPL are the same), the more people > will contribute to it, the bigger the project becomes!!! It's the > equivalent for the 'rich get richer', but the currency is not money but > usefulness/code. It is simple, yet brilliant. This is an artifact of "open software". GPL is a *part* of open software - it is not the definition of open software. I don't believe anyone here is advocating making wine non-open. The problem wine has is that it is not a small endeavor like most GPLed software. If you look at the larger projects (gcc, gdb, openoffice, apache, x11, mozilla..), you will find the ones that are most successful long term are the ones with active corporate involvement. With this in mind, I think wine is better served by having its use proliferate and being more complete (even at the expense of having propriatary extensions), than having something that is incomplete but "free". As a side question, what IS the difference between what's available on winehq vs codeweavers? -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

4 4

Re: create more window data structures before calling WH_CBT hooks.
by Uwe Bonnes 16 Dec '01

16 Dec '01

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> hi, My application, girotel v 2.1, crashes during the creating of Rein> its first windows when calling the CBT hooks in Rein> --- ./wine/windows/win.c Wed Sep 29 17:14:39 1999 Rein> +++ ./mywine/windows/win.c Tue Oct 12 20:24:27 1999 Rein, are you sure this is the right patch? It seems from 1999... I want it test the patch if it supercedes my recent get_whole_window patch... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

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

16 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Even according to a strict interpretation of the LGPL > > they would just have to provide their code in seperate > > files so everything could be relinked when new versions > > of Wine was released. > > It seems you really don't understand the LGPL. Modifications made to a > library released under the LGPL are a derivative work of this library, > and have to be LGPL no matter if they are in separate files or > not. Saying the ALL modifications gives rise to a derived works even if distributed seperately is a ridiculous proposition that is the main problem with (L)GPL. As I have been trying to explain is that the courts are unlikely to support this, at least not 100%. The question is where is borderline is. At the extreme end the courts might totaly reject the doctrine of derived work in favour of the doctrine of combined work what I have been talking about in previous mails. If somebody (A) only provide drop in files that replaces some functions say the Crypto API in ADVAPI32, they are not any combined work since they are 100% written by A. Sure the application/library as a whole is of course a combined work, but that doesn't matter if you do not distribute it as a whole. > This is the standard interpretation that just about anybody > except you agrees with. If you think everybody agrees what a derived work is you are badly mistaken. Even Richard Stallman himself admit that the power of (L)GPL is dependent on how far the courts will allow the doctrine of derived work. Note that I do not pretend to know how the courts will rule. But I do know that sticking the head in the sand and pretending that (L)GPL doesn't have large potential holes in it is quite naive and potentially dangerous.

3 2

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