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

Re: Lindows.com and open source
by Michael Robertson 12 Feb '02

12 Feb '02

>John Alvord <jalvo(a)mbay.net> At 02:11 PM 2/11/2002 -0800, you wrote: >Maybe you could shed some light on the current License flamefest. >Would BSD versus LGPL have made any difference to you progress as a >company? You have contributed so much in the past, a formal statement >of intentions could reduce the perceived problem... I'm not sure Lindows.com has earned a voice in the license debate yet or even if we had a voice could add anything meaningful that hasn't already been said. There are many others who have for years shepherded WINE to this stage. I'm confident they'll do the right thing. Licensing is a topic on the wineconf 2002 agenda. I'll be sending a list of topics to the list shortly for feedback. Thanks to those who have offered suggestions. From a more general perspective though, I believe there needs to be much more investment in many areas of WINE and more broadly Linux to get to the next level (say from 1% penetration to 10%). Anything that gets more people involved, more organization, more developers, more capital, more companies, and more ideas will ultimately be a good thing. When I was at MP3.com, we had the MP3 summit every year. We invited everyone including our direct competitors, tangentially related industries and even our antagonists. We'd not only invite them, but also encourage them to speak. Our thinking was the more people that we got making "neural connections", the more success MP3 would have (and ultimately MP3.com) Companies were created, merged, and bought because of the MP3 Summit. Products were dreamed up and built because of the MP3 Summit. It wasn't about our company, it was about bringing all the smart, passionate people together (even if they had opposing viewpoints) and watching the magic happen. I believe Linux and WINE (at least on the desktop) are at similar stages. -- 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 1

RFC: Re: Problem with COM (fwd)
by lawson_whitney＠juno.com 12 Feb '02

12 Feb '02

---------- Forwarded message ---------- Date: Sun, 10 Feb 2002 21:32:31 +0100 From: "[iso-8859-2] Du¹ko Rusmir" <drusmir(a)gmx.ch> Reply-To: wine-users(a)winehq.com To: wine-users(a)winehq.com Subject: Re: Problem with COM Dana nedelja 10. februar 2002. 04:11 napisali ste: > On Sun, 10 Feb 2002, [iso-8859-2] Du¹ko Rusmir wrote: I must use 5726, 5760 and 9600. My app need this to work. On 4800 and 9600 I got error. With other app I can use 38400, 57600 and 115200 wery well. I thing the handling of COM Port on these BaudRate is't good. Thanks -- trace:comm:BuildCommDCBAndTimeoutsA (COM1: baud=5760 parity=N data=8 stop=2,0x405608ac,(nil)) trace:comm:SetCommState handle 64, ptr 0x405608ac trace:comm:SetCommState bytesize 8 baudrate 5760 fParity 0 Parity 0 stopbits 2 trace:comm:SetCommState ~IXON ~IXOFF err:comm:SetCommState baudrate 5760 Now nobody is going to convince me there is any software that will make a normal 16550a run at 5726, but with effort I managed to explain the linux setserial spd_cust kluge, and at last report the app was working: /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4 Baud_base: 115200, close_delay: 50, divisor: 20 closing_wait: 3000 Flags: spd_cust skip_test trace:comm:BuildCommDCBAndTimeoutsA (COM1: baud=38400 parity=N data=8 stop=1,0x405608ac,(nil)) trace:comm:SetCommState handle 76, ptr 0x405608ac trace:comm:SetCommState bytesize 8 baudrate 38400 fParity 0 Parity 0 stopbits 0 trace:comm:SetCommState ~IXON ~IXOFF trace:file:ReadFile 76 0x405607d0 255 0x405607c4 (nil) trace:file:ReadFile 76 0x405607d0 255 0x405607c4 (nil) trace:comm:EscapeCommFunction handle 76, function=3 trace:comm:EscapeCommFunction SETRTS trace:comm:EscapeCommFunction handle 76, function=4 trace:comm:EscapeCommFunction CLRRTS Now I am not particularly fussed that Wine should be exactly as Windows, and I am willing to try to explain (again) the spd_cust kluge in Wine doco, if I don't have to use sgml, but I wonder if it wouldn't be better in the long run to figure out what Windows does with off-brand speeds like this (little help? I don't have any Windows.) and cobble up a TIOCMGSERIAL/TIOCMSSERIAL to handle them, at least for Linux. Anybody know how to do a ./configure test for an ioctl? Oh.. looks like we already have some. I guess I can figure it out. 5760 is easy, I believe that is just a divisor of 20, but 5726? Does it round up to the next possible speed? Round down? Count the feet and divide by 4? Lawson

