February 2002 - Wine-devel - list.winehq.org

Wine's path VS host path
by David D. Hagood 16 Feb '02

16 Feb '02

Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine. The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.). Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is "self-contained". The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs. As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path. Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime? On a related note: would it be possible to have a means to tell the wineserver process to "hang around" for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of "start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit" operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process.

5 9

Re: a small patch to wineshelllink
by Alexandre Julliard 16 Feb '02

16 Feb '02

"Michael Cardenas" <michaelc(a)lindows.com> writes: > - Added a check for file type to wineshelllink. If the file is an > executable, add "Type=application" to the kde entry. You can't do it that way, there is no guarantee that 'file' will return the same description on all machines. -- Alexandre Julliard julliard(a)winehq.com

2 1

brett glass
by Shane Shields 15 Feb '02

15 Feb '02

>The words of a man who has no intention, interest or desire to compromise. >"There is no need to compromise because my way is the right way." Brett, no >one >on this list that has read your posts fails to see your point. Some of them >disagree, some of them agree, but a) you have no formal say in the decision >(of >course, you're free to do as you've done and bemoan the issue) and b) you >have >shown no willingness to look at the points of view of the other members of >this >list who don't think the same way you do. >I think it's time you, to use a phrase, either put up or shut up. If you >want >people to listen to you more than you've listened to them, then write some >code. > Then, people might be more interested in what you have to say. Saying >"Well, >I *might* contribute, so long as you don't change the license" and presuming >that your vapourware-work is any sort of argument for people to listen to >you >and do what you want, is ridiculous, childish and egotistical. >We've heard your arguments and attacks on the FSF and RMS. Fine, you've >stated >your case and made your point. Now let the people that can actually make >the >decision make it. hear hear im glad that you said it. cause if you wasnt going to i was. some people like arguing for arguments sake but it takes two (or more) people to have an argument. if no-one was to reply to an unwanted solicitation then that outlet of expression will die a limp death. for people who enjoy vendettas and slander the best medicine is to deny them the satisfaction of knowing that they have produced a response. in other words dont respond to useless verbatribe and it will dissapear like butter on a hot plate. this is the only mail that you will see from me about this subject (no need to regurgitate useless code) best regards Shane Shields -- To drink the WINE of success you must first seek the sayings of source _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

RE: Clarification on my call for license change
by Patrik Stridvall 15 Feb '02

15 Feb '02

> > But the second more important question was (in my words): > > Why should I buy a Wine distribution from you? > > > > If you are forced to contribute back everything I can just do: > > > > cvs update ; ./configure ; make install > > > > What I and other have been trying to say is that some business > > models like consulting business makes sense with a LGPL:ed Wine > > but others like Transgaming:s might not. Read what Gavriel wrote > > in his first(?) reply again. > > > I have been avoiding this debate although reading it closely. > However i > thought i would step up to the plate on this one, as someone whose > salary depends on Jeremy's vision. > > The simple of it is.. you, Patrik, would not buy a Wine distribution > form us. Why would you? You are a developer, and a wine > developer on top > of that. If your critical app crashes you can just hack on > the code and > make it work. In fact we dont really expect anyone on this > list to buy a > Wine distribution from us. Yes, that is pretty obvious. > However if a company unfamiliar > with Wine, or > even linux wants to get a critical app working on Linux using > Wine they > have to choose. The could hire a developer and have that person figure > out wine and do the work, or buy a distribution of Wine supported by > proven Wine developers. > > It is these sorts of people and companies that we want to target. And > financially Patrik's money for his license or even the money form all > the wine developers would be nearly insignificant compared to a 100+ > seat site license. The problem is not that I or the other Wine developers don't pay. The problem is that the company needing a 100+ seat license runs Red Hat, SuSE or Mandrake or some other Linux distribution. They turn to their respective distributor say Red Hat and say that they are prepared to pay $XXX per year for a better supported Wine. Red Hat in turn hires me (or some other on this list) to do this and I do: cvs update ; ./configure ; make install That is your problem. Sure Red Hat might write a contract with you instead but then perhaps they consider you a competitor and hire me instead or perhaps they believe I'm better or whatever. > As a developer who has worked on far too many > proprietary Wine trees and seen all the fights the Jeremy has gone > through. I want to be assured that i can give my code back to the wine > community. Assurance about some things can be given but everything has a price. Will you pay it? Will it really do what you expect it does?

2 1

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 15 Feb '02

15 Feb '02

