wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

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

RE: Jeremy makes a persuasive argument for LGPL
by Patrik Stridvall 15 Feb '02

15 Feb '02

> Well, I'm fairly convinced after reading his argument that LGPL is the > right way to go. I think it's better for the Wine project > over the long > term. Read my reply the Jeremy. Do you are really think the price is worth paying? > For those companies who have built a business model on closed source > enhancements to Wine, there is still a way to play the game: > > At some point Wine is going to improve to the point where the > core code > works well enough to do almost everything we need. There will > always be > room for improvement, but the action may shift to > reimplementing Microsoft > applications that have important APIs (Internet Explorer, > Windows Media > Player...). > > I'm sure that Microsoft will change its EULAs to prohibit use of > applications such as MSIE on a Non-Microsoft OS. It has > already started > doing this for some programs. I don't think such paragraph are worth the paper they are written on and as long as the Microsoft trial is going on thet wouldn't dare even try. > Companies could respond by selling open or closed source > reimplementations > of these applications, bundled with a LGPL Wine. There will always be > plenty of ways to add value on top of the core Wine code. Will it? You don't think most of the market will be eaten up by the traditional Linux distributions (Debian, Red Hat, SuSE, Mandrake etc) and possible Lindows? > Meanwhile, LGPL ensures that core code improvements will flow back to > benefit all, not just those individuals and companies that have an > altruistic bent. Yes, but at a terrible price.

1 0

Re: Scrollbar Fix
by Alexandre Julliard 15 Feb '02

15 Feb '02

Phillip Ezolt <ezolt(a)perf.zko.dec.com> writes: > It converts the intermediate variables to floats instead of > int, which guarantees that multiplication of large values of don't > overflow. (with a small sacrifice of accuracy) You should probably use MulDiv() instead of floats. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: BSD, Gav, LGPL, Jeremy, and business
by Brett Glass 15 Feb '02

15 Feb '02

Correction to the message I just sent: "Finally, because the (L)GPL makes product differentiation at best and often infeasible or impossible" Should have been: "Finally, because the (L)GPL makes product differentiation at best difficult and often infeasible or impossible" --Brett

1 0

WINELIB is not defined
by Andriy Palamarchuk 15 Feb '02

15 Feb '02

To check whether an application is compiled under Wine I should use WINELIB macro, right? It seems the macro is not defined if I try to check on it in programs/notepad. Should I define it in the Makefile.in explicitely? I see that other programs, specifically winhelp, wcmd, progman, use conditional compilation blocks, based on the macro, but I did not find it defined in their Make files. Sorry for the newbie question, but I'm not sure how this is supposed to work. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Got something to say? Say it better with Yahoo! Video Mail http://mail.yahoo.com

2 1

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

15 Feb '02

> > >Several people have asked me to clarify my original post. > > I just don't understand one thing: > > How does your company expect to make money once WINE is > xGPLed? If all your > > code has to be contributed back, why should I buy it from > your company? > > Hi, > > Companies will pay because they want certain functionality to > be implemented > that isn't there. For example, let's say you are company > Foo, who wants > their product "FooBar for Windows 2000" to work in Linux using WINE. > It makes use of some COM related functionality not currently in WINE > (like Out-of-proc objects or something) What do you do? > I mean, you can't just post on wine-devl and say "hey guys, > stop making > patches for DirectX, we want you to fix this COM stuff and NOW!" > No way. Do you get your internal staff to do it? Maybe. However, > most likely none of them know anything about WINE, so there is a big > ramp up time. Or do you hire an outside company to help you out, > a WINE developer-for-hire so to speak. That's why companies like > Macadamian and CodeWeavers get hired by clients, to get functionality > into WINE that would otherwise not get done. It allows the > client to focus > the fixes in the areas they need for their particular > application. Congratulations, you have just explained is why specialized consultants can make a living in the Wine market. However since this with a similar explaination is true in almost any market, I can't say I'm impressed. Sorry. That was perhaps a little rude. I was trying to illustrate a principle not insult you. It was not really aimed at you. > Sure, these > changes (optionally for BSD license, "required" for GPL) are > made available to > competitors, but as far back as I remember and for a while > yet I imagine > any moderately complex app will always require some fixes to > WINE to get > it to work perfectly. Yes, but sometimes this is what your client wants, sometimes it is not. Sometimes that client doesn't understand what is good for him and then you have the choice of explaining why or keeping you mouth shut. Your choice, sometimes this is better for you, sometimes it is not. Note however, what is good for you is not nessarily the same thing that is good for your client. Longterm that is. Short term the client pays you for your work regardless.