1 0

Re: Wine License Change
by Claus Fischer 12 Feb '02

12 Feb '02

As a non-developer, I think this discussion can be considerably shortened by just forking and starting to work on the LGPL branch. If the current license allows Lindows to make proprietary modifications and not give anything back, it certainly allows Codeweavers/whoever to make proprietary modifications and give back under LGPL. Those who don't want to even read LGPL code for reasons of 'contamination' just shouldn't read it. You can't read Lindows code either. Why should Codeweavers be morally pressured to contribute under a steal-me license when steal-it companies don't contribute at all? Just let Codeweavers use their rights that you defend so vehemently for others, and don't critizise them for doing something your favourite license permits. ****** I personally tend to think that GPL style licenses attract more developers and create a level playing field even for companies as contributors. Put a snapshot of current CVS somewhere for X11 freaks and start checking in LGPL. And don't discuss with morons, especially non-developers ... :-) Claus -- Claus Fischer <claus.fischer(a)clausfischer.com> http://www.clausfischer.com/

2 1

RE: Wine license change
by Patrik Stridvall 12 Feb '02

12 Feb '02

> Francois describes the central issue well: the LGPL will > provide a way for the vendors to trust each other. > > Let those of us who understand this simply start releasing > our Wine changes under the LGPL, regardless of what anyone > else does. That should make it clear which way the main > tree should go. First of all what "those of us"? You mean "those of you"? Searching the mailing lists I see that you from time to time have provided various testing, suggestions or other information but I can see no patches. Secondly understand what? If you are so clever that you REALLY understand what the LGPL means, please enlighten us poor ignorant people. In particular answer Roger Fujii's challenge: I challenge anyone to show me what "work that uses the library", "work based on the library", and "whole" means in the context of wine. The problem is that I'm pretty sure you can't. In any case the trust mechanism of LGPL is dependent on the how the license is interpreted. If you are not certain or pretty sure how a judge or jury will interpret the license, all trust issues are meaningless. Futhermore I have tried to show that you can't both have the cake and eat it. In order for the LGPL or for that matter any license to provide the "trust" that you are after you must also prevent things that are quite reasonable to assume are legal. Like Joe Hacker using his proprietary library to get another proprietary application to run under Wine in order to avoid dual booting and share it with fellow hobbyists. Even if you dismiss this as "Oh well, even so I think it is worth it.", I have another question: How is this compatible with freedom 3 of the free software definition? Free Software Definition (freedom 3): The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.

2 1

Wine Developer License Test
by Ove Kaaven 11 Feb '02

11 Feb '02

Take this test and find your preferred license. A few simple questions can reveal your stance. Fun for the whole family! 1. Do you maintain that information (code) should always be free, no matter how expensive or difficult that information was to come up with, no matter how limited applicability it may have, and no matter how damaging freeing that information might be for the industry, both good and bad? a) yes b) no c) maybe points: a = 2, b = 0, c = 1 2. How should people that come up with such information (coders) be rewarded for their efforts? a) tangible goods (money) b) name recognition in the liberation army (free software enthusiasts) c) name recognition in the rest of the world d) feeling good about themselves (no reward at all) e) I really don't care about them, I just want the code points: a = 0, b = 2, c = 0, d = 1, e = 2 3. Would you like it if your work was incorporated into cheap, mass-produced, proprietary, commercial consumer devices, like cell phones, game consoles, microwave ovens, or home-grown nuclear power plants? a) yes b) no c) I don't care points: a = 0, b = 2, c = 1 4. Do you care about users? a) yes, I would like to have many users, and listen to their needs b) no, I'm the developer, I do the work, it's my way or the highway c) mostly, but not at all costs, I don't mind losing a few points: a = 0, b = 2, c = 1 Results: 0-1: I feel the X11 (BSD) license makes the world a better place 2-3: While not perfect, I think the X11 (BSD) license does give users a fair choice and encourage wide use 4-6: I am somewhat suspicious of my users, so I think the LGPL license makes it easier to herd them 7-8: Freedom above all; I elect RMS for president, and prefer the GPL

