wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

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

17 Dec '01

> While I am thinking about this, there are some interesting > things in the > LGPL. One of these is that you can modify the LGPL library > to work with > your code. The catch is that you have to release source to the > modifications and that the modifications must not require that your > proprietary component be included. The text of the license > mentions that > if you modify a function that computes square roots to hook into your > proprietary components that the function must still compute > square roots. > But in Wine's case, many functions don't do what they are > supposed to do, > or they do what they are supposed to do but that's not what > actually needs > to be done. That is a very intresting point. Thank you for bring it to my attention. I didn't realize that. Hmm. I will have to think about it what this means, if it indeed means something. > This stuck out like a sore thumb to me, but > maybe it's not > such a big deal. Can you perhaps say exactly what bothered you?

1 0

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

17 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > > No, of course the LGPL doesn't provide absolute > protection; nothing > > > does, and I don't think absolute protection is desirable > either. There > > > are some things that the LGPL clearly allows, some that it clearly > > > forbids, and a number of border cases, that frankly are only > > > interesting to people who want to try to get around the license > > > restrictions. And what would be the point of doing that? > > > > Making their business model work. > > Trying to ensure investment return. > > That would be the case if the code they are using magically turned > LGPL once they had invested millions. But that's not possible, since > only new code becomes LGPL. Indeed and that makes any protection LGPL gives even weaker. My earlier analysis was based a 100% LGPL:ed Wine... > Now, if someone is basing his business > model on turning LGPL code proprietary by exploiting possible > loopholes in the license, I wouldn't suggest investing in his > company... I don't think our goal in choosing a license is to make > sure every flawed business model can succeed. There are lots of > reasonable business models that can be built on a LGPL (or GPL) code > base. Lets arguments sake assume somebody is called Bar and have a business model that might possibly be illegal under your interpretation of the LPGL. What's preventing him from creating a library called bar under his proprietory license as well as supplying a patch under the LGPL that results in code looking like: void WINAPI Foo(void) { #if HAVE_LIBBAR BAR_Foo(); #else /* Old Wine code */ #endif } Wouldn't this always be legal under the LGPL? In that case the only thing you did by threatening to sue him was to increase his costs. The point is, you didn't get his code, that it seems, that you hoped you would get. > > The current license is something that is easy to understand and > > are unlikely to scare companies like Transgaming away, but can > > you really say the say same about LGPL? > > OK, now we are getting somewhere. So your argument is basically that > the LGPL might scare some companies away. Yes. > Yes, I agree that's a > possibility. Good. > Most likely these companies will have been scared away > from Linux already, since many other things they need are also LGPL > (most notably the C library). That is a claim that makes no sense at all. Why should anybody want to make a business model out of modify or making additions to the almost 100% complete C library? One of the main reason Wine has the possiblity at all to attract companies like Transgaming is that it is not complete far from it. > But of course this possibility cannot be > excluded. Indeed. > I think that the risk of this happening is not larger than the risk of > having companies hold hostage pieces of Wine, and the damage in the > second case is much larger; so I think the LGPL would minimize the > potential damage to the project, even if damage cannot be excluded in > any situation. Your analogy with hostage holding is a bad analogy, sure I understand that you are refering to Transgaming promises to release eventually. If you don't believe them announce that publicly and developers that might be hanging back in fear of doing "double" work might step forward. They might not, of course, but then perhaps nobody was intresting in doing work in that area, Transgaming or no Transgaming. > Of course only the future can tell us who is right. Agreed.

1 0

Filename case handling
by Duane Clark 17 Dec '01

17 Dec '01

I have a question about the handling of filename case when trying to find an existing file. When files are on a win filesystem, the case is ignored, by the setting of flags by DRIVE_GetFlags(). As expected. When on a ext filesystem, that call sets the DRIVE_CASE_SENSITIVE flag, which is ok. But then the flag is used in the call to DOSFS_FindUnixName() (from DOSFS_GetFullName()), and I guess the fundamental question I have is under what circumstances wine would want to do a case sensitive search. One of my apps (Xilinx ngdbuild) always supplies upper case names when searching for a file, but the files always have lower case names (they were created by another Xilinx app). When searching for this file in DOSFS_FindUnixName() on an ext filesystem, the first test always fails, because we do a case sensitive test: if (!ignore_case) { if (!strncmp( long_name, name, len )) break; } However, and here is the other part I am questioning, if the file is an 8.3 filename, an alternate dos filename is created by DOSFS_ToDosFCBFormat(), and then a second test is performed here: if (!strcmp( dos_name, short_name )) break; This call passes and the file is found. However, if the file is not an 8.3 filename, the call to DOSFS_ToDosFCBFormat() fails, and no case insensitive test is made. So it seems to me that either a case sensitive search should be made in both cases, or in neither case. And of course I think that it should be both cases (since this fixes my app) :-) Duane