2 1

RE: ldconfig : ..... .so is not a symbolic link
by Medland, Bill 15 Feb '02

15 Feb '02

> -----Original Message----- > From: Sylvain Petreolle [mailto:spetreolle@yahoo.fr] > Sent: Friday, February 15, 2002 12:26 AM > To: wine-devel(a)winehq.com > Cc: wine-users(a)winehq.com > Subject: ldconfig : ..... .so is not a symbolic link > > > After updating this morning > cvs udpate -APd > rm config.cache > ./configure > make depend && make > > i get this when 'make install' : > what should i do ? (think i won't be the only one) Ah! I wasn't the only one. I went home last night and built a fresh wine and had the same thing happen to me. I thought it was because I had a screwed up system. As far as I understand it (google *IS* your friend) this is raised by ldconfig on occasions when it finds two identical so's that are explicitly saved rather than symbolically linked. However not always. In my case having removed all those messages (which I presume are actually warnings) ldconfig still didn't seem to detect my libuser.so for some reason (and possibly some others). (Actually they can't be warnings; initially it couldn't find libwprocs.so but that disappeared when I linked it to libkernel32.so, I think). Hopefully someone who knows what they are talking about will help us both out. Bill P.S. I don't suppose you tried a make uninstall and make install. DONT. make install won't work since the wine gets copied after the windedbg tries to copy from it.

1 0

Re: wine-devel digest, Vol 1 #745 - 13 msgs
by Roger Fujii 15 Feb '02

15 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > > I'd like to. But I will not release code under an FSF license, so I can > > only do so if I know that the project won't try to xGPL my work. > > You believe in releasing code under BSD-style licenses, but you refuse to > do so unless you have assurances that no one will create a GPLed product > from that code as allowed by the BSD license? I think there is a distinction to be made between RE-licencing and the "original" license. Given that we are possibly in an imminent change of the license, it is conceivable that a patch made now might not come out under a BSD license (really would depend on how the switchover would occur). Just as some people won't contribute to anything BUT *gpled projects, it's not unreasonable for other to have the opposite position. -r

1 0

ldconfig : ..... .so is not a symbolic link
by Sylvain Petreolle 15 Feb '02

15 Feb '02

After updating this morning cvs udpate -APd rm config.cache ./configure make depend && make i get this when 'make install' : what should i do ? (think i won't be the only one) /sbin/ldconfig: /usr/local/lib/libwine_unicode.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libwine_tsx11.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libwine.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libwineps.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libw32skrnl.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libsetupapi.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/liboleaut32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libole32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libmsvfw32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libkernel32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libgdi32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libcomdlg32.so is not a symbolic link ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr

1 0

Re: Wine License change: Open question to Jeremy White
by Sylvain Petreolle 15 Feb '02

15 Feb '02

Hi, Last time you just said you had personal problems. Now you are just hiding away. When a company wants to have the money, there are not days or weeks, only hours. Re: Wine License change: Open question to Jeremy White From: Jeremy White (jwhite(a)codeweavers.com) Date: Fri Feb 08 2002 - 18:23:23 EST Next message: Andreas Mohr: "Re: Dr. Seuss, licensing, and WINE" Previous message: Andreas Mohr: "Re: Dr. Seuss, licensing, and WINE" In reply to: Roland: "Wine License change: Open question to Jeremy White" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] -------------------------------------------------------------------------------- Roland, I've just hit a very busy patch in my personal life. You've asked a fair question, and I will try to address it, but please give me a day or two. Thanks, Jeremy ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr

1 0

OT: Wine build system tech info
by Vassilis Virvilis 15 Feb '02

15 Feb '02

Halo wine-devel people, Although I understand you probably "enjoy" one of the best or worst f^H debates of all times (who said wine devel is immune to flamewars after all? :-) I would like to pose a somewhat off topic question but still quite technical. As part of a private investigation I noticed that both WINE and LINUX kernel build systems have a mkdep utility which generates in clude file dependencies. What I am looking for is to understand the reasons behind this decision for the two very popular projects instead the recipe suggested by GNU make documentation. Here is what GNU MAKE suggests as the preferred way to handle dependencies. #---------Makefile Start TARGET=a SOURCES=a.c b.c CFLAGS=-ansi -pedantic -Wall OBJECTS=$(SOURCES:.c=.o) DEPS=$(SOURCES:.c=.d) %.d: %.c set -e; $(CC) -MM $(CPPFLAGS) $< \ | sed 's/$$*$\.o[ :]*/\1.o $@ : /g' > $@; \ [ -s $@ ] || rm -f $@; $(TARGET): $(OBJECTS) include $(DEPS) #---------Makefile End This method has the several disadvantages: i) It is GNU specific (unportable): a) Needs accumulative dependencies. That means a.o: a.c a.o: a.h does not override the first entry but it means a.o: a.c a.h b) It requires the include statement c) It requires that MAKE will reload the Makefile as soon as it realizes that the Makefile or any of included file has been changed. d) It uses compiler specific features. ii) Speed. a) Files has to be parsed twice during compilation. b) Slight changes to config.h may result in unnecessary, uncontrolled compilations. --------------- I would like to know if there are any other reasons that is not listed here and or if any of the reasons listed above is more significant than the others. Thank you for your time. .Bill __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com

3 4

FW: Patch: Double-click support
by Michael C. Maggio 15 Feb '02

15 Feb '02

It looks like this patch wasn't applied to CVS and I didn't see any comments here in wine-devel. Before I resubmit I just want to make sure that it wasn't turned down for any particular reason. =Michael C. Maggio http://www.voyd.net/ -----Original Message----- From: Michael C. Maggio [mailto:voyager@voyd.net] Sent: Tuesday, January 15, 2002 1:27 AM To: wine-patches(a)winehq.com Subject: Patch: Double-click support This patch adds support for double clicking in Wine. The added function, _is_dblclick(), is invoked with each button-down mouse event. The event must be the same button (left, middle, or right), at the same X,Y position, and occur within 500 milliseconds from the previous event. The original button-down event is still invoked regardless of the double-click. Tested in Starcraft. :) Ideally, we may eventually want to determine the double-click delay time from the registry, as it is a configurable Windows setting. But this should serve the purpose in the mean time. One last tidbit of info - I did not add a function prototype to any header files given the limited scope of this function. Whether this deviates from the Wine Development Standard (tm), I do not know. Perhaps a local prototype is more suitable in this case for the sake of ANSI-C compliance. I would appreciate knowing, at least, what the preferred method of prototyping is. ChangeLog: Adds support for double-click events via _is_dblclick(). =Michael C. Maggio http://www.voyd.net/

2 1

Re: Dr. Seuss, licensing, and WINE
by Brett Glass 15 Feb '02

15 Feb '02

Rick Romero (rick(a)valeoinc.com) writes: >As long as I'm sending this, I might as well make a comment on the >license. We all know money makes the world go round. If the current >license makes WINE more enticing to businesses, it should stay with that >model. If the LGPL encourages investment (time or money), then WINE >should move that way. IMHO, it appears the current license is best in >the long run. I agree. >The biggest issue I've seen so far is people ego's going >out of control when they've shared their work with the public, and >someone else hasn't returned their share (and possibly making money off >of it). Perhaps a simple economic analysis would help to assuage those egos. If WINE is available at no cost to any user, its market value as a product (defined as what a willing buyer would pay a willing seller for a license to use it) is zero. No one will pay money for something that's readily available for free. (They might pay a small amount for the service of pressing it onto a plastic disc, but with today's Internet there's no need even to do that.) Yes, its intrinsic value is higher, but what matters to users is market value -- what they have to pay to get it. Given that the market value of WINE, as distributed at no cost over the Net by the WINE project, is zero, anyone who hopes to sell a version for money must add sufficient value to get users to pay for it. This added value must not only be worth the money that customers pay (or word will get around and the company will make no sales) -- it must also be enough to overcome the transaction costs that the user incurs (filling out a Web form, paying shipping costs, waiting for delivery, worrying about credit card fraud, picking up the package at the post office, etc). And the seller of the value-added product will have a tough time convincing the user that the added value is sufficient to warrant the purchase. Is the no-cost version "good enough?" As WINE improves, it will be -- for more and more users. Thus, anyone who hopes to create a value added version of the product has a tough row to hoe. He or she must add a LOT of value -- and also provide support services, infrastructure for distribution, a sales staff, marketing, and much, much more. And he or she must stay ahead of the no-cost version, which over time will likely duplicate the most important value added features of the commerical release. Finally (and most importantly), if users DO buy the value added product, every cent they pay will be not for the original product (whose market value, as entioned above, is tautologically zero) but for the value added by the vendor. Thus, no developer of WINE can claim that the vendor is "making money off of" WINE. EVERY CENT will be due not to what the WINE project did, but to the value added. If the vendor is able to make money at all (and it's a long shot), he or she thoroughly deserves it. And every copy sold will benefit the WINE project, because the project's reputation will be enhanced by the vendor's success and the vendor will become more and more able to contribute code back to the project. (The vendor MUST, of course, retain some of its code so as to provide unique value; otherwise -- again -- no one will pay and everything falls apart. But at the same time, it benefits from contributing code with less strategic value, because the project will maintain it.) It may be that the vendor won't be equal to the task of adding sufficient value to stay in business. But if he or she does, it's a win/win. The project benefits from an enhanced reputation and from code that's returned to it because it's in the vendor's interest to do so. It's thus in the project's interest to help, not hurt, the vendor. The (L)GPL destroys this delicately balanced symbiotic relationship by making it impossible for the vendor to add unique value. As a result, the scenario described above can't happen, and it's a lose/lose rather than a win/win. The only entity that wins is the FSF, whose stated purpose is to prevent any commercial software vendor from surviving. --Brett Glass

6 14

Re: Licensing response and an idea
by Lean Fuglsang 15 Feb '02

15 Feb '02

Thanks for an enlightening post, Gav. //DISCLAIMER - I AM JUST AN ORDINARY USER - SO DON'T READ IF YOU DON'T FEEL LIKE I am not a developer (yet). But I truly believe in the spirit of OpenSource Free software. I have reported some bug reports, but I would really like to contribute more. When I first heard about a (very) possible licens change to GPL I thought it was a great Idea, because I hate companies who take code and don't contribute back. With the current license this is possible. But I also think it would be a shame for companies with good intentions (as Transgaming) who (maybe:) will contribute all there code back, and make very fast directed code to wine. I would also be very delighted to pay money directly to the wine project because I like it and use it. An important note is that this is what I do with everything that I buy. When I by music, it is because I like it and have heard it and want's to support the artist. Same with movies. I know this is not the way the corporate world works at the moment, but I can pirate music/video/software very easily and therefore they have to trust me to pay for what I want's to pay to. Phew, hope I didn't confuse all of you (like I confused my self:) But the point is, I really like to make contribution to a gratis project if it is GPL'ed or dual licensed (for 'good' corporations). Many of the people I know has the same 'Ideology' as me, and don't pirate things they think aren't sh**t. And after I have changed to linux and opensource, I have actually pirated a lot less, because all stuff are free, and the things that aren't 'stands out', so to speak. Just my .02$ (and maybe more if it goes as I hope:) //lean Ps. Hope I send this mail to the right place

8 14

Re: Wineconf attendance
by Michael Robertson 15 Feb '02

15 Feb '02

We currently have 35 registered people not counting the inquisitive reporter who signed up. I believe all are from wine-devel list since that's the only place I've seen it mentioned. Companies represented include: - Codeweavers - Transgaming - ReactOS - Macadamian - Xandros - Cadlink Technologies - Caldera - DSSD Software Inc. - 2 Geeks Computer Systems - DeviceForge - Some big OEMs - Other companies - A bunch of unaffiliated people If you would like to do a company presentation, please let me know and we'll do our best to accommodate. On the technical track, since attendees will be the speakers please think about the topic that would be interesting that you are knowledgeable about. This is all about people leaving smarter than they came and that happens best with everyone sharing their information and ideas. One of the 3 people on the Frankfurt/San Diego express, Dr. Ulrich Weigand has volunteered to speak on the following two topics: - 16-bit Windows: how does the support for 16-bit in Wine work, how much 16-bit code is still there in Windows 95/98/ME, how are the various types of thunks etc. implemented, what are the chances of running native Windows 95/98/ME 16-/32-bit DLL pairs under Wine (this would include the user.dll question Uwe suggested) - Debugger: how does the Wine debugger work, details about the various debugging formats (including the undocumented .PDB format) ... The biggest request is to hear from Alexandre Julliard who is working on his keynote to open the event now which rumor has it is better than the opening ceremonies of the Olympics. Only one request for "fencing and WINE". Sorry Gav. :) -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

2 2

RE: drawtext should not split words on clipping
by Medland, Bill 14 Feb '02

14 Feb '02

> -----Original Message----- > From: Joerg Mayer [mailto:jmayer@loplof.de] > Sent: Thursday, February 14, 2002 2:42 PM > To: Medland, Bill > Cc: Wine patches (E-mail) I think we're supposed to discuss these on wine devel > Subject: Re: drawtext should not split words on clipping > > > I've only read the description, so maybe I'm guessing wrongly what the > path does. Sometimes it is preferrable to split a word in the > middle to > not splitting very long words (like URLS). Yes, but you don't split it by saying it should be clipped; you split it by specifying, for example, DT_WORDBREAK | DT_EDITCONTROL (which results in breaking within the word if the whole word doesn't fit) This is a small part of a long sequence of changes that, I believe, are required to make DrawText work correctly overall, especially when it comes to ellipsification and word breaking on multiple lines. (The current version believes that ellipsification is only done if DT_SINGLELINE is specified!!). Maybe there is some case where the existing code "worked" by accident and it doesn't now but if so then I believe it should be fixed properly (which won't really be possible until I've submitted a couple more major reworks). Actually it's getting difficult to figure out how to do the next stage without a 500 line delta, because somewhere along the line I think it requires a complete revamp of the core routine (and, tempting as it may be, I am not happy submitting 250 lines of code that aren't yet called but will be when I submit the next delta). I am perfectly happy to discuss this with anyone who wants to; otherwise please bear with me. I honestly believe I know what I am doing. Regards Bill

1 0

Re: WineCorp (was Re: Wine license change)
by Roger Fujii 14 Feb '02

14 Feb '02

David Elliott <dfe(a)tgwbd.org> wrote: > Thus what we really need is some entity that will always have an unlimited > license to the complete wine codebase to do with it as it decides. I > question assigning copyrights away from myself and to anyone else, is > there some reason why signing an unlimited use license wouldn't be > acceptable (and thus developers would still retain their own copyright) or > is that effectively how it works anyway? This scheme would make the license awkward, because you have to add in "oh, by the way, all the contributions you make will be given to winecorp with an unrestricted license" clause. It is far cleaner and simpler to require contributions to assign the copyright. OpenOffice does this. > Wine cannot stay X11 free-for-all forever. Reminds me of one of Roger > Ebert's columns about the movie "It's a Wonderfull Life". Because the > movie is now public domain, anyone can use the original print for whatever > purpose. This includes colorizing it and then selling the colorized > version for a lot of cash (thanks Ted... yeah right). The colorized > version is a bastardization of the movie and is one of those cases where > you almost wish that copyrights didn't expire. Especially considering that > the director and the much of the cast were still alive to see this > horrible, horrible thing. Wine is very much in the same position here. > While we are not quite public domain we are so close that any distinction > is a moot point. *GPL wouldn't prevent the above either. Any "open source" license would let the above happen. As I said before, "freedom means others can do what you don't like" -r

2 3

Re: shellexecute patch
by Andreas Mohr 14 Feb '02

14 Feb '02

On Thu, Feb 14, 2002 at 11:57:55AM +0100, Rein Klazes wrote: > > Needed for Visual Studio.NET installer. > > Changelog: > > dlls/shell32 : shell.c > In ShellExecute16, make sure there is a space between command > and parameters. Hmm, I suspect that might be wrong. (in case your ShellExecute16() is being called by ShellExecute(), that is) ShellExecute() was supposed to call WinExec() instead of WinExec16() (long filename support). I wrote a ShellExecute patch some weeks ago that didn't get applied, probably because there were compile warnings. But I might be wrong and your patch is completely independent of mine. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 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