2 2

ScrollBar/Cannot use first megabyte
by Phillip Ezolt 11 Feb '02

11 Feb '02

Hi All, Here's a little break from the license wars. When I run the example contained in 1902.exe from: http://msdn.microsoft.com/library/en-us/dnwui/html/msdn_scroll32.asp?frame=… I receive the following error: "err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report" Interestingly enough, the test program for scroll bars works much differently on Windows NT than on Wine. The scrollbar example includes both source and executable as well as documentation about some Windows scrollbar bugs. If I knew a little bit more about windows programming and/or Wine, I'd fix it.. --Phil Compaq: High Performance Server Systems Quality & Performance Engineering --------------------------------------------------------------------------- Phillip.Ezolt(a)compaq.com Performance Tools/Analysis

1 0

Re: Wine license change
by Roger Fujii 11 Feb '02

11 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > On Thu, Feb 07, 2002 at 05:45:36PM -0500, Roger Fujii wrote: > > If you are using marketing speak for "contribute". GPL requires 1) > > for you to show your work 2) You effectively license your software to > > the FSF. It doesn't say it has to be in any useful form to be worked > > back into the originating project (if any). > We're talking about the LGPL, not the GPL. true with either. Your "contributions" must be licensed as LGPL/GPL. > The rest of this paragraph shows a serious disconnect with the text of > the LGPL. Have you actually read the license in question? I have no clue what you are talking about. I didn't say anything until the "Here we go again". And Yes, I have read the *GPL, many, many, many times. > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control > compilation and installation of the library. If you are contesting the "useful form", let's say I did this: Took the original GPLed code and run it through a lexical translator so that all labels and such are changed. Make my changes with respect to THIS codebase. Now publish this. This AFAIK, fulfills the technical requirement of the *GPL, but it certainly isn't a usable form. > > Here we go again.... If this is *all* it did, LGPL is far less objectionable. > > The problem with *GPL is that it also regulates the UNMODIFIED use of the > > software. > > The creation of derived works does not constitute "unmodified use of the > software" under any legal definition I've ever seen, if that's what you're > referring to. no, it's this phase: Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. > > Freedom means allowing people to do things, even things that you don't > > agree with. BSD = Free. GPL is not. Call a spade a spade.... > > Nonsense. To extend your definition to the proper conclusion, it's not > Free unless it's placed in the public domain, you are ABSOLUTELY right. The spectrum is PD->BSD->GPL-------->Propriatary. But then, things in the PD really isn't licensed, so X11/BSD is probably as close as one can get. > and any software license that permits you to maintain any portion of your > copyright is a fraud if it claims to be Free. If you really cared about > giving absolute freedom to the users of code that you write, you would > place all of your code in the public domain. we can quibble about what "free" means, but saying GPL is "more free" than X11/BSD doesn't make any sense. Given the current license is X11/BSD and the argument is for changing it to LGPL, I can't see how one can use the "freedom" argument in this case. > Not planning to do that any time soon? stuff that I have put back into projects go with the license that it's under. All of the changes I've put back goes back with *no* restriction (ie. it's PD as far as I'm concerned). > Then spare us the bullshit arguments about the BSD being Free and the GPL not. > (Yes, it is bullshit. Call a spade a spade, right?) geez. no need to get bent out of shape. I'll rephrase and say BSD is MORE free than GPL. Happy? > All Free Software licenses attempt to find an equitable balance between the > freedoms and rights of the authors, and the freedoms and rights of the users. this statement is true of licenses in general, with the freedoms/rights of the user declining along that freedom spectrum. In the US (forgetting the DCMA for the time being), the freedoms and rights of the authors are guarenteed by law (1st amendment/copyright). What I philosophically object to is using the freedom argument WRT GPL, since the freedom of the author is never in question, while the freedom of the user is curtailed. I have no problems in saying it's equitable, fair, desirable <insert socially desirable adjective here>, even "right" - just not 'free'. > You are free to favor one balance point over the others, but that doesn't make > other licenses and other balance points non-free. my dictionary says one of the definitions of freedom means "unrestricted use". So it's fair to say something that has MORE restrictions is LESS free, or are you arguing that GPL is more "free" than PD? > But neither philosophy nor politics is the issue at hand. The issue at > hand is whether the LGPL, or a similar license, would be better or worse > for growing the Wine community. For that, there are good arguments on > both sides. we agree. > On the other side, companies like Lindows.com don't impress me as bringing > any added value back to the community -- they may succeed in increasing > the percentage of non-Windows desktops in the world, but the current Wine > license makes it possible for all the profits from their OS to pad the > wallets of marketroids, sales critters and smooth-talking business execs, > without contributing anything back to the Wine tree. I have no problem at > all with the idea of eliminating that particular business model. The problem with that particular argument is that it makes the fundamental assumption that all people who don't contribute back NOW is evil foreever. You just don't know what will happen in the future. Maybe Sun/IBM buys out lindows.com in 6 months when they are broke, and opens the source. Or, maybe in a year, they have a change of heart (has happened before with other companies). The point is that it's arguably better to have more players. > > If this is the goal (it certainly is mine), then *GPL is not a good choice, > > because it would interfere with deployment (*GPL wouldn't allow being bundled > > with the playstation2 or other HW platforms as an example). If acceptance > > is the goal and you care about wine in a non-linux context, stay with > > BSD/X11. If you don't care about expanding the pie, go *GPL.... > > Please write what you mean, which seems to be "Sony would never accept the > terms of the LGPL, which would prevent them from being able to bundle Wine > with the PlayStation2". Again, I don't see where this would be a loss. > Companies that are unwilling to contribute back to the community are not > any concern of mine; if they want to compete with Microsoft on the > desktop, let them fund their own software development instead of leeching > off of the community. My only concern with the LGPL is making sure that > well-intentioned companies that DO give back to the community aren't > caught in the middle. Let's say the playstation distributed wine for every PS2 that shipped. If only .001% of its users (and these are gamers) get interested in wine, that's 200 additional contributers. Most people get involved with a project because they USE it initially. So, it's reasonable to say that wine is still better off if sony distributed it without contributing *anything* (maybe had had to make NO changes, who knows) because of the additional interest. You might not consider this a loss, but to me, it seems like it is. -r