> On Fri, 15 Feb 2002, Patrik Stridvall wrote: > > > Still think that after reading my reply to Jeremy? > > Yes, I do. > > Listen Patrik, in the past you seemed to be a reasonable > person. Now you > are indistingushible from a troll. Really. It seems that whatever is > argued, you have a psychotic tendency to invent a counter-argument, no > matter how silly it is. Yes, I'm quite aware that some people consider my tendency of almost never giving up irritating. :-) But what do you expect me to do when I have a feeling that going to LGPL is a terrible mistake? If you don't understand it if I explain it one way, perhaps you will if I explain it another way, of course often I hope invain... > Now, that fun sometimes, but it has > gone too long, > too often in this bitter thread. For this very reason I have > avoided to > argue with you, but I will make this one exception, since the > thread has > progressed past useful long time ago. If you have made up your mind you have, but I'm arguing for people that haven't. > > Very true and this significantly weakens any "protection" > > that the LGPL offers. > > Which is a feature, and which should silence all reasonable BSD > supporters. BSD has the same feature so when comparing pros and cons this certainly doesn't weight in favour LGPL. > The ones that are left, simply ignore this very > important FACT > (It's emphesised since I don't want to argue it, let's assume > it for the > purpose of this discussion). Their is nothing to argue, BSD has the same feature. Obviously we should concerntrate on the relative pros and cons. > > Perhaps, but at a terrible price. Read my reply to Jeremy. > > Crap. What terrible price, WTF are you guys smoking, 'cause I > want some of > it! Once again: Wine is isomorphous to a Linux distribution. They are > growing MUCH faster than Wine ever did. They have a lot of commercial > backers. No Wine is not isomorphous to a Linux distribution. Wine will be an essential part of EXISTING Linux distribution. Sure there might be a market for new specialized ones like Lindows but don't have to large hopes. I'm sure there will be Linux distributions willing to offer proprietary extension to Wine if some company offers it. There is nothing strange about that, some distributions already bundle proprietary applications. > Stop this stupid, idiotic, "LGPL will kill all > business" argument. I have never said, that LGPL will kill all business models, now you are claiming things I never said. There are some people, none named, none forgotten in the BSD camp that he made similar claims, but please don't make me guilty by association. I have said that it will limit the possible business models severly. For example read Gavriels first reply or for that matter read my last reply to Jeremy again. Since the LGPL removes the work protection that the work have from copyright, it is almost essential that you get assurances that you get paid before doing the work. This is in most markets called contracting. > > Somehow you seem to believe that all reasonable business models > > will strictly following DLL boundaries, but you have given. > > absolutely no proof of this, you just assume it. > > Patrick, you are incorrigible. Yes, our purpose in choosing a > license is > not to support as many business models as possible. No. It is > to find a > licence that _overall_ is best for Wine. My point is that since the Microsoft DLL in general have no clear design the LGPL will articially for no good reason prevent some business models that you otherwise have been possible. This means that Microsoft arbitrary choices will prevent many otherwise possible business models. Is that good? Of course this requires that Alexandres analysis of the LGPL is correct, if he is not, you will lose most of the rest of the protection that the LGPL might provides. In that case you will have Wine under a close to meaningless license that will potentially scare away people not wishing to try their luck in court. > Now, we all agree that some > commercial involvment is good. The question is, how much? All possible > one? Like everything is life, the answer must lie in the > middle, not at > axtreme. Obviously. I have never claimed anything else. > So we must sacrifice a few business models to > benefit Wine. It's > just fare. An LGPL licence will keep most of them still > viable (such as > TransGaming, for example). WTF is your problem with it? My biggest problem is that because of way Microsoft have designed the Windows the sacrifice will be complete arbitrary. I'm not entirely against some sort of "copyleft", that is why I in my debate with David Elliot proposed that we could possibly have a license that makes it clear that linking to proprietry libraries are allowed. Possible we could add some paragraph about that the functionality must be a seperate part of DLL in some way. I don't really like it, but you were speaking about compromises....

1 0

Question concerning internal string usage
by Gerhard Gruber 15 Feb '02

15 Feb '02

Some functions are duplicated with their only difference being that one of them is wide character (W) and the other is ASCII (A). Of course it makes sense to convert one of them into the other and reuse the existing code. What I was wondering about, though is that, at least in the exmaple of files/profile.c the W functions are converting to A instead the other way around. Shouldn't we expect some problems with systems using wide characters or is this handled such that these characters are represented as more then one characters in ASCII? In Windows I'm pretty sure that A is always converted to W for such functions.

3 2

Re: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 15 Feb '02

