wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Big Bummer for running Shrinkered files!
by Robert Baruch 18 Dec '01

18 Dec '01

Uwe: > showsehframes.exe from the examples there foinds an endless loop even with > native msvcrt: That was a good idea, to try out that program. I'll have to review how that whole program works. Maybe it has something to do with the fact that scopetable is only valid inside MSVC code -- anything in a frame past the handler and prev ptr is compiler-dependent. Maybe it will work once I finish the EXC_CallHandler code. --Rob

1 0

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

18 Dec '01

> Patrik Stridvall wrote: > > > > > Patrik, > > > > > > The more I read your posts, the less I understand what you > > > are trying to say. You argued over many hundreds of lines > > > over weird technical details and various dubious assumptions > > > about what courts will do in the future. > > > > The main point is that what is legal allow is very unclear. > > Hogwash. I feel the LGPL is extremely clear. It allows > you to dynamically link to LGPL code without worries. Full stop. The clearness of the LGPL in itself is a non issue. The issue in the foundation that LGPL rests on namly the doctrine of derived work. > Patrik, it might be good for you to create a web page outlining > the problems you see in the LPGL; that would give you a > chance to explain > them more clearly than is possible in this forum. Do try to > be succinct. > I'd like to understand your point of view. Hmm. I think I already spend to much time trying to explain my point of view. I would rather answer questions concerning details insteed. Perhaps I will someday, but don't hold your breath.

1 0

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

18 Dec '01

> > But most apps wine will run *cannot* use a GPLed component. GPL > > expressly forbids being linked to a nonGPLed component. > *GPL does not > > only cover the source, but rather the USE of the components > as well. > > Read the > > license. It's quite an eye opener. > > I'd argue (though IANAL) that a nonGPLed win32 executable > running under > wine is not being "linked" to any GPL component - wine itself may be > linking to its own GPL components at run-time depending on > what's going on > with the win32 executable. But in terms of true linkage, I'd > have viewed > the win32 executable as more like a document that causes the host > application (wine) to load appropriate sub-components with > which to process > the document. MS Word (to use an example) might have to > dynamically link in > a special MS Word component to process specifics in my > document, it doesn't > mean my document is "linked" with the MS Word component does it? Ah, you are beginning to see the problem. :-) This is the spot on one of the main problem with the GPL. Proponents of the GPL are trying to use the doctrine of derived work as a means to achieve their goal without realizing (or rather ignoring) that if the doctrine of derived work supported want they wanted it would also, as a logical consequence, support to the absurdity you meantioned above. This is why I firmly oppose the doctrine of derived work and instead hope that the courts will embrace the much more senisible doctrine of combined work that I have been talking about earlier. Of course a strict doctrine of combined work would make the GPL and for that matter the LGPL largely meaningless, since you could distribute the LPGL work, the proprietory patch and a combining script seperately and let the user do the combining as thus no combined work is distributed and thus no violation of copyright law. Note that a doctrine of combined work doesn't effect normal commercial software at all since the end user is legally required to pay for the software if he uses it, regardless of whether the user used some patch offered under whatever license. It ONLY effects viral licenses. > Of course, we could all ask RMS his opinion but we all know > he'll interpret > it (once again) to mean whatever is required to spread his > GPL tenderhooks > as far as possible. Living in Wellington, NZ I'm having to > fight back hard > the temptation to make a "Sauron" joke here ... :-) I don't believe RMS is evil, quite the opposite, just that: "The road to hell is paved with good intentions"

1 0

Re: Big Bummer for running Shrinkered files!
by ek sqrl 18 Dec '01

18 Dec '01

On Mon, 17 Dec 2001 14:49:35 +1000 Mike McCormack <mike_mccormack(a)start.com.au> wrote: > Did you try running wine with -winver win98? Yes, Shrinker tries to load a VXD which is not allowed under Wine. At first I was going to implement a special Shrinker VXD replacement for Wine, but then I found that it wouldn't try to load the VXD under --winver nt40. Thus, I figured I would try to resolve the problems with running under nt40, since that would (at least theoretically) improve the existing functionality of Wine, rather than add new functionality. > > Did you try finding an Un-Shrinker? A quick search using google turned > up a few candidates. Haven't tried any out though. Yes, I've looked at them. They all seem to be h4x0r toolz with no source code. Some new news on the Shrinker front. I've managed to determine, for the most part, what Shrinker's exception filter function does. It's a minefield! Recall that earlier I said it was looking for a magic signature in ntdll.dll. I found all of the landmines. The first landmine makes sure the exception handler was called with the code "call ecx". If not, the process dies. Next, we read 8 bytes from the process around that location. If the read fails, the process dies. If the code starting with the call is not FF D1 64 8B 25 or FF D1 64 8B 0D, the process dies. It then tries to allocate some memory, and copies some of the process code into that memory. If the allocation fails, the process dies. With that in mind, it seems that the only thing it's really looking for is that signature. So one idea that I had is a "Shrinker fixer". When Wine loads an executable, it would look for this specific exception handling code, and then NOP out the checks. Is that a reasonable approach? --Rob

