wine-devel

wine-devel@winehq.org

84463 discussions

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

17 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So you mean that all the people that are current voluntering > > to work of Wine won't work on Wine if it is almost complete > > just because somebody else have done the parts they need > > to run their applications and that they will happily pay for > > the right to use it. > > No, I'm not saying they won't work on it when it's almost complete. > I'm saying that there may not be enough incentive to complete it if > all the parts are available under more or less proprietary > licenses. Maybe I'm wrong, but your reasoning that it's OK for people > who want games to have to pay for it certainly doesn't reassure me. What I meant is that for people that play games might it might make more sense to pay a monthly fee since most of them, I guess, lack the knowledge to contribute to Wine anyway. Companies wishing to use Winelib to port their productivity application are not in the same situation, they have the resources pay somebody to improve what they need or perhaps even do it themselves. Sure they can also choose to pay companies with business models like Transgaming but then they become dependent on them to fix bugs in the extra parts they supply. Actually, this is analogous to normal argument for using open source instead of proprietary software, nothing that is unique to Wine. In short: The incentive is the same as working on any open source software. Sometimes is makes sense, sometimes is doesn't. > > In that case it would be disasterous to make Wine run > > all Microsoft implemented non-core Wine DLL:s because > > then everybody would just be happy to use the Microsoft > > DLL:s and nothing beyond non-core would ever be > > implemented. > > It would not be a disaster, but it is certainly a potential problem > too. It is a smaller problem first because making the dlls run is > about as much work as reimplementing them, and because they are > completely proprietary, not half-way open source. But yes, I do think > a number of features could have improved faster if people didn't use > native dlls to work around the problems. There is a distinct possibillity that people used the time they didn't need to reimplement the working Microsoft implemented functions to implement functions that didn't work so it is quite hard to provide hard proof on this. Furthermore the fact that a lot of the Microsoft implement functions works might instead have encourage people to work on because SOMETHING work instead of giving up then NOTHING worked. In any case I think neither of us will be able prove the correctness of our respective theory.

1 0

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

17 Dec '01

> > > and if it does happen, will we find enough people to do what > > > XFree86 has been doing for X11? Maybe, and maybe not. When I hear > > > people like Patrik saying that it's OK for parts of Wine to become > > > proprietary because we can't do everything anyway, I'm worried. > > > > If wine was even CLOSE to being complete, I would agree with you. > > But you cannot change the license once it is mostly complete; by then > it will be too late. Why would you want to change the license when it is mostly complete? There will be very little reason for companies to enter the market at that time and why try to make it difficult for the few that might.

2 1

win32eviceIoControl problem
by Ancient Computers 17 Dec '01

17 Dec '01

When trying to run a game called Visual Pinball, I get this as console output. The DecodeHash problem can be fixed by using a windows version of advapi. What about the win32eviceIoControl problem, what is it about ? [root@localhost Visual Pinball]# [root@localhost Visual Pinball]# wine Vpinball.exe x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403b58f8,00010022,2):stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403b5d64)->(00000000,00001008) fixme:commdlg:GetFileName95 Flags 0x00000002 not yet implemented fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device NWLINK fixme:advapi:CryptAcquireContextA (0x405b5c30, (null), (null), 1, f0000008): stub! fixme:advapi:CryptCreateHash (0x405b5c34, 0x8001, 0x0, 00000000, 0x405b5c58): stub! fixme:advapi:CryptHashData (0x10010, 0x49ab80, 14, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x405b5c5c, 4, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x405b583c, 4, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x41615710, 4, 00000000): stub! _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

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

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