15 Feb '02

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > Can't you see that most Linux distributions _are_ made mostly of > xGPLed code, and that hasn't stoped a lot of proprietary companies such as > Oracle, SAP, IBM, etc. to release and develop code on this platform? This is an apples to oranges comparison. Things that CALL LGPLed libraries are safe. The problem is that things that work WITHIN a library is not. You can *say* that it stops at the DLL boundaries, but the license does not back what you say. The LGPL has a "work as a whole" clause that can easily be argued that it applies to anything within wine. So, while an installer for wine won't be affect by LGPL, any DLL that wine uses can arguably be considered a part of wine (unless you go through the pains of making sure that your DLL was added AFTER wine, and that the new wine works without your dll. If you want a LINUX analogy, look at device drivers. The *GPLness of the kernel means that no propriatary driver can be shipped as a part of any distribution. Steve Langasek wrote: > Since Jeremy has stated his intention to release future code changes only > under Copyleft, the decision for Wine contributors to make is a simple > one: do you believe that the benefits of potential additional corporate, > closed-source adopters of Wine outweigh the certain loss of code > contributions from Codeweavers, a known active contributor? ok... finally, a reasonable place to start, as it's finally an admission that the choices are exclusionary to some respects. re jeremy's posting: It's pretty obvious that there's animosity between transgaming and codeweavers. Peronally, I think the main problem here has very little to do with licensing, but rather that the commerical pie for wine is really only large enough to support 1.3 companies. So, let's just go over some of the points: > 1. The current license encourages forks. a) the forks already exists - do you think changing the license will fold in any of the forks? b) the forks are also signs of (new) development. Presumably, no one would fork something just for having a fork. > 2. The current license discourages competitors > from releasing their code. s/discourages/does not encourage/ > Since I believe in the LGPL, but compete with Transgaming > and Lindows, contributing my code under the current license > is like giving my competitors my very best and getting nothing > in return. So, are you saying that Gav is an insignificant contributer to wine? and that all the code inside with is 100% written by codeweavers? > You know, the concept of making money on Free software is crazy > enough without enabling your competitors into the mix. Think the problem here is that you guys are competing in the first place. If you were in different markets, one would think you could "trade" components into open source, thus reducing redundancy without having to risk your business. Also, I don't think it's unreasonable to ask (as a switch to LGPL might discourage Transgaming from ever releasing the dcom code - gav, will this affect your decision?) what exactly is codeweavers going to release LGPLed in the short term and why the urgency? > 3. The current license is harmful to the growth > of Wine, because it creates a murky, uncertain ground. > Well, a Copyleft license provides potential > corporate citiziens with written rules. LGPL is not the only license that's a copyleft. Just from cursory reading, MPL seems more reasonable that LGPL since section 3.7 makes a distiction between "covered code" and "larger work". Personally, if a simple "requirements" list is made, some choice can be made that isn't disagreeable to too many people (unless you have philosophical restrictions like "it can/can't be GPL compatible"). If copyleft and commercial viability is the only requirement, MPL would be a reasonable compromise. -r

2 1

Re: Jeremy makes a persuasive argument for LGPL
by dschwarz＠bellatlantic.net 15 Feb '02

15 Feb '02

Brett, Thanks for the email. I've read your argument, many times over on the wine-devel list. I don't buy it. Regards, Daniel Schwarz dschwarz(a)bellatlantic.net

1 0

BSD, Gav, LGPL, Jeremy, and business
by Dimitrie O. Paun 15 Feb '02

15 Feb '02

People, I am sorry I have to fuel the flames, but I have to say what I have to say. First, and formost, we have now heard the oppinion of two big (from Wine POV) commercial players: Gav and Jeremy. Now, it was painfully obvious to me that Jeremy had the power of reason on his side, while Gav only a strong emotional impulse. And there's reason for that -- the LGPL make a lot more sense for Wine. We've heard countless arguments why that's not that case. A lot of them where simply nonsense. The few that made some sense, were ALL based on a false premise: that Wine is a monolithic product. Now, this is a _fundamental_ point that is ignored over and over again: Wine is a _collection_ of products, just like a Linux distribution. Which means that the viral aspect of the LGPL _stops_ at every DLL boundary. It is easy to see now that this does not preclude most commercial implementations. In fact, it encourages them givin them a level playing field. Just like Linux does. People, for crying out loud, _think_ about it, and the conclusion will jump right out at you. THIS IS WHAT WE WANT: -- if a company invests a _little_ to improve a DLL, we should have no moral problem requireing them to contribute that back. Since it's just a little contribution, no business will be destroyed because of it. -- if a company makes a huge improvement (like Transgaming), they can simply drop the original Wine code, and keep everything propriatary. Now, compared to the _huge_ improvement, the cost of reimplementing the mostly non-working Wine code should be trivial. Bottom line is: -- are we raising the bar for comercial companies with a LGPL licence? YES! -- how _much_ are we raising it? BY A TRIVIALLY SMALL AMOUNT! -- do we invalidate TG business model? NO! I'll say this: if Alexandre will start maintaining a LGPL tree, I will submit my code only as LGPL. Everybody who believes even _a_little_ in an LGPL solution should do the same. -- Dimi.

2 3

RE: Clarification on my call for license change
by Patrik Stridvall 15 Feb '02

15 Feb '02

> Since Jeremy has stated his intention to release future code > changes only > under Copyleft, the decision for Wine contributors to make is > a simple > one: do you believe that the benefits of potential additional > corporate, > closed-source adopters of Wine outweigh the certain loss of code > contributions from Codeweavers, a known active contributor? Even so, since the LGPL is a one way street, remember that it might not always be so in the future. If we choose LGPL there is no turning back. Remember that always.

1 0