4 9

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

18 Dec '01

> Did anybody mention that if wine moved to an LGPL license, we would be > able to borrow code from a wider variety of other projects? > > That would include KDE, libXML, Bochs, OpenOffice, GTK+, Atheos, jCIFS > and any other LGPL (or compatable) projects. Sure, but I would much rather use them by linking them to Wine than borrowing code and having to maintain it. Whether Wine is LGPL or BSD matters not in such cases.

1 0

Re: Installshield 6 (inter-proc) patches
by Roger Fujii 18 Dec '01

18 Dec '01

Alexandre Julliard <julliard(a)winehq.com> wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > As for the license of Wine, I was among the ones opposing the LGPL last > > time it was discussed, and I have not changed my mind. I feel that Wine is > > most widely useful if it keeps the X11 license, and usefulness is more > > important in my mind than making it 50% harder for companies to "steal" > > the code. If X11 is so bad for large projects such as Wine, why is the > > largest project of all, XFree86 (and associated projects like DRI), still > > using it, even though its maintainer would have the power to switch to > > e.g. the LGPL or even GPL with a snap of the fingers ("sublicensing" it)? > > A thing to keep in mind is that X11 got almost killed by licensing > issues and the proliferation of closed source vendor versions. You understanding of X11 is pretty flawed. X11 had closed parts of its implementation practically from the very beginning. Look at the original X11 contributers. It was DEC, SUN, IBM... The main reason for the dry spell was that it became a mature product. Why tinker with stuff that basically works? Vendors, quite unlike the GNU people, really resist changing things without a good reason. I think the current interest in the X project was due to the advent of so many graphics cards plus 3d/video. Look at gnuemacs - it's GPLed, and had a really long dry spell. Was the lack of interest the result of the licensing? > If the XFree86 team hadn't picked it up, there probably wouldn't be a free > version of X11 available today. What are you talking about? What do you think is sitting on www.x.org? > This is something that could happen to Wine; Wine should be so lucky as to be accepted like X11..... > 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 given its current state, I think that a *gpl license would just discourage companies from even looking at wine (I can't see why any company would like *GPL over X11 so long as they are not the givER - this is not to say they won't accept *gpl, just as to what the preference would be). And given that IMHO, a lot of wine work to be done (looking at Direct* and other M$ stuff) falls under the unpleasant column (ie, most people won't do this for fun), discouraging commercial work doesn't seem to be the way to go. -r

5 6

Re: Installshield 6 (inter-proc) patches
by Mike McCormack 18 Dec '01

18 Dec '01

Did anybody mention that if wine moved to an LGPL license, we would be able to borrow code from a wider variety of other projects? That would include KDE, libXML, Bochs, OpenOffice, GTK+, Atheos, jCIFS and any other LGPL (or compatable) projects. Mike http://freshmeat.net/browse/16/?filter=&orderby=popularity_percent+DES C > 0. Isn't Wine's best interest to evolve and develop as fast as it can? ------------------------------------------ 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: Installshield 6 (inter-proc) patches
by Patrik Stridvall 18 Dec '01

18 Dec '01

> > Then if the LGPL holes are dangerous, the X11 license should be even > > more dangerous; after all it's a much larger hole than the LGPL will > > ever have. I still don't understand where you are trying to go with > > your argument. > > > This has been my argument against Patrick exactly. Some > protection is > better than none at all. As a general rule, yes. However this time the protection comes with a price. > > You really make it sound like the LGPL is some kind of unexplored > > wilderness that we shouldn't venture into. The fact is that a large > > majority of free software projects use either the GPL or > the LGPL, and > > in practice it works just fine for them, just as I'm confident it > > would work just fine for us. > > > Agreed. The LGPL is a very well-written fairly clear > license. There are > some borderline cases as mentioned, but this does not mean > that we should > thus throw the possibilty of LGPL completely out the window. The problem is not whether LGPL is well written or not the problem it is the doctrine of derived work. That is very unclear because of lack of good case law.

2 1

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

18 Dec '01