3 2

Yet the parameters problem (WAS: CreateProcess API - undocumented use)
by Ricardo 11 Feb '02

11 Feb '02

Ok, I've tried everything. Change the API used (GetStartupInfoA to GetStartupInfoW), changed the code, but I have no idea where to change in wine to, when I have 2 programs, doesn't loose the passed parameters. Here's how it works: PGM1 starts and ask the username and the password. If it's ok it writes FILE1.DAT and FILE1.IDX with settings to PGM2 to run. These files are wrote correctly, but PGM2 can't read them. When PGM1 finish wine seems like "closing" and than star over with the PGM2 (called by PGM1 with the parameters writen (API CreateProcess)). But PGM2 starts without any parameters (API GetStartupInfo) and without the parameters it cant run, so the program exit. I've already checked 3 files: loader/module.c, scheduler/process.c and memory/environ.c. And compared it with the MSDN Library, and the codes are the same, so no problems with it. How does WINE deal with a program calling another one? thanks Ricardo

2 1

Re: Make Home, End and Enter on the keypad work in the debugger
by Eric Pouech 11 Feb '02

11 Feb '02

Dmitry Timoshkov a écrit : > + {/*VK_END*/ 0x23, WCEL_MoveToEnd }, > + {/*VK_HOME*/ 0x24, WCEL_MoveToBeg }, those two ones are already in Win32KeyMapExtended, so I don't see no reasons to add them twice A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Dr. Seuss, licensing, and WINE
by Brett Glass 11 Feb '02

11 Feb '02