3 4

Wine and Drivers
by Viacheslav Zilberfayn 17 Dec '01

17 Dec '01

Hello, I'm wondering if anyone ever attempted to use wine to run Windows driver, specifically videocard drivers. Or at least to load them. I'm thinking of using Wine to load windows drivers into Linux, along with whole DirectX. I understand that drivers are special s/w, but I guess they use smaller part of windows api. Any information/opinions would be appreciated. Slava ===== --- NOTE: EMAIL HAS CHANGED !!! --------------------- Slava Zilberfayn | Home +1(416)7838430 EMAIL: slavka012(a)yahoo.ca ADDRESS: appt 1219, 377 Ridelle ave, M6B1K2, Toronto, ON, CANADA ______________________________________________________ Send your holiday cheer with http://greetings.yahoo.ca

2 1

Microsoft Antitrust Remedy proposal, take 3
by Dan Kegel 17 Dec '01

17 Dec '01

I've learned a fair bit since putting together my essay on the States' proposed remedies. In particular, Microsoft's response to the States was enlightening; it pointed out the parts of the Court of Appeals ruling that need to be heeded when fashioning a remedy. I now feel that the States' proposal has little chance of being accepted by the judge. The Proposed Final Judgment negotiated by Microsoft and the DOJ is probably the right starting point for any new proposals. Accordingly, I've started over, and this time I'm sticking very close to the negotiated settlement, and paying close attention to the law. As before, you can read my proposals at http://www.kegel.com/remedy.html I'm looking forward to your feedback. I've set up a mailing list at http://groups.yahoo.com/group/ms-remedy/ (aka ms-remedy-subscribe(a)yahoogroups.com ) for those who want to discuss this further. Together we can find a way to make the settlement more just and fair, or I'll eat my hat. Dan Kegel http://www.kegel.com

1 0

Re: Big Bummer for running Shrinkered files!
by Mike McCormack 17 Dec '01

17 Dec '01

Hi Robert, Did you try running wine with -winver win98? Did you try finding an Un-Shrinker? A quick search using google turned up a few candidates. Haven't tried any out though. eg. http://www.programmerstools.org/unpackers.htm Mike > 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? ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

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

17 Dec '01

On 2001.12.16 21:39:52 -0500 Peter Hunnisett wrote: > <snip> > > > fixme:dsound:IDirectSoundBufferImpl_QueryInterface > > Unknown GUID > > {31efac30-515c-11d0-a9aa-00aa0061be93} > > > > (undocumented API call?) > > > > Anybody knows what this GUID refers to, or how to > > research it, I would be > > much abliged. > > Get a copy of the DirectX SDK and check out, most > likely, dsound.h. The GUID defines the interface that > the application is trying to aquire through the > IDirectSoundBuffer interface it already has. You'll > probably find that it's basically asking for an > unimplemented feature of direct sound. Thanx Peter. I'll check it out (tomorrow... ;)) Ian -- Linux, the choice | "Eat, drink, and be merry, for tomorrow you of a GNU generation -o) | may work." Kernel 2.4.15-gr /\ | on a i686 _\_v | |

1 0

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

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