> David Elliott <dfe(a)tgwbd.org> writes: > > > The crypto part of ADVAPI32 was the example I used. Let's > say I were > > to write a CryptoAPI implementation as a set of seperate > source files. > > With the LGPL I could compile all of that stuff and refer to it as a > > library. What is a library? I would say one or more object files > > linked together form a library. I could then take my CryptoAPI > > library, link it with the rest of Wine's ADVAPI32 and distribute a > > libadvapi32.so that could be dropped into a wine install. > > If it is a completely separate library that doesn't contain portions > that are derivative work of ADVAPI32, then yes you can do that. But > you cannot for instance decide to reimplement CreateWindow and not > release it simply by putting it into a separate file, which was what > Patrik suggested; because your new CreateWindow will necessarily use > internal functions and variables of USER32, and thus would be > considered a derivative work. It takes more that use to be considered a derived work, but the doctrine of derived work is central to the discussion. One thing that is very important to note is copyright only protects expression not fact or ideas. In this case we are talking about use which I guess is better to talk about in terms of functionality. Functionality on the other lies closer to fact or ideas than to expression so I would consider it doubtful for the courts to extend the doctrine of derived work to protect this.

2 1

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

17 Dec '01

> Alexandre Julliard wrote: > > > > Gavriel State <gav(a)transgaming.com> writes: > > > > > There are several factors to that equation, and I'm > afraid we don't have > > > a firm ETA yet. > > > > Well, this worries me. It sounds like you are planning to > do the same > > thing you did with your DirectX stuff: by making the code > available on > > your site, and promising to release it at some hypothetical future > > date, you remove all incentive for other people to spend time > > improving the main Wine, thus ensuring that it always lacks some > > features. I don't like this at all. > > > > If you can't/don't want to release your code, I'd strongly suggest > > that you reconsider your strategy of making it publicly > available. If > > it was only available to paying customers, there would at least be a > > reason for other people to work on a free implementation. But if > > everybody who needs some feature in Wine can simply download WineX > > instead, no one will spend time re-implementing that > feature. This is > > beginning to seriously hurt the project, and we need to > find a way to > > address this issue. > > The DCOM issues had been ignored by other Wine developers for YEARS > before we came along. Yes, but that is because it hasn't been needed for anything but obscure application until now. > It's not at all clear that our work there has > discouraged anyone else from working in that area. Granted. > To say that > our work is preventing anyone from doing a free version of DCOM is > completely incorrect. To the contrary: we have already contributed > substantial amounts of this code to the public tree - thousands of > lines, in fact. That can only help anyone with a sudden and > unexpected > interest in recreating our work. That is absolutly true and would make any decision not to release it under a free license even more strange. Note however that I'm not accusing you of not releasing it. Not yet, but I reserve the right to do so in the future. Anyway, see below. > Now, it is our firm desire to see *all* of that code end up > in the main > version of Wine. The fact is, unfortunately, that we simply cannot > afford to give everything away as soon as we write it. We only got a > minimal implementation of the DCOM code working six weeks ago. We are > not a rich company, with millions in VC funding to burn; this > means that > our DCOM work has to remain under the AFPL until we can find a sponsor > willing to defray some of the tens of thousands of dollars it cost us > to develop it. I think that you look a things the wrong way. Think of the expense as an extra cost you pay for being early to the market. Sure it won't make your accountant much happier but thats life. :-) What I mean by that is that the DCOM code aiming to get InstallShield to work is not really something that has very much to do with the product you that your customers want to buy. Installation is done only once and can be made in the real Windows if you dual boat and beside it is really something that Wine should have supported already. In short, it was something you had to do because Wine was not mature, because you wanted to be early to market and holding it as proprietary code are unlikely to give you any advantage for very long. If you won't release it somebody else will implement it before long. > Furthermore, we are committed to writing quality, robust > code. We don't > think it's in anyone's best interest for the current version > of the code, > which is effectively limited to the requirements of > InstallShield, to be > used as the basis of future DCOM related work. We in the midsts of > working on a much more flexible architecture which will permit more > than just typelib based proxying. > > I don't really think this affects individual users at all. They can > simply download and use the code from our website, or apply the > necessary patch to WineHQ wine. They can even redistribute it all > non-commercially should they wish. > > Without a doubt, we are committed to the Wine project and have already > contributed a great deal of code to support it. However, to > maintain the > quality and integrity of the project, we stand by our decision of only > contributing code when it makes sense to do so (in order to > allow us to > continue developing quality code) and when it reaches a > certain minimal > degree of quality. Yes, I fully understand that, I'm grateful for all you have done and I'm not making any accusations right now. However I reserve the right to do so in the future. > Publicly questioning our ethics is certainly not the right solution > nor is it in the spirit of the project, especially given how much we > have supported it to-date. We believe that we ARE doing the Wine > user and developer community a service and propelling it further. I don't think Alexandre is questioning your ethics. I think he is question what relation the Wine project should have with you based on praticial issues and not on ethical issues at all. In short: Should the Wine project wait until you release or should it not? > The > only people that our lack of haste in contributing code back really > affects are organizations that want to make immediate commercial use > of the code. These organizations include the one you work > for, and its > clients. If you want to see the DCOM code Wine-licensed soon, you > need to talk to your boss and your clients, not me. :-) I fully understand that you wish to take every opportunity to get some extra income but I think your analysis is partly wrong. Sure it is possible you might get some sort of one time payment from somebody if you are a little clever, but realize the following. A significant part of your potential customers consists of, I guess, people who would very much like to not to dual boot any longer and their first priority is that their normal productivity applications installs and works. Games are their second priority and so as long InstallShield doesn't work in normal Wine you risk losing them since they will continue to dual boot and presumably continue to play their games in Windows. > At this point, I think it would be best if we were to take this > discussion off-line so that we can determine a solution that works > for everyone. For any discussion concerning milking some money out of CodeWeavers or their clients, absolutely. Not my problem. :-) However one important problem that really can't be discussed off-line, is what your relation you wish to have to the Wine project. In fact, it can't be discussed at all, only your actions can determine it. I will be blunt: Do you see yourselves as a complement to Wine or a competitor to Wine? Because not releasing important core code like code needed to install important applications especially non-games might be interpreted as really wish to compete with Wine instead of being a completement. Note again (the third(?) time) that I'm not accusing you of anything, at least not yet, but I wish to point out that it might hurt your public image if people see as a competitor instead of a complement to Wine. Being vague and saying: "There are several factors to that equation, and I'm afraid we don't have a firm ETA yet." will not help your image.