[Note: This is a slightly revised version of some material which I've posted to Slashdot. Copy replies to me, as I am not on the wine-devel list (though I have been an active advocate of WINE and will continue to be so long as it is not licensed under a viral license such as the LGPL). -BG] This entire issue is reminiscent of the well known Dr. Seuss story "Horton Hatches the Egg." In the story, a bird lays an egg and then convinces a kindly elephant named Horton to sit on it. Horton braves all manner of hardships -- heat, cold, even the indignity of being captured and displayed as a freak in a circus -- to remain with his charge until it hatches. Whereupon, the bird immediately demands that Horton return the fruits of his labor to her. (Were she a modern Richard Stallman, she might have declared that it was a GPLed egg.) Writing a program -- like laying an egg -- isn't necessarily an easy task. However, bringing it to the marketplace and successfully selling it as a product -- especially in the presence of a free alternative -- is a much more difficult and dangerous one. The company that hopes to sell a product that's an improved derivative of one that's available for free is taking a big risk and must make a truly Hortonian (if I may coin the phrase) effort to be successful. What Mr. Stallman and the (L)GPL would demand is that the person who manages to do this -- competing against all odds with a no-cost version and potentially infinite numbers of competitors publishing and bundling it -- get nothing. Those who wish WINE to be published under a license which is not truly free, as the current license is, appear to believe that the emergence of products such as Lindows is a threat to WINE and/or to businesses such as CodeWeavers. Nothing could be further from the truth. If the creators of derivative works act in their own best interests, they will return all but the most strategically important code from their implementations to the WINE project, reserving for themselves only what is necessary to differentiate their product from what another vendor (e.g. Red Hat) might produce. This minimizes their maintenance costs, and may -- there's no sure thing here -- provide them with sufficient value added to survive in the presence of a free alternative. (If they don't do this, there is an automatic penalty: they'll have to re-integrate changes into each new version.) To (L)GPL WINE, on the other hand, prevents such worthy products from ever seeing the light of day. It is, in essence, snatching back the egg from poor Horton after all of his hard work. And it won't benefit WINE, WINE users, or CodeWeavers. Many companies' potential contributions will be lost, and CodeWeavers and WINE will gain themselves a reputation for being hostile to business. This will cause the consulting business from which CodeWeavers hopes to make money to dry up. In short, the move is shortsighted and bad for all concerned. CodeWeavers, and other companies that hope to profit from their work on WINE via paid consulting, should look instead to the model of Wasabi Systems (http://www.wasabisystems.com/ [wasabisystems.com] which just received a round of venture capital funding worth more than $1M to port, publish, promote, and consult on NetBSD. NetBSD is truly free; it's published not under the restrictive GPL or LGPL but under the BSD License. And Wasabi is going strong; they just published a desktop package (consisting of NetBSD plus GUIs and applications) that is competitive with the best of the Linux distributions. The WINE project, for its part, should resist falling prey to the spite and resentment that the Fascist^H^H^H^H^H^Hree Software Foundation encourages (and has made part of its licenses). If the project makes the mistake of adopting an FSF license, commercial programmers such as myself will no longer be able to so much as look at the code -- much less fix bugs or contribute. This license change would, effectively, close WINE to me and any other developer who writes commercial software... forever. Here's why. As most people already know, the GPL and LGPL require developers who create "derivative works" to give their work away for free. But what most people do not understand is that if a programmer so much as looks at GPLed or LGPLed code, and later writes some code that performs the same function, he or she is open to accusations that the code produced later is a derivative work. (The late ex-Beatle George Harrison fell into a similar trap when he heard a song and, years later, wrote one with a similar melody. A court convicted him of "unconscious" copyright infringement because he'd heard the original song.) For this reason, commercial programmers simply cannot look at source code that's published under one of the FSF's licenses without taking a tremendous risk which could destroy their careers as programmers. This may be fine with Richard Stallman -- who in the GNU Manifesto stated that programmers should code for love rather than money and that good salaries for programmers should be "banned" -- but for those of us who need to put food on the table it is simply a risk we cannot take. Thus, if WINE is (L)GPLed, I can no longer look at the code, fix bugs when something breaks, or contribute to the project. Nor can I peruse the code in order to learn from it. It will, effectively, be as closed as a closed source product to me and to any other commercial programmer. WINE will be un-free and would not be open source (since it would be licensed under a license that discriminates against a group of people and a field of endeavor). Only a truly free fork (which I sincerely hope will occur if the license is changed) will be accessible to those of us who code for a living. It would be a sad day for those of us who would LIKE to continue to recommend WINE to users who wish to free themselves from Windows, as I would immediately have to stop installing and advocating the use of WINE. --Brett Glass (Who hasn't happened to contribute to WINE yet, but may do so if it remains open source)

9 17