10 16

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

17 Dec '01

> > But you cannot change the license once it is mostly > complete; by then > > it will be too late. > > If it was mostly complete, what would it be too late for? Yes, I wonder that as well. To late for a 100% open source world perhaps, but then only the most naive (like Richard Stallman) actually think it is realistic. Open source is good for some things, but it is not the solutions to all problems. > Patrik Stridvall <ps(a)leissner.se> wrote: > > > 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. > > I was using the following lines of thinking: If it were > mostly complete, > any changes would most likely be the result of bug fixes or > minor improvements. Exactly and therefore there would be very hard to find a niche for a company to profit in. > In the end, if you look at the larger projects (mozilla, > openoffice, perl), you will > see that any of them uses a straight *gpl scheme. My You mean _neither_ of them, I guess. > suggestion is that if you are > going to change it, change it to something like a currently > existing project that > has commericial involvement (mozilla/openoffice). And the advantage of this would be the following?

1 0

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

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

Big Bummer for running Shrinkered files!
by Robert Baruch 17 Dec '01

17 Dec '01

The plot sickens... Here's the background info. I have a file, power-structure-demo.exe which can be obtained from www.write-brain.com. Uwe has another file, tar2001.exe. Both have been compressed by the commercial Shrinker utility. When these exe's are run under Wine, Wine will spin. A look at the +all debug messages shows that the app tries to write into its own code area in order to purposely throw an exception. Kind of like this: void my_function() { try { *(char *)&my_function = *(char *)&my_function; } catch (access violation) { } } Shrinker was written using Visual C++, since this article at MSJ (http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0197/exception/exce…) describes the code's exception handler perfectly. The Visual C++ exception handler, which gets control of the app from ntdll.dll, first calls a filter function corresponding to the catch clause to see if the handler associated with the catch will handle the exception. If so, it passes control to that handler. Otherwise it moves to the next catch clause. Here's the weird thing. The filter function looks at the code which called the exception handler, which is in ntdll.dll. Under Windows, this code is FFD1 (call ecx). The filter function compares that code to the call ecx instruction. At first the only difference between Wine and Windows is this comparison. A register gets decremented if the comparison fails. However, then the function calls ReadProcessMemory with a handle of -1 (what does that do?) to read 8 bytes, and compares some of the data returned to FFD1, and to 648B25 (which is the beginning of the next instruction after call ecx, mov esp,fs:[00000000]). Things rapidly deviate from there, resulting in Wine spinning and Windows continuing execution. 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? --Rob

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