- wine-devel - winehq.org

configure broken?
by Oliver Sampson 15 Dec '01

15 Dec '01

Howdy, I just tried to update my CVS version and I get the following: checking size of long long... ./configure: line 6355: syntax error near unexpected token `<<<<<' ./configure: line 6355: `<<<<<<< configure' Really, all is did was type 'cvs update' :-) Thanks, ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

6 7

Re: Various OSS fixes
by Ian D . Stewart 15 Dec '01

15 Dec '01

On 2001.12.12 15:27:16 -0500 eric pouech wrote: > this patch should fix a lot of last OSS bugs > thanks to all the people which reported issues and took time > for the testing... Eric, I tried applying this against build 20011108, and got the following error message: 23 out of 41 hunks FAILED -- saving rejects to file dlls/winmm/wineoss/audio.c.rej Do I need to upgrade (or downgrade) Wine before applying this patch? Thanx, Ian -- "Looney?! I'm just as sane as the rest of you. Never mind..." --DaemonThread, comp.lang.java resident looney Get my GNU Privacy Guard public key at ftp://ftp.stewartcastle.com/pub/idstewart.key

2 2

Problems with FreeLibrary winmm.dll
by Uwe Bonnes 15 Dec '01

15 Dec '01

Hallo, somewhere in the MS Encarta99 installation the programm tries to start /dosd/windows/temp/~GLJ6675.tmp d:\\wine95\\system\\SWFLASH.OCX In the flow of that program, it calls FreeLibrary(Handle(winmm.dll)). After that, a GetModuleHandle16("user.exe") leads to a crash, indicating that the linked list of 16 bit dlls is disturbed. Denying FreeLibrary on a handle to winmm.dll circumvented the problem and let the program continue. Any ideas for a clean solution? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 15 Dec '01

15 Dec '01

At 07:47 PM 13/12/2001 -0800, you wrote: > >What do others think? I feel rather dismayed by the whole discussion. First to all you lawyers who have already posted their legal opinion, you can dismiss all that I will say : I'm not a lawyer and I don't want to be one. It's only a low-level common sense point of view, what I think is right or wrong. First a link : http://www.gnu.org/gnu/thegnuproject.html This is the philosophy of the gnu project, from the guy who designed the cornerstone : the Gpl (I will say Gpl even if what is in question here is LGpl : from my point of view, it is only a technicality) You will notice the enormous number of terms evoking public rights, user rights, help your neighbour philosophy. I have nothing against that by itself. However, what I find surprising is the use of this philosophy. You'll find many examples of that, in another of this thread's posts for example : >A few years back, Ingo Molnar >(or Linux Kernel fame), wrote to the wine-devel list saying that he really >wanted to contribute the project but didn't because of the lack of >protection of his work from the licence. Here is the keyword in my opinion : *his* work. in this particular case Ingo Molnar could mean the right thing of course, I can't say for sure from a short citation - but there is so much more of this stuff. Here is more if you want, from another poster : >I -have- had to deal with companies stealing my GPL code Here this is so much more clear. *My* code. They have stolen from *me*. Where are the users's right ? I don't want to say that it is all right to use Gpl code in proprietary works. But I think that any legal (real) action should - morally - only be done when an user has been really wronged. I think that a user getting proprietary work including gpl'ed code could ask for a court to order the release of the full code of the app he bought. He could ask for getting his money back for all the licenses (beyond the first) that he bought, since he had the right to manage the installation of additional copies himself. He could ask the court to sweep aside any Eula limiting the company responsibility since the hiding of Gpl code removed his right to fix the bugs himself. All this means civil litigation, damages, money. >From my - common sense, not legalistic - point of view, that would be entirely appropriate. In this context, the Gpl developer could associate to the first legal action, so that his *moral* right could be recognized and - more importantly - the infringement proved. But a 'pure' Gpl (not the double licensing sort) developer suing for himself, without any actual user wronged, is not morally acceptable in my opinion. The usual argument about Gpl, that courts would not accept the action because there is no material interest (money) for Linus Torvalds, for example, in Linux, is akin to mine, but my point of view is not legalistic. This is not right because if he asks for money, he is doing a pitiful mockery of the generous philosophy expressed in the Web page I referenced. If he asks for the society to punish the deed, a penal action in opposition to a purely civil action, he is doing something even more distateful. He is asking the society to consider the infringement on his rights something so important that the doer should be punished even in the absence of any tangible damage for anyone. I think that he is justifying the idea of 'intellectual property' : copyright infringement is stealing, infringers are thieves (criminals?) (words quoted because I refuse the idea entirely - and yes, I'm aware that Gav State himself approves of it :-)), like the society can punish an (old-fashioned) thief even if by mistake what he stole was entirely valueless. I believe that in your approach (I mean here you, Alexandre Julliard), as in the case of the developers I quoted, I have not heard much about users rights. If you cared that much for users, as is implied by the Gpl license, the work made by Codeweavers for Borland would be repellent : yes, the code (all of it ?) has been released to Wine. But Kylix users don't have the possibility to get the Wine source code used; they don't have the right to get latest Wine code and maybe fix bugs. This is scandalous from a Gpl point of view, yet no Wine developer has ever said anything against it. Why what was a mere possibility before has become urgent now ? Transgaming, of course. Transgaming is, in your words, taking away the 'mindshare' of users and developers. Gav replied that end-users were not harmed since they got the source anyway, but it has not mollified you - to the contrary. I'm sorry but this sounds rather selfish. You have entirely the right to be selfish about your (enormous) work of course, but a proprietary license is more logical in this case. You want to use the Gpl as a tool, but I don't see a lot of respect for the philosophy that is behind it. What I find even more disturbing in what you said is the allusion (when replying to Patrick) to a future tightening of copyright laws, a tendency that is in my opinion directly linked to the idea of copyright, patents, etc being 'intellectual property' assets, and infringers thieves stealing them. You seemed to welcome the additional protection it would give Wine. What I hear is : more Dmitry Sklyarovs. More programmers in jail. Is this what you want ? Are you really so eager to send legal injunctions to people ? No one should think that in a legal action the programmers doing the actual work will be left alone and the 'suits' will go to jail. This is not how this world works (not that I think that the 'suits' deserve it anyway) Don't think also that you can avoid that easily : it's said that Adobe never intended for Dmitry to be jailed, and they backed away as soon as it happened. But he stayed in jail nevertheless. I believe that the freedom privation that someone sent to jail is suffering is more grievous that the privation that an user suffers when he has no access to the code of his application (in most cases - there may be exceptional cases, but certainly not *computer games*) and is not proportionate to the deed. That's a very important reason for which I am afraid to hear Gpl developers brag about threatenings they can make to people 'stealing' 'their' code. I have two more practical remarks to finish my ramblings : 1) if Wine turns into a legal machine hunting 'intellectual property' 'thieves' (and there is *a lot* of money involved with Win32 api of course), it could get some really bad public opinion. I think that one of the frail walls protecting Wine from legal harassement is public opinion disliking people using lawyers instead of competition. Be done by as you did, could say the public opinion later - when the MS lawyers come. 2) You seem to think that Transgaming or similar companies are or could be responsible for the low Wine mindshare among developers I don't think this is explaining even 1% of the problem. There are much more bigger reasons for Wine not attracting and - more importantly - not keeping developers. I don't think this particular discussion is important now, though. Gerard

4 3

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

15 Dec '01

> > > (after all, they do follow on work that we did). > > > > Not according to the David Elliot and I agree. > > > > Ah, so the summer Andreas spent here working on > InstallShield 1-5 was of no value, and the past > two years that Alexandre has spent reworking > the internal process and window communications > infrastructure of Wine had no value, and the > three weeks that Huw spent staring at hex > dumps implementing Type 1 Typelibs was clearly > just some insane British stiff upper lip sort of thing. You may perhaps not like it and David Elliot may of course answer himself because of how the LGPL is constructed above doesn't seem to matter. Note that this has nothing to do with the analysis that of the weakness och (L)GPL the I did, merely a strict reading of the LGPL. If you choose GPL on the other hand David seems to agree, while I might not, but that is a different issue. IIRC LGPL primarily concerns itself that the LGPL:ed part of code should be able to relink itself with the proprietary part when a new version of the LGPL:ed part is available. Face it doesn't provide the protection you want.

1 0

Re: [RFC] Async I/O patch: server code + ReadFileEx()
by Mike McCormack 15 Dec '01

15 Dec '01

i'm pretty sure i removed all references to FILE_GetTimeout from files/file.c. Perhaps you've got one of my other patches in there too? There shouldn't be any warts, as my diff was against the latest CVS. Mike >> Hi Lawson, >> >> another user head space error... i forgot to include async.h .. >../dlls/libntdll.so: undefined reference to `FILE_GetTimeout' >collect2: ld returned 1 exit status >make: *** [wine] Error 1 >[whit@giftie wine]$ > >This might be something stupid I have done, OTOH she had warts, and it >might not be. I'll sort it out later. > >Lawson ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

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

15 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Therefore I'm happy to leave things like DirectX to companies like > > Transgaming for the time being since people that wants to play games > > are more likely to be happy with the way they can support > Transgaming > > ie paying a monthly fee. > > Then I guess you are also happy to leave OLE support to company Foo, > and networking support to company Bar, and multimedia support, common > controls, etc. to yet other companies. After all, people who need > these features would be happy to support these companies, right? Not always no, but that is a choice primarily for them. It depend on their priorties. I think Transgaming business model makes sense for a lot of gamers. However I don't think people using for example networking would like their buisness model and they are much more likely to support the core Wine project. > As > long as the free version of Wine runs Solitaire we don't need anything > else, right? There is no need to sarcastic. > Or is it different because the applications *you* care > about need these features but not DirectX? Not, primarily no. It is because I don't believe this is what will make or break Wine in the long run. > > Using your strict interpretion of the LPGL it will > significantly increase > > the cost of entry to the market, thus requiring higher risk > of entering > > the market, even with a basicly sound business model. > > No, IMO it will lower the cost of entry, because more code will be > available. So if you want to make money with Wine you won't need to > first buy all the pieces you need from the various companies that hold > them proprietary. Transgaming could probably never have entered the > market if all the development that was done before them had not been > released as free software. > > > > Well, I strongly disagree. Wine is supposed to be a free > > > implementation of Windows; if making it successful > requires making it > > > non-free, we might as well stop right now. > > > > "He who defend everything, defends nothing" > > > > Need I say more? > > What do you suggest defending then? Nothing? The ability to run only > your favorite application? I still don't understand your position, > and I can't say you seem to really understand it yourself. We should aim at ("try to defend") trying to get much resources (read: developers) as possible to work Wine and we thus should aim for productivity applications because that there the resources of the world are. Then we can try to reclaim the nices that companies like Transgaming has tried to reclaim.

1 0

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

15 Dec '01

> On 2001.12.13 18:43 Patrik Stridvall wrote: > > > Patrik Stridvall <ps(a)leissner.se> writes: > > > > > > > Umm. I feared that question would come. The "protection" > > > the LGPL (or GPL) > > > > that Marcus proposed is IMHO largely an illusion when it > > > comes to libraries. > > > > > > > > Sure we might use a strict interpretion as a weapon in > a PR campaign > > > > against possible voilators but we don't have the > resources to sue > > > > somebody and I very much doubt we would succed either. > > > > > > I think you greatly underestimate the power of such licenses. > > > > That is what remains to be seem. Many laws doesn't make logical > > sense anymore or becomes inconsistant in the new brave world and > > the attempts to adapt them often introduces new problems. > > > > The attempts of various courts the interpret the uninterpretable > > inconsistancies, without realizing it, futuremore adds to > the confusion. > > > > Expect extreme uncertainty to be the keyword for the > immediate future. > > > > Patrick, is your glass always half-empty? There is no need to be > completely and totally pessimistic about everything. Just > look at the > archives. Almost every argument you have ever made on this > list begins > with some statement about the courts being stupid or corrupt or > something. I do not believe that the courts are corrupt just that they haven't realized that world is much more complex than current laws seems to think it is. This is of course not only the courts problem. It is primarily political problem but I do not believe the politians will figure this out before a court point this out to them. Actually I quite optimistic than they will figure it out eventually. I do believe in the democratic process, however I'm very pessimistic than this will happend anytime soon, ie in the next few years, and in the meantime it will do considerable harm by adding confusion to the marketplace. > Really dude, lay off the slashdot for a while. Well. Kuro5hin is still down. :-) > With that said I'd also like to apologize for saying that > (but it still > needed to be said). No need to apologize. > Alexandre is correct that you are greatly underestimating the > power of the > FSF licenses. Remember, the GPL and LGPL and also the X11, > BSD, etc. all > give you rights that by law you would not have. True, they do. But if you don't need thoses rights, being bound by the obligations is ridicoulus. What part of: I do not distribute any (L)GPL code. I just ship my work under whatever license I wish so the end user after he has fullfilled his legal obligations to me can combine some (L)GPL:d code, that he can legally download seperately, with my work. > > > AFAIK > > > nobody in the world is currently shipping code (except maybe by > > > mistake) in violation of the GPL or LGPL, despite the > fact that it has > > > never been taken to court. > > > > True, it does have some power because few wants to be > > named a bad boy, but that might mean less and less in the future. > > > You are deluded if you think companies who have been in this > position were > only concerned about PR. That was exactly was I said. Many companies in the open source world care about PR right now, however that might change in the future as the market grows. Money talks... > Companies are concerned about only > one thing: > money. Any company that is not conerned about money as > priority number 1 > is broken. Hell, by law they have to be. ... bullshit walks and I see there is no disagreement from your part here. In short, I think we agree. > The bottom line is that someone decided that the cost of > bringing their > product into compliance with the (L)GPL one way or another > was less than > the cost of the alternatives. Exactly and since I think the (L)GPL as applied to libraries is very weak there is not much we can do about it. > > Then we have the middle case by have say the Crypto API that is > > a part of ADVAPI32. Does distributing a whole file replacement of > > dlls/advapi32/crypt.c represent a violation of GPL or LGPL? > > In that case why? The Crypto API is largely independent of the > > rest of ADVAPI32 it could as well be a separate DLL. > > > > Hmm, let me think here about what the LGPL states. Let's say > Advanced > Crypto Systems (made up company, hereafter refered to as ACS) > decides they > want to write a proprietary implementation of the crypto code > in ADVAPI32. > > The LGPL specifically states that you may statically link > LGPL code and > proprietary code to form a new library provided you follow the > conditions. Basically that means the same as usual, that > end-users must > be able to replace the LGPL part with a newer/modified > version given that > the interface remains the same. So ACS would be entitled to > provide for > example a libadvapi32.so file that could drop into an existing wine > installation as long as they also at the very least provided > their object > code before linking it with the rest of wine which would > allow an end-user > to compile a newer version of wine and link in the ACS crypto > support. > ACS could instead provide source code, but it need not be under the > (L)GPL. It could be under a license only allowing redistribution to > people who have a license for the binary. > > So basically to answer your question: no, it does not violate > the LGPL, > though it sure as hell would violate the GPL.. But as > Alexandre said, the > GPL is extremely inappropriate for Wine, and as such I > recommend we drop > the GPL issue immediately and focus on LGPL. OK. So since to take Transgaming's implemention of DCOM (in order to run InstallShield) as an example there is nothing we even if we used LGPL since DCOM is a distinct part just like the Crypto API. So what is the point of using LGPL? > > Any protection that (L)GPL provides is to a large part based on > > myth and legend. > > > > In addition hypocritical people at for example Slashdot also > > seems to wish to apply different standard at open source licenses > > and proprietary licenses. > > > > So company cries that their products shouldn't be hacked (having a > > part replace) should be ignored despite their insistance that a > > paragraf of their license has been violated, while any violations > > of the (L)GPL doing essentialy the same thing (replacing a part) > > should be strictly enforced. :-) > > > As Alexandre said in his reply to this message, these are two > different > things. As noted above, the (L)GPL gives you privileges you don't > otherwise have. An EULA takes away rights you should have. > EULAs are > actually pretty questionable if you think about it. First of all note that I'm primarily talking about an EULA as a license presented pre sale not a license presented post sale ie a shrink wrap license. Yes. EULA:s take away some of your rights, but whether you should have some rights is a matter of law (or the constitution). If you are say a beta tester of say some game you are often forbidden to talk about the game to others. This is a clear violation of right to free speech. However that is not legally a problem since you recieved some consideration in return ie you got to play the game in advance. Of course public intrest sometimes forbids enforcement of some clauses like for example reverse engineer is legal and can't be taken away with a license. Furthermore the right of first sale gives the right to resell the work. (providing of course that a sale has taken place which is probably not so in the beta tester case above). The point is that the difference is not that great. Any clause whether it is in the GPL or in an EULA is that are not enforced is because of public intrest not because of some other reason. > But > copyright on a > written work is pretty well established. Yes, but I need not distribute your work I distribute MY work and the end user combines them either through compiling or through runtime linking. > > Note that I'm not accusing you of being hypocritical, I just > > point out the we can't both have the cake and eat it. > > What if Microsoft licensed their code as is not allowed to > > run under an emulator or something similar? > > > Tough cookies for them. EULA is really a questionable thing. No, shrink wrap licenses are questionable things, but EULA in themselves are not questionable. True, many paragraphs in normal EULA:s is quite questionable because of law and the constitution but that is something else. > > Of course myth and legend can be a powerful ally. Just look > > at all thing done, good or bad, in the name of Christianity, > > Democracy or whatever, regardless of whether what was done was > > was logically consistant with whatever else was done. > > > Where you are going with this I have no idea, but while your > at it why not > mention the people (using the term broadly here) that are > doing bad stuff > in the name of Islam. I specifically refrained from doing since Christanity or for that matter Democracy is quite enough to serve as an example. What I ment to say is that whether some things are true or not, I this case whether I'm right or not, matters less if some people in this case Open Source movement believe because of their "faith" that thing that are really true are not true. In short: Even if LGPL is actually very weak as I believe it might not matter so much if a lot of people believe it is true. However beware that someday some nasty companies may come anyway and do we you wish not to happend and then we sue them we lose in court. In the meantime we have scared away a couple of other nice companies that believe that the LGPL forbid what they wished to do but it didn't. > > However, my opposition to (L)GPL is not based primarily on that, > > but rather the alleged, and by you, it seems, supported, features > > of it. See below. > > > Right, so your opposition to the LGPL is not based on the > first 60% of > what you said... Why did you bother saying it then. There are two main possibities 1. I'm right 2. I'm wrong. If I'm right (the LGPL is weak) the first 60% was to convince you not to use the LPGL since it is close to meaningless and only add to the confusion. If I'm wrong (the LPGL is strong) the last 40% was to convince you that you don't want a LPGL as license since you might scare away potential nice companies. > > Once companies are being to migrate to Linux/Wine we will hopefully > > get an influx of new developers to fix less important problems. > > > > > > The work of companies that we don't trust is ignored and we work > > > > on as we always have. > > > > > > That's true if that work is kept completely proprietary. > But the thing > > > that the Transgaming stuff should make us realize is that > if that work > > > is released under a free but non open-source license, it > competes with > > > Wine for user and developer mind share, and it hurts Wine > no matter > > > how much we try to ignore it. That is a new situation > that I believe > > > we didn't take into account when picking the current license. > > > > That is true, but I still think we made the right choice. > > If we had made Wine LGPL we might have prevent Transgaming > > from entering the market and a change now might prevent others > > from doing so. > > > Bullshit. The LGPL is actually pretty damn liberal. I think one > advantage here is that it would actually require the > transgaming peices to > be in different object files so they could be relinked, or in > different > source files (possibly under the AFPL) so that they can be > recompiled and > then relinked. Whereby increasing the work Transgaming and other companies have to do and thereby increase to cost for entry to market. In the advantages for us _really _that great? > > I think it is very dangerous for us to reject the help we can get > > to increase the mind share of Wine and derivates as a whole, > > inspite of any inconviences for the core Wine project. > > > > Wine has not yet accieved the breakthrough on the desktop market > > that Linux did on the server market and until then we need all the > > allies we can yet, regardless of their actually "loyalties". > > > > In short: > > We have to take the good with the bad. > > > > Sorry, I totally disagree with this. Wine exists because > developers like > us enjoy hacking on it. Sure and now it happends that nobody enjoys working on DirectX since they, if Transgaming think they are good enough, will get payed to hack on it insteed. What are you going to do about that? Complain that you don't get for free want to haven't payed or worked for? > Is the goal really to try to bring > as many people > away from MS Windows regardless of what platform the move to. > What if > people decide to move away from Windows and to some other proprietary > WinAPI platform. Has this really furthered the Wine project? Yes, because the proprietary WinAPI platform are likely to run on Linux or some other platform Wine supports. Now we continue competing we them instead of Microsoft. > With the > risk of sounding too much like Stallman, I think the real > goal is to get > as many people using free software as the base system. The keyword is base system. Linux is the base system in the example above isn't it? > I > will stop with > that because I don't think at this point forcing the issue of free > software for everything (including applications) is going to work. Exactly and now they run proprietory WinAPI platform under Linux and you can continue to hack on Wine that you love so much knowing that Linux has one more user that can potentially contribute to it. > In any case, going LGPL would not affect TransGaming > horribly. They would > still be free to release proprietary components such as the DirectX > libraries. And by my reading of the LGPL they would even be able to > implement parts of a DLL as long as they are in seperate objects. And the advantages for us would outweight to all problems for others including Transgaming and benifit Wine in the long run? > Furthermore, moving to LGPL is not as bad as moving from the original > license to X11 was. As has been mentioned the only thing > that needs to be > done is to make new contributions LGPL. I will actually extend this > idea. Give developers a choice of whether they want to use > LGPL or X11 > for their contributions. The idea being that to use Wine as > a whole you > must comply with the LGPL, but for any existing code and for any new > contributions under X11 a user or developer could use the code for > anything. The only thing that needs to be done to make this > happen is for > Alexandre to start accepting code licensed under the LGPL > into the Wine > tree. No, please. That will be incredibly messy and evenmore add to the confusion in the market place.

1 0

Re: Installshield 6 (inter-proc) patches
by Dimitrie O. Paun 15 Dec '01

15 Dec '01

On Thu, Dec 13, 2001 at 07:47:42PM -0800, Alexandre Julliard wrote: > [snip] But I see now that there are > ways to make the code kind-of-proprietary that can actually cause more > harm to Wine than purely proprietary ones, and I think we should do > something to address this issue. > > What do others think? Well, a few years ago we discussed this very topic, and at the time I supported a change to LGPL. I still do, because I think it will hellp Wine, for the following reasons: -- we greatly increase our potential code-sharing base. Not only we can copy code from more places (X11-licenced places are still available), but we can now theoretically use any LGPL libs which were before off-limits. -- we greatly increase our developer pool. This is a critical point. The project has been around for a long time, but it has failed to atract a large number of developers. Even today, there are just a few (say in the order of 10) active developers. Of this, I doubt we'll lose any if we switch to LGPL. However, the upside is big. A few years back, Ingo Molnar (or Linux Kernel fame), wrote to the wine-devel list saying that he really wanted to contribute the project but didn't because of the lack of protection of his work from the licence. I'm sure anyone who knows even a little bit of Ingo's work would_love_ to have such a talented guy contribute to Wine. Moreover, we have to understand that the Open Source community has grown quite large lately, but that means that for most people Open Source == (L)GPL. It takes a few levels of refinement to understand _why_ one would like to licence under an X11-style licence. It is, after all, a natural reaction. I know it took me a _long_ time to understand that. There's no point in swiming against the current. -- the two points mentioned earlier will improve the speed of the development, and that can only be good. History shows us that _availability_ is what wins. It would be to everyone's advantage (even companies using Wine's code), to have *working* code, even if under a stricter licence such as LGPL. It would make it much easier to reimplement that feature under a different licence, than no code. -- nowadays Wine is nicely modularized along clear DLL boundaries, which also bounds the 'infectious' nature of the LGPL. Again, think about availabily, If a DLL is 80% X11-licenced, and 20% LGPLed, it would be far easier for anyone to replace the 20% with propriatery/X11-licenced code, than to start from a non-working DLL. -- on the political front, the LGPL provides a lot more _stability_ than a X11-style licence one. And stability, in the long term, helps everybody: comercial companies, because it removes a lot of the risk, Wine in terms for developer peace of mind. In other words, I fully support such a change. The upside looks great, as I've just tried to show. Let's consider the downside: we might lose some developers. I claim this is not gonna be the case, but we can have an informal poll: let's see a show of hands for the people who will stop contributing to Wine if we switch over to LGPL. -- Dimi.

1 0

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

15 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > They might even have an implementation from scratch with no > Wine code at > > all. > > I can see no difference between for example their DLL and a > Microsoft DLL > > running under Wine, regardless of Wine being GPL or LGPL or > whatever. > > There is no difference whatsoever, as long as it is not based on Wine > code. We can't (and shouldn't) prevent anybody from reimplementing a > dll from scratch. My point exactly. > What we can (and should IMO) prevent is people using > our own code against us. Yes, but does the example below ... > > Then we have the middle case by have say the Crypto API that is > > a part of ADVAPI32. Does distributing a whole file replacement of > > dlls/advapi32/crypt.c represent a violation of GPL or LGPL? > > In that case why? The Crypto API is largely independent of the > > rest of ADVAPI32 it could as well be a separate DLL. ... really violate the LGPL IYO (In Your Opinion)? I really can't see why it is significant that Microsoft put the Crypto API in ADVAPI32.DLL instead of say a seperate DLL, say CRYPTO32.DLL. > > Any protection that (L)GPL provides is to a large part based on > > myth and legend. > > I think you are very mistaken here. The protection is based strictly > on copyright law, and if anything is certain it is that copyright law > is going to become even stronger in the coming years. There are certainly a lot of people that _wish_ to make copyright law stronger. However even more important is a copyright law that make logical sense. I think doctrine of derived work is one of the most serious mistakes in how copyright law today is formulated. The basic idea is a good one and I support it, but I really think it should have been formulated in term of combined works instead of derived works. That is, if you combine your work with somebody elses work and distribute it together you must have the permission all the authors of all parts the combined work consists of. But that is exactly what the doctrine of derived work says, you object, what is the difference? Well, the difference is subtle. Under a strict doctrine of combined work ONLY distribution of the combined work is prohibited not providing a work that can be combined with another work to form a combined work regardless of whether this was intended or not. Under such a doctrine, the (L)GPL doesn't make any sense (and thus have no power) if all if you only provide patches. Note that you only have to accept the (L)GPL if you distribute the (L)GPL:ed work and you don't. The fact that end user can combine your work and the (L)GPL:ed work, perhaps using a script you wrote, perhaps not, doesn't matter att all under a strict combined work doctrine since no distribution is taking place. The big question for the future is the doctrine of derived work really a strict doctrine of combined work? Note that 1. This is the only thing it AFAIK has been used for in actual court cases 2. This might be the only possible constitutional interpretation of copyright law, because otherwise somebody (A) can prevent somebody else (B) from "speaking" based on what some third party (C) can used the "speech" lawfully acquired from B together with some "speech" lawfully acquired from A. Especially since what C might do is most likely not even be illegal. > In addition our situation is even easier since the dll interfaces are > already defined for us; the difficulties you see are purely imaginary, > I don't think there would be any technical problem applying the LGPL > to Wine. Technical problems perhaps not, but does it help? Especially given how much it might hurt. > The GPL is another story, but we clearly don't want to go there if > Wine is to remain useful for running proprietary applications. Agreed. > > In addition hypocritical people at for example Slashdot also > > seems to wish to apply different standard at open source licenses > > and proprietary licenses. > > > > So company cries that their products shouldn't be hacked (having a > > part replace) should be ignored despite their insistance that a > > paragraf of their license has been violated, while any violations > > of the (L)GPL doing essentialy the same thing (replacing a part) > > should be strictly enforced. :-) > > If you don't understand the fundamental difference between the GPL and > a standard EULA, I'd suggest studying the issue a bit more. And > www.gnu.org is probably a better reference than Slashdot to learn > about this kind of things <g> Oh, I read both these sites and more. Sure there is a difference, as the current law is written, but the big question does it make sense that there is a difference? The fundamental issue is the same. 1. I am the author of some work 2. You would like to use my work in some way. 2. I'm prepared to make the work available to you under some conditions As a side note, because of copyright as some sort of public contract not all possible conditions are enforcabled. For example first sale doctrine says I can't control what happends to a specific copy of a work once I have sold it. But that doesn't change the fact the situations are basicly the same and I was not talking about law here rather about morality. I said hypocritical didn't I? > > True, but that doesn't worry me so much, since very few non games > > depend of DirectX and this allows us concentrate on what is really > > important getting commonly used productivity applications to run > > under Wine. > > In short, because you don't care about games Wine doesn't have to > support them. I strongly disagree with this sentiment; even though I > don't care much about games myself, I want Wine to be able to run them > just like other applications. And again, DirectX is just one example > of something that could happen with any other part of Wine. What I mean is that, we can't have everything. We don't have the resources to do everything. We have to make priorities and people playing games are people that are unlikely to provide a lots of new developers or other resources for the core Wine project as it is organized. Companies on the other hand wanting to run their productivity application are much more likely to provide resources developing Wine further especially after we reach the point there their normal applications run close to perfectly and they wish to make their more unusual application to run as well to be able to provide a say all Linux desktop. Therefore I'm happy to leave things like DirectX to companies like Transgaming for the time being since people that wants to play games are more likely to be happy with the way they can support Transgaming ie paying a monthly fee. > > That is true, but I still think we made the right choice. > > If we had made Wine LGPL we might have prevent Transgaming > > from entering the market and a change now might prevent others > > from doing so. > > I don't think so; they would certainly have had to make some > adjustments to the business model, but I think it is definitely > possible to build a business on an LGPL code base. Of course these > days building any kind of business is quite difficult, but I don't > think LGPL vs. X11 is going to be the difference that makes otherwise > successful businesses fail. Using your strict interpretion of the LPGL it will significantly increase the cost of entry to the market, thus requiring higher risk of entering the market, even with a basicly sound business model. > > I think it is very dangerous for us to reject the help we can get > > to increase the mind share of Wine and derivates as a whole, > > inspite of any inconviences for the core Wine project. > > > > Wine has not yet accieved the breakthrough on the desktop market > > that Linux did on the server market and until then we need all the > > allies we can yet, regardless of their actually "loyalties". > > Well, I strongly disagree. Wine is supposed to be a free > implementation of Windows; if making it successful requires making it > non-free, we might as well stop right now. "He who defend everything, defends nothing" Need I say more? > Anyway we are not going to convince each other. I take note that you > are opposed to the change, even if I admit I'm a bit surprised; it > seems last time we discussed licenses you were quite favorable to the > LGPL. Well, with age comes wisdom (or senility). :-) Seriously, we made that choice we made in hope that it would be a good one and I think it is to early to say that the choice was a bad one. Changing licenses out of panic is a bad idea. Let calm down and think this through properly.

4 3

Re: [RFC] Async I/O patch: server code + ReadFileEx()
by lawson_whitney＠juno.com 15 Dec '01

15 Dec '01

On Sat, 15 Dec 2001, Mike McCormack wrote: > > Hi Lawson, > > another user head space error... i forgot to include async.h :-/ > > Here's the patch including async.h. > > Mike > > > >I did tools/make_requests, but where is async.h spoze to come from? > .. > make[1]: Entering directory `/oof/Wine-20011108/miscemu' make[1]: `miscemu.o' is up to date. make[1]: Leaving directory `/oof/Wine-20011108/miscemu' gcc -o wine miscemu/miscemu.o -L./dlls -lntdll -L./library -lwine -L./unicode -l wine_unicode -lncurses -lm -lutil -ldl ./dlls/libntdll.so: undefined reference to `FILE_GetTimeout' collect2: ld returned 1 exit status make: *** [wine] Error 1 [whit@giftie wine]$ This might be something stupid I have done, OTOH she had warts, and it might not be. I'll sort it out later. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

1 0

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

15 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Umm. I feared that question would come. The "protection" > the LGPL (or GPL) > > that Marcus proposed is IMHO largely an illusion when it > comes to libraries. > > > > Sure we might use a strict interpretion as a weapon in a PR campaign > > against possible voilators but we don't have the resources to sue > > somebody and I very much doubt we would succed either. > > I think you greatly underestimate the power of such licenses. That is what remains to be seem. Many laws doesn't make logical sense anymore or becomes inconsistant in the new brave world and the attempts to adapt them often introduces new problems. The attempts of various courts the interpret the uninterpretable inconsistancies, without realizing it, futuremore adds to the confusion. Expect extreme uncertainty to be the keyword for the immediate future. > AFAIK > nobody in the world is currently shipping code (except maybe by > mistake) in violation of the GPL or LGPL, despite the fact that it has > never been taken to court. True, it does have some power because few wants to be named a bad boy, but that might mean less and less in the future. > And nobody in their right mind would base a > business on shipping illegal code; even if they believed they could > get a judge to agree with them, the risk is simply too great. Small changes in a particular DLL then there is no clear boundaries between their boundaries between their code and ours might be risky, true. However, in your example five companies offered one proprietary version each of five different half important DLLs. They might even have an implementation from scratch with no Wine code at all. I can see no difference between for example their DLL and a Microsoft DLL running under Wine, regardless of Wine being GPL or LGPL or whatever. Then we have the middle case by have say the Crypto API that is a part of ADVAPI32. Does distributing a whole file replacement of dlls/advapi32/crypt.c represent a violation of GPL or LGPL? In that case why? The Crypto API is largely independent of the rest of ADVAPI32 it could as well be a separate DLL. Any protection that (L)GPL provides is to a large part based on myth and legend. In addition hypocritical people at for example Slashdot also seems to wish to apply different standard at open source licenses and proprietary licenses. So company cries that their products shouldn't be hacked (having a part replace) should be ignored despite their insistance that a paragraf of their license has been violated, while any violations of the (L)GPL doing essentialy the same thing (replacing a part) should be strictly enforced. :-) Note that I'm not accusing you of being hypocritical, I just point out the we can't both have the cake and eat it. What if Microsoft licensed their code as is not allowed to run under an emulator or something similar? Of course myth and legend can be a powerful ally. Just look at all thing done, good or bad, in the name of Christianity, Democracy or whatever, regardless of whether what was done was was logically consistant with whatever else was done. However, my opposition to (L)GPL is not based primarily on that, but rather the alleged, and by you, it seems, supported, features of it. See below. > > > My concern is not so much about Transgaming, I trust that > Gav means to > > > do the right thing, > > > > Agreed and I think we should allow them considerable time > to consider > > their position as well no need to rush something. > > I'm not trying to rush anything, just opening a discussion. And as I > said this is not against Transgaming, any license change would not > modify the current situation at all anyway, since it obviously only > applies to future developments. Agreed. > > > even if I don't entirely agree with his methods. > > > > Well, money makes the world go round whether you like it or not. :-) > > I like it, in fact as you may know I make money with Wine too... I'd > be more than happy to see Gav or others make millions out of Wine, but > I don't want to let people hurt the project, even if doing that makes > them more money. Agreed. > > Now that Transgaming has done the hard work of getting > InstallShield to > > work and even been kind enough provide the source code > eventhough under > > a propritary license it can't be that difficult to look at it and > > provide an alternative implementation. > > The issue is absolutely not limited to this InstallShield stuff. In > fact my worry is much more about what we see happening in DirectX, > where all development on the free version has stopped. True, but that doesn't worry me so much, since very few non games depend of DirectX and this allows us concentrate on what is really important getting commonly used productivity applications to run under Wine. Once companies are being to migrate to Linux/Wine we will hopefully get an influx of new developers to fix less important problems. > > The work of companies that we don't trust is ignored and we work > > on as we always have. > > That's true if that work is kept completely proprietary. But the thing > that the Transgaming stuff should make us realize is that if that work > is released under a free but non open-source license, it competes with > Wine for user and developer mind share, and it hurts Wine no matter > how much we try to ignore it. That is a new situation that I believe > we didn't take into account when picking the current license. That is true, but I still think we made the right choice. If we had made Wine LGPL we might have prevent Transgaming from entering the market and a change now might prevent others from doing so. I think it is very dangerous for us to reject the help we can get to increase the mind share of Wine and derivates as a whole, inspite of any inconviences for the core Wine project. Wine has not yet accieved the breakthrough on the desktop market that Linux did on the server market and until then we need all the allies we can yet, regardless of their actually "loyalties". In short: We have to take the good with the bad.

5 4

Re: [RFC] Async I/O patch: server code + ReadFileEx()
by lawson_whitney＠juno.com 14 Dec '01

14 Dec '01

On Fri, 14 Dec 2001, Mike McCormack wrote: > Hi Martin, > > This is a working patch that: > > * orders async operations > * moves all async timeouts and activation back to the server > * works for serial I/O > * should be extensible to other objects > > Tell me what you think. > > Mike > > > ChangeLog: > * move async activation into the server > * implement async queues > I did tools/make_requests, but where is async.h spoze to come from? make[1]: Entering directory `/oof/Wine-20011108/server' ../tools/makedep -I. -I. -I../include -I../include -C. async.c atom.c change.c console.c context_i386.c context_sparc.c debugger.c device.c event.c file.c hand le.c main.c mapping.c mutex.c named_pipe.c object.c pipe.c process.c ptrace.c qu eue.c registry.c request.c select.c semaphore.c serial.c snapshot.c sock.c threa d.c timer.c trace.c unicode.c user.c window.c -C. async.h: No such file or directory async.h was first included from async.c:21 make[1]: *** [depend] Error 1 make[1]: Leaving directory `/oof/Wine-20011108/server' make: *** [server/__depend__] Error 2 [whit@giftie wine]$ Probable user head space error. - Dennis A. Moore

1 0

Winelib source for IPropertySetStorage implementation
by Sanand Patel 14 Dec '01

14 Dec '01

Hello, We have managed to compile and link winelib for a SPARC CPU, and Winelib runs in a fashion (can compile/link simple C++ application and execute a couple of WIN32 APIs). But I can't seem to find the implementation for IPropertySetStorage/IPropertyStorage. I see the defines in the header files (include/wine/obj_storage..) but I have scoured the winelib source tree for the implementation with no luck. Is this interface implmented? Thanks.

2 1

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

13 Dec '01

> It's been quite fascinating watching this discussion; it's > nice to see that > such issues are covered. It raises two issues for me: > 1. Where does Lindows fit into all this? Does anyone know > what's happening > there? No idea. > 2. Is the current wine license as loose as it appears to me? Probably. > My > understanding is that "the license" is the file "LICENSE" at > the root of the > cvs tree and basically allows anyone to do anything with it > provided they > keep the license in there (and respect copyright). Yes. > I keep > seeing quotes and > things that suggest wine is under GPL, LGPL, BSD etc.; I > presume that they > are simple ill-informed. It is under the modified BSD license, ie the BSD license without the advertisment clause, more often called the X11 license.

1 0

Re: Patch to memory/virtual.c
by Uwe Bonnes 13 Dec '01

13 Dec '01

>>>>> "Robert" == Robert Baruch <autophile(a)starband.net> writes: Robert> Description: map_image now sets up the protections in the view Robert> of the memory-mapped executable image according to the Robert> protections for each section in the image. Before the patch, Robert> running an app under WinDbg on W2K/VMware showed a protection Robert> violation at a certain address, which Wine did not fault at that Robert> address. After the patch, the app faults in the same place in Robert> Wine as it does in W2K. I think the protection setting needs more care. With some shrinker file (targ2001.exe) I get ... trace:module:map_image mapping section .idata at 0x75b69000 off 34000 size c00 flags 40000040 ... trace:virtual:map_image Set protection for section .idata 40000040 to 41. trace:virtual:VIRTUAL_SetProt 0x75b69000-0x75b69fff c-r-- ... Unhandled exception: page fault on write access to 0x75b6903c in 32-bit code (0x40091c2f). In 32-bit mode. 0x40091c2f (PE_fixup_imports+0x2af [pe_image.c:330] in libntdll.so): movl %eax,0x0(%ecx) 333 if (!thunk_list->u1.Function) { Wine-dbg>Backtrace: =>0 0x40091c2f (PE_fixup_imports+0x2af(wm=0x40382b48) [pe_image.c:330] in libntdll.so) (ebp=405b5dc8) Giving VPROT_WRITE to .idata breaks when native oleaut32 is loaded: trace:module:MODULE_LoadLibraryExA Trying native dll 'D:\wine95\system\OLEAUT32.DLL' trace:module:PE_LoadImage loading D:\wine95\system\OLEAUT32.DLL trace:virtual:CreateFileMappingW (18,(nil),01000000,0000000000000000,(null)) trace:module:map_image mapped PE file at 0x65340000-0x653d2000 trace:module:map_image mapping section .text at 0x65341000 off 2000 size 82000 flags 60000020 ... trace:virtual:map_image Set protection for section .text 60000020 to 45. trace:virtual:VIRTUAL_SetProt 0x65341000-0x653c2fff c-r-x ... Unhandled exception: page fault on write access to 0x65341000 in 32-bit code (0x40091c2f). In 32-bit mode. 0x40091c2f (KERNEL32.DLL.__wine_call_from_16_thunk+0x61cf): movl %eax,0x0(%ecx) Wine-dbg>Backtrace: =>0 0x40091c2f (KERNEL32.DLL.__wine_call_from_16_thunk+0x61cf) (ebp=405b6cbc) 1 0x400924e2 (KERNEL32.DLL.__wine_call_from_16_thunk+0x6a82) (ebp=405b6d48) 2 0x40092632 (KERNEL32.DLL.__wine_call_from_16_thunk+0x6bd2) (ebp=405b6d70) ... Running with builtin oleaut32 and friends, I again get to the shrinker error box. Thanks for your efforts so long! Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

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

13 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > In short: > > Should the Wine project wait until you release or should it not? > > That's certainly a question we have to think about, but I think there > is a deeper issue: should we continue to release under a license that > allows people to use our own code to hurt the project? Umm. I feared that question would come. The "protection" the LGPL (or GPL) that Marcus proposed is IMHO largely an illusion when it comes to libraries. Sure we might use a strict interpretion as a weapon in a PR campaign against possible voilators but we don't have the resources to sue somebody and I very much doubt we would succed either. If I was I judge I wouldn't want to touch the issue of what constituted "linking" with a ten foot pole. Beside since where was no real damages since Wine was already free I would probably look for an excuse to dismiss the case as early as possible. No, a license change is not the answer to our problems. > My concern is not so much about Transgaming, I trust that Gav means to > do the right thing, Agreed and I think we should allow them considerable time to consider their position as well no need to rush something. > even if I don't entirely agree with his methods. Well, money makes the world go round whether you like it or not. :-) > But I'm worried that if Transgaming succeeds, it will set a precedent > that others will follow, who may have no desire at all to do the right > thing for Wine. Succeed with what? Now that Transgaming has done the hard work of getting InstallShield to work and even been kind enough provide the source code eventhough under a propritary license it can't be that difficult to look at it and provide an alternative implementation. Note that Gav said: < 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. We could quite easily make InstallShield work ourselves now that they have don't all the tedious debugging and we know what needs to be done. Note copyright only protects expression not fact or ideas (or hard work for that matter). In light of this it might be advantagous for Transgaming to release their InstallShield code. But as I said lets no rush things. I'm prepared to give them the benifit of the doubt and wait for them to decide. However my (and presumable others) patience in not boundless. > What will happen if 5 different dlls are improved and > released by 5 different companies under 5 different non-free licenses? When we had to decide which of the companies we trusted to release their code in the not so far away future and which we don't trust. The work of companies that we don't trust is ignored and we work on as we always have.

2 1

Improved redraw performance when application loaded
by Dave Hawkes 13 Dec '01

13 Dec '01

changelog: Reduced the time for a window with many child windows to be displayed. More info: A large application was taking up to 10 seconds to display its main window. This appears to be due to X individually exposing every child window (of which there are very many) of the main application window and then wine forcing a redraw on the parent of every child and then all the subchildren again (!) resulting in the accumulation of a huge redraw list. This patch will force a redraw only on the child and not the parent as X will eventually expose that anyway. After applying this patch the initial redraw dropped from around 10 seconds to about 2 seconds and I could not find any painting problems If anyone else is having slow application loading problems of this nature, then please try this patch. Dave Hawkes

1 0

Re: Uncleared WM_PAINT loop problem
by Gerard Patel 13 Dec '01

13 Dec '01

At 02:13 PM 12/12/2001 -0500, you wrote: >I have a problem where an edit control get stuck in an infinite WM_PAINT >loop. > >BeginPaint never clears the paint count because of this code: > > if(((hrgnUpdate = wndPtr->hrgnUpdate) != 0) || (wndPtr->flags & >WIN_INTERNAL_PAINT)) > add_paint_count( hwnd, -1 ); > > >if wndPtr->hrgnUpdate is 0 then the paint count is never decremented here >and nowhere else attempts to decrement it and we land up in an infinite >paint loop. I'm not sure how we get to this point the a NULL update region >(which may be a bug anyway), but there should still be a method of breaking >out of this loop once we are there. > >I tried removing the test and always calling add_paint_count and this >appears to fix the problem. > With current Cvs code the infinite loop should have gone away... Alexandre Julliard has changed a strangeness of BeginPaint : when the update region is null, Wine used to paint the whole window. New code set an empty painting rectangle. However, if the empty update region comes from an earlier Wine bug, the new code replaces excessive repainting with no repainting at all. I have already an app that shows this problem. As I was saying in reply to Andi Mohr, better code can reveal better old bugs... Gerard

2 1

Improved redraw performance when application loaded
by Dave Hawkes 13 Dec '01

13 Dec '01

changelog: Reduced the time for a window with many child windows to be displayed. More info: A large application was taking up to 10 seconds to display its main window. This appears to be due to X individually exposing every child window (of which there are very many) of the main application window and then wine forcing a redraw on the parent of every child and then all the subchildren again (!) resulting in the accumulation of a huge redraw list. This patch will force a redraw only on the child and not the parent as X will eventually expose that anyway. After applying this patch the initial redraw dropped from around 10 seconds to about 2 seconds and I could not find any painting problems If anyone else is having slow application loading problems of this nature, then please try this patch. Dave Hawkes

1 0

Great ! [Re: wine/ dlls/user/Makefile.in dlls/user/wnd16.c ...]
by Andreas Mohr 13 Dec '01

13 Dec '01

On Wed, Dec 12, 2001 at 08:03:31PM -0500, Alexandre Julliard wrote: > Started rewrite of painting functions for multiple processes. Moved > BeginPaint to dlls/user. Fixed bug in paint count handling. Oh yeah. *Much* better now :-) OrCAD PSpice can actually be looked at now without vom****** :-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

Re: Installshield 6 (inter-proc) patches
by Igor Furlan 13 Dec '01

13 Dec '01

On Thu, 13 December 2001, Alexandre Julliard wrote: it will set a precedent > that others will follow, who may have no desire at all to do the right > thing for Wine. What will happen if 5 different dlls are improved and > released by 5 different companies under 5 different non-free licenses? > Wasn't (L)GPL designed to ___prevent___ this kind of things to happen ? just my 0.02euro Igor

1 0

Re: Great ! [Re: wine/ dlls/user/Makefile.in dlls/user/wnd16.c ...]
by Gerard Patel 13 Dec '01

13 Dec '01

At 02:08 PM 13/12/2001 +0100, you wrote: >On Wed, Dec 12, 2001 at 08:03:31PM -0500, Alexandre Julliard wrote: >> Started rewrite of painting functions for multiple processes. Moved >> BeginPaint to dlls/user. Fixed bug in paint count handling. >Oh yeah. >*Much* better now :-) > >OrCAD PSpice can actually be looked at now without vom****** :-) Well, at least one of my test apps is now completely broken, certainly a following of this patch (repainting problems). This does not mean that the patch is wrong of course - maybe 2 bugs were compensating each other before. Gerard

1 0

Re: OSS fixes
by Duane Clark 12 Dec '01

12 Dec '01

Eric wrote: > could the people who had issues with the latest OSS patch(es) test > if this one fixes all their issues ? This patch causes both Riven and Myst to immediately freeze for me, and no sound at all. Without the patch, the sound in Myst works pretty good (occasional brief dropouts). In Riven without the patch, only the opening sequence has sound, and that has many large dropouts. I'm using ALSA drivers in Redhat. Duane

6 7

Uncleared WM_PAINT loop problem
by Dave Hawkes 12 Dec '01

12 Dec '01

Hi, I have a problem where an edit control get stuck in an infinite WM_PAINT loop. BeginPaint never clears the paint count because of this code: if(((hrgnUpdate = wndPtr->hrgnUpdate) != 0) || (wndPtr->flags & WIN_INTERNAL_PAINT)) add_paint_count( hwnd, -1 ); if wndPtr->hrgnUpdate is 0 then the paint count is never decremented here and nowhere else attempts to decrement it and we land up in an infinite paint loop. I'm not sure how we get to this point the a NULL update region (which may be a bug anyway), but there should still be a method of breaking out of this loop once we are there. I tried removing the test and always calling add_paint_count and this appears to fix the problem. Before I submit this change, does anyone know the original reason for this test in the first place? Thanks Dave Hawkes

1 0

Re: [PATCH] BeginPaint
by eric pouech 12 Dec '01

12 Dec '01

Gerard Patel wrote: > > ChangeLog: > > * windows/painting.c > Fix stupid use of unlocked window pointer wouldn't it be a good idea to zero out the wndPtr after releasing so that we could catch such errors ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Wine doesn't work
by Dmitry Petuhov 12 Dec '01

12 Dec '01

Hello!!! I have subj in Wine 20011004 Linux Kernel 2.4.2, Xwindow 4.0.3 It sayes: X Error of failed request: XF86DGANoDirectVideoMode Major opcode of failed request: 138 (XFree86-DGA) Minor opcode of failed request: 22 (XDGAOpenFramebuffer) Serial number of failed request:181 Current serial number in output stream: 181 Why it is and how I may run it???

1 0

can not run IE and it's derived app
by wenhong xing 12 Dec '01

12 Dec '01

dear sir/madam: i use wine with redhat linux 7.2 and enjoyed it very much. however, i encountered a problem that may need your help: i have project built with VC++ 6.0. it included CHtmlView/microsoft web browser control. it turned out that they could not be created when the program started. but i link MFC staticlly; at least the CHtmlView shouldn't cause trouble. please give me some advice. thanks wenhong __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com

1 0

problems with counter-strike under wine
by Matthew Winner 11 Dec '01

11 Dec '01

info: newest versions of counter-strike and half-life for windows. wine version 200111008 GLX and NVdriver installed and working for nvidia card running hl.exe from .../half-life on c:\ of windows partition with wine --winver win98 hl.exe -- hl.exe --console using c:\\windows, c:\\windows\\system, c:\\windows\\temp, etc in .wine/config file halflife loads and runs flawlessly, but these errors occur when I try and start a game of counterstrike: fixme:winsock:_get_sock_fd handle 0 is not a socket (GLE 6) Warning: /halflife.wad not accessible from a configured DOS drive I also get one that looks like this: fixme:system:SystemParametersInfoA Unimplemented action: 3 (SPI_GETMOUSE) It will terminate on all three of these, apparently at random, but the most common is the one about halflife.wad. here's my config entry on the DOS drive in question: [Drive C] "Path" = "/mnt/win" "Type" = "hd" "Label" = "MS-DOS" "Filesystem" = "win95" "Device" = "/dev/hda1" It's a fat32 partition running windows 98 se and windows 2000. windows 98 is emulated in the conifg file. The last line "Device" I added, hoping this would help somehow. The mount point and /dev/hda1 are correct. I've tried running with --winver win98, this doesn't seem to help. any ideas? I noticed a few others on this post have had similar problems. It's pretty clear that Counter-Strike can and does work under WINE. Is this an ldconfig matter? what should I do? matt -- mwinner(a)altavista.com Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com

1 0

Wine, Office, and the antitrust settlement
by Dan Kegel 11 Dec '01

11 Dec '01

I'm proposing that Wine be part of the settlement of the Microsoft antitrust trial. See http://www.kegel.com/remedy.html Comments welcome. I have a few questions for Wine developers, especially the good folks at Codeweavers and Transgaming: 1. How much would it cost to achieve full support for Office 2000 in Wine? 2. Is it true that Office uses undocumented Windows APIs? If so, how many? Are they a significant part of the challenge of supporting Office? Thanks, Dan Kegel dank(a)kegel.com

3 5

extracting shares from mtab
by Robert Lunnon 11 Dec '01

11 Dec '01

Mon, 10 Dec 2001 00:06, you wrote: > Message: 6 > Date: Sat, 08 Dec 2001 18:38:57 -0500 > From: Gavriel State <gav(a)transgaming.com> > Organization: TransGaming Technologies Inc. > To: Alexandre Julliard <julliard(a)winehq.com> > CC: Dan Kegel <dank(a)kegel.com>, Eric Pouech <eric.pouech(a)voila.fr>, > Stefan.Leichter(a)camLine.com, wine-devel(a)winehq.com > Subject: Re: UNC patch & parsing fstab/mtab > > Alexandre Julliard wrote: > > > > Dan Kegel <dank(a)kegel.com> writes: > > > > > Just how terrible is parsing /etc/mtab? It doesn't look like > > > much code. I'd be happy to provide a nice OO wrapper object > > > for it if that would make you happier. It would then no > > > longer be an ugly hack. Would that satisfy you? Or are > > > you fundamentally opposed to it for some other reason than > > > code clarity? > > > > Code clarity is one thing (it should be probably using getmntent and > > friends), performance is another (parsing /etc/mtab on each CreateFile > > is *not* a good idea), but mainly I'm opposed to the concept of > > configuring everything by hand except magically getting smb shares > > through /etc/mtab, when they may not at all reflect what you want the > > Windows application to see. It doesn't fit in the current > > configuration philosophy. Now of course the config philosophy can be > > changed, but it must remain coherent. > > I don't doubt that we don't want to be parsing /etc/mtab on each > CreateFile, but I will put in a word for some modifications to the > configuration philosophy when it comes to drive letters. > > One of the problems we've come across recently is this: for games that > use copy protection, we need to have direct access to the device that > a CD-ROM drive uses. For the moment, this relys on the user to manually > configure their drive letters. From what we've seen, doing so is > beyond the ken of many of our users. > > As such, we've put together a scheme for parsing /etc/fstab on startup > (not mtab: the drive may not be mounted), and automatically adding > drive letters for each iso9660 filesystem listed. The patch (to the > WineX tree) is here: > > http://www.geocrawler.com/archives/3/9376/2001/11/0/7204310/ > > We're happy to contribute this in our next outward merge if people > think it's useful. > > -Gav Oh no not again Except for us poor people that dont use linux ! On Solaris fstab is vfstab, and mtab is mnttab, parsing these files is no good unless it is done in some portable way. (Not that smbfs even works on Solaris) I would think that persistent share selection should be saved in the registry and accessed through smbclient rather than smbfs, then smb shares would work for all OSs supporting Samba, not just those supporting smbfs. IMHO There are already too many linux centrix assumptions in wine, please, lets not add any more . Bob

3 2

Getting Started
by Oliver Sampson 11 Dec '01

11 Dec '01

Howdy, I'm trying to get started with Wine development, and I figured the best way would be to CVS the code and install it. I CVSed the code, configured, did a 'make depend', 'make', and a 'make install'. When I try to run wine, I get a message that libntdll.so wasn't found. So I found it in /usr/lib/libntdll.so. is there something in the initial setup config that didn't work correctly? FWIW, I can rpm the wine-cvs-unstripped rpm just fine, and it works well. (The install process and the program.) Any ideas how to get this working from my cvs directory? Thanks, ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

5 15

Re: OSS fixes
by Gerard Patel 10 Dec '01

10 Dec '01

At 09:23 PM 10/12/2001 +0100, you wrote: >could the people who had issues with the latest OSS patch(es) test >if this one fixes all their issues ? I have only one serious issue, and it's fixed by your patch. While you are at it, I noticed a few spelling errors : 'can be do better' at line 672 'unable read mixer' at line 1250 'unable set mixer' at line 1282 'we have the 0 the block by hand' at line 1394 'we can have at least a 4 longs to store.' at line 1401, Gerard

1 0

RE: Dialog autoradio buttons are initially not tabstops
by Medland, Bill 10 Dec '01

10 Dec '01

No. It IS down in the button.c; I'll do it in a second. > -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland@accpac.com] > Sent: Monday, December 10, 2001 1:57 PM > To: Wine patches (E-mail) > Subject: Dialog autoradio buttons are initially not tabstops > > > <<diff33.txt>> >

1 0

OSS fixes
by eric pouech 10 Dec '01

10 Dec '01

could the people who had issues with the latest OSS patch(es) test if this one fixes all their issues ? TIA A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Index: dlls/winmm/wineoss/audio.c =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/dlls/winmm/wineoss/audio.c,v retrieving revision 1.47 diff -u -r1.47 audio.c --- dlls/winmm/wineoss/audio.c 2001/11/19 02:10:50 1.47 +++ dlls/winmm/wineoss/audio.c 2001/12/10 20:15:30 @@ -82,6 +82,7 @@ #define WINE_WM_RESETTING (WM_USER + 3) #define WINE_WM_CLOSING (WM_USER + 4) #define WINE_WM_HEADER (WM_USER + 5) +#define WINE_WM_UPDATE (WM_USER + 6) typedef struct { int msg; /* message identifier */ @@ -89,9 +90,9 @@ HANDLE hEvent; /* if message is synchronous, handle of event for synchro */ } OSS_MSG; -/* implement a in process message ring for better performance +/* implement an in-process message ring for better performance * (compared to passing thru the server) - * this ring will be used by both the input & output plauback + * this ring will be used by the input (resp output) record (resp playback) routine */ typedef struct { #define OSS_RING_BUFFER_SIZE 30 @@ -105,39 +106,32 @@ typedef struct { int unixdev; volatile int state; /* one of the WINE_WS_ manifest constants */ + WAVEOPENDESC waveDesc; + WORD wFlags; + PCMWAVEFORMAT format; + WAVEOUTCAPSA caps; + + /* OSS information */ DWORD dwFragmentSize; /* size of OSS buffer fragment */ - DWORD dwBufferSize; /* size of whole OSS buffer in bytes - * used to compute dwPlayedTotal from dwWrittenTotal and - * ioctl GETOSPACE info - */ + DWORD dwBufferSize; /* size of whole OSS buffer in bytes */ WORD uWaitForFragments; /* The number of OSS buffer fragments we would like to be free * before trying to write to the DSP */ - DWORD dwMillisPerFragment; /* The number of milliseconds of sound in each OSS buffer - * fragment - */ - WAVEOPENDESC waveDesc; - WORD wFlags; - PCMWAVEFORMAT format; LPWAVEHDR lpQueuePtr; /* start of queued WAVEHDRs (waiting to be notified) */ LPWAVEHDR lpPlayPtr; /* start of not yet fully played buffers */ + DWORD dwPartialOffset; /* Offset of not yet written bytes in lpPlayPtr */ - /* info on current lpPlayPtr->lpWaveHdr */ - LPSTR lpPartialData; /* Data still to write on current wavehdr */ - DWORD dwPartialBytes; /* number of bytes to write to end current wavehdr */ - LPWAVEHDR lpLoopPtr; /* pointer of first buffer in loop, if any */ DWORD dwLoops; /* private copy of loop counter */ - DWORD dwPlayedTotal; /* number of bytes played since opening */ - DWORD dwWrittenTotal; /* number of bytes written since opening */ + DWORD dwPlayedTotal; /* number of bytes actually played since opening */ + DWORD dwWrittenTotal; /* number of bytes written to OSS buffer since opening */ /* synchronization stuff */ HANDLE hStartUpEvent; HANDLE hThread; DWORD dwThreadID; OSS_MSG_RING msgRing; - WAVEOUTCAPSA caps; /* DirectSound stuff */ LPBYTE mapping; @@ -174,7 +168,8 @@ "WINE_WM_RESTARTING", "WINE_WM_RESETTING", "WINE_WM_CLOSING", - "WINE_WM_HEADER" }; + "WINE_WM_HEADER", + "WINE_WM_UPDATE" }; /*======================================================================* * Low level WAVE implementation * @@ -378,56 +373,6 @@ return 0; } -/************************************************************************** - * OSS_NotifyClient [internal] - */ -static DWORD OSS_NotifyClient(UINT wDevID, WORD wMsg, DWORD dwParam1, DWORD dwParam2) -{ - TRACE("wDevID = %04X wMsg = 0x%04x dwParm1 = %04lX dwParam2 = %04lX\n",wDevID, wMsg, dwParam1, dwParam2); - - switch (wMsg) { - case WOM_OPEN: - case WOM_CLOSE: - case WOM_DONE: - if (wDevID >= MAX_WAVEOUTDRV) return MCIERR_INTERNAL; - - if (WOutDev[wDevID].wFlags != DCB_NULL && - !DriverCallback(WOutDev[wDevID].waveDesc.dwCallback, - WOutDev[wDevID].wFlags, - WOutDev[wDevID].waveDesc.hWave, - wMsg, - WOutDev[wDevID].waveDesc.dwInstance, - dwParam1, - dwParam2)) { - WARN("can't notify client !\n"); - return MMSYSERR_NOERROR; - } - break; - - case WIM_OPEN: - case WIM_CLOSE: - case WIM_DATA: - if (wDevID >= MAX_WAVEINDRV) return MCIERR_INTERNAL; - - if (WInDev[wDevID].wFlags != DCB_NULL && - !DriverCallback(WInDev[wDevID].waveDesc.dwCallback, - WInDev[wDevID].wFlags, - WInDev[wDevID].waveDesc.hWave, - wMsg, - WInDev[wDevID].waveDesc.dwInstance, - dwParam1, - dwParam2)) { - WARN("can't notify client !\n"); - return MMSYSERR_NOERROR; - } - break; - default: - FIXME("Unknown CB message %u\n", wMsg); - break; - } - return 0; -} - static int OSS_InitRingMessage(OSS_MSG_RING* omr) { omr->msg_toget = 0; @@ -497,24 +442,38 @@ *======================================================================*/ /************************************************************************** - * updatePlayedTotal [internal] - * - * Calculates wwo->dwPlayed total from wwo->dwWrittenTotal and the amount - * still remaining in the OSS buffer. + * wodNotifyClient [internal] */ -static DWORD updatePlayedTotal( WINE_WAVEOUT* wwo ) +static DWORD wodNotifyClient(WINE_WAVEOUT* wwo, WORD wMsg, DWORD dwParam1, DWORD dwParam2) { - audio_buf_info info; - - if (ioctl(wwo->unixdev, SNDCTL_DSP_GETOSPACE, &info) < 0) { - ERR("ioctl failed (%s)\n", strerror(errno)); - return wwo->dwPlayedTotal; + TRACE("wMsg = 0x%04x dwParm1 = %04lX dwParam2 = %04lX\n", wMsg, dwParam1, dwParam2); + + switch (wMsg) { + case WOM_OPEN: + case WOM_CLOSE: + case WOM_DONE: + if (wwo->wFlags != DCB_NULL && + !DriverCallback(wwo->waveDesc.dwCallback, wwo->wFlags, wwo->waveDesc.hWave, + wMsg, wwo->waveDesc.dwInstance, dwParam1, dwParam2)) { + WARN("can't notify client !\n"); + return MMSYSERR_ERROR; + } + break; + default: + FIXME("Unknown CB message %u\n", wMsg); + return MMSYSERR_INVALPARAM; } - - wwo->dwPlayedTotal=wwo->dwWrittenTotal-( wwo->dwBufferSize - info.bytes ); - return wwo->dwPlayedTotal; + return MMSYSERR_NOERROR; } +/************************************************************************** + * wodUpdatePlayedTotal [internal] + * + */ +static void wodUpdatePlayedTotal(WINE_WAVEOUT* wwo, DWORD availInQ) +{ + wwo->dwPlayedTotal = wwo->dwWrittenTotal - (wwo->dwBufferSize - availInQ); +} /************************************************************************** * wodPlayer_BeginWaveHdr [internal] @@ -523,12 +482,11 @@ * If the specified wave header is a begin loop and we're not already in * a loop, setup the loop. */ -static void wodPlayer_BeginWaveHdr( WINE_WAVEOUT* wwo, - LPWAVEHDR lpWaveHdr ) +static void wodPlayer_BeginWaveHdr(WINE_WAVEOUT* wwo, LPWAVEHDR lpWaveHdr) { - wwo->lpPlayPtr=lpWaveHdr; + wwo->lpPlayPtr = lpWaveHdr; - if( !lpWaveHdr ) return; + if (!lpWaveHdr) return; if (lpWaveHdr->dwFlags & WHDR_BEGINLOOP) { if (wwo->lpLoopPtr) { @@ -541,6 +499,7 @@ wwo->dwLoops = lpWaveHdr->dwLoops; } } + wwo->dwPartialOffset = 0; } /************************************************************************** @@ -550,8 +509,9 @@ */ static LPWAVEHDR wodPlayer_PlayPtrNext(WINE_WAVEOUT* wwo) { - LPWAVEHDR lpWaveHdr=wwo->lpPlayPtr; + LPWAVEHDR lpWaveHdr = wwo->lpPlayPtr; + wwo->dwPartialOffset = 0; if ((lpWaveHdr->dwFlags & WHDR_ENDLOOP) && wwo->lpLoopPtr) { /* We're at the end of a loop, loop if required */ if (--wwo->dwLoops > 0) { @@ -564,17 +524,17 @@ * the opening one or for both ??? * code assumes for closing loop only */ - wwo->lpLoopPtr = NULL; - wodPlayer_BeginWaveHdr( wwo, lpWaveHdr ); } else { - wwo->lpLoopPtr = NULL; - wodPlayer_BeginWaveHdr( wwo, lpWaveHdr=lpWaveHdr->lpNext ); - } + lpWaveHdr = lpWaveHdr->lpNext; + } + wwo->lpLoopPtr = NULL; + wodPlayer_BeginWaveHdr(wwo, lpWaveHdr); } } else { /* We're not in a loop. Advance to the next wave header */ - wodPlayer_BeginWaveHdr( wwo, lpWaveHdr=lpWaveHdr->lpNext ); + wodPlayer_BeginWaveHdr(wwo, lpWaveHdr = lpWaveHdr->lpNext); } + return lpWaveHdr; } @@ -584,11 +544,13 @@ * This is based on the number of fragments we want to be clear before * writing and the number of free fragments we already have. */ -static DWORD wodPlayer_DSPWait( WINE_WAVEOUT *wwo, WORD uFreeFragments ) +static DWORD wodPlayer_DSPWait(const WINE_WAVEOUT *wwo, DWORD availInQ) { - return (uFreeFragments>wwo->uWaitForFragments)?1: - wwo->dwMillisPerFragment* - (wwo->uWaitForFragments-uFreeFragments); + DWORD uFreeFragments = availInQ / wwo->dwFragmentSize; + + return (uFreeFragments >= wwo->uWaitForFragments) + ? 1 : (wwo->dwFragmentSize * 1000 / wwo->format.wf.nAvgBytesPerSec) * + (wwo->uWaitForFragments - uFreeFragments); } /************************************************************************** @@ -598,20 +560,15 @@ * This is based on the number of bytes remaining to be written in the * wave. */ -static DWORD wodPlayer_NotifyWait( WINE_WAVEOUT *wwo, LPWAVEHDR lpWaveHdr ) +static DWORD wodPlayer_NotifyWait(const WINE_WAVEOUT* wwo, LPWAVEHDR lpWaveHdr) { DWORD dwMillis; - if( lpWaveHdr->reserved<wwo->dwPlayedTotal ) { - dwMillis=1; + if (lpWaveHdr->reserved < wwo->dwPlayedTotal) { + dwMillis = 1; } else { - dwMillis=(lpWaveHdr->reserved-wwo->dwPlayedTotal) * - wwo->dwMillisPerFragment / wwo->dwFragmentSize; - TRACE( "wait for %lu bytes = %lu\n", - (lpWaveHdr->reserved-wwo->dwPlayedTotal), - dwMillis ); - if( dwMillis < 1 ) - dwMillis=1; + dwMillis = (lpWaveHdr->reserved - wwo->dwPlayedTotal) * 1000 / wwo->format.wf.nAvgBytesPerSec; + if (!dwMillis) dwMillis = 1; } return dwMillis; @@ -621,26 +578,28 @@ /************************************************************************** * wodPlayer_WriteMaxFrags [internal] * Writes the maximum number of bytes possible to the DSP and returns - * the number of bytes written. Also updates fragments in dspspace. + * the number of bytes written. */ -static DWORD wodPlayer_WriteMaxFrags( WINE_WAVEOUT *wwo, LPSTR lpData, - DWORD dwLength, - audio_buf_info* dspspace ) -{ - /* Only attempt to write to free fragments */ - int maxWrite=dspspace->fragments*dspspace->fragsize; - int toWrite=min(dwLength,maxWrite); - - int written=write(wwo->unixdev, lpData, toWrite); - - TRACE("wrote %d of %lu bytes\n", - written, dwLength ); - if( written > 0 ) { - /* Keep a count of the total bytes written to the DSP */ - wwo->dwWrittenTotal+=written; - /* reduce the number of free fragments */ - dspspace->fragments -= (written/dspspace->fragsize)+(written%dspspace->fragsize>0); +static int wodPlayer_WriteMaxFrags(WINE_WAVEOUT* wwo, DWORD* bytes) +{ + /* Only attempt to write to free bytes */ + DWORD dwLength = wwo->lpPlayPtr->dwBufferLength - wwo->dwPartialOffset; + int toWrite = min(dwLength, *bytes); + int written; + + TRACE("Writing wavehdr %p.%lu\n", wwo->lpPlayPtr, wwo->dwPartialOffset); + written = write(wwo->unixdev, wwo->lpPlayPtr->lpData + wwo->dwPartialOffset, toWrite); + if (written <= 0) return written; + + if (written >= dwLength) { + /* If we wrote it all, skip to the next header */ + wodPlayer_PlayPtrNext(wwo); + } else { + /* Remove the amount written */ + wwo->dwPartialOffset += written; } + *bytes -= written; + wwo->dwWrittenTotal += written; return written; } @@ -654,37 +613,30 @@ * we notify all wavehdrs and remove them all from the queue even if they * are unplayed or part of a loop. */ -static DWORD wodPlayer_NotifyCompletions( WINE_WAVEOUT* wwo, WORD uDevID, BOOL force) +static DWORD wodPlayer_NotifyCompletions(WINE_WAVEOUT* wwo, BOOL force) { LPWAVEHDR lpWaveHdr; - updatePlayedTotal(wwo); /* Start from lpQueuePtr and keep notifying until: * - we hit an unwritten wavehdr * - we hit the beginning of a running loop * - we hit a wavehdr which hasn't finished playing */ - while( (lpWaveHdr=wwo->lpQueuePtr) && - (force || - (lpWaveHdr != wwo->lpPlayPtr && - lpWaveHdr != wwo->lpLoopPtr && - lpWaveHdr->reserved <= wwo->dwPlayedTotal ))) { + while ((lpWaveHdr = wwo->lpQueuePtr) && + (force || + (lpWaveHdr != wwo->lpPlayPtr && + lpWaveHdr != wwo->lpLoopPtr && + lpWaveHdr->reserved <= wwo->dwPlayedTotal))) { wwo->lpQueuePtr = lpWaveHdr->lpNext; lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; lpWaveHdr->dwFlags |= WHDR_DONE; - TRACE("Notifying client with %p\n", lpWaveHdr); - if (OSS_NotifyClient(uDevID, WOM_DONE, (DWORD)lpWaveHdr, 0) != MMSYSERR_NOERROR) { - WARN("can't notify client !\n"); - } + wodNotifyClient(wwo, WOM_DONE, (DWORD)lpWaveHdr, 0); } - return ( lpWaveHdr && - lpWaveHdr != wwo->lpPlayPtr && - lpWaveHdr != wwo->lpLoopPtr ) ? - wodPlayer_NotifyWait( wwo, lpWaveHdr ) : - 0 ; + return (lpWaveHdr && lpWaveHdr != wwo->lpPlayPtr && lpWaveHdr != wwo->lpLoopPtr) ? + wodPlayer_NotifyWait(wwo, lpWaveHdr) : INFINITE; } /************************************************************************** @@ -692,10 +644,10 @@ * * wodPlayer helper. Resets current output stream. */ -static void wodPlayer_Reset(WINE_WAVEOUT* wwo, WORD uDevID, BOOL reset) +static void wodPlayer_Reset(WINE_WAVEOUT* wwo, BOOL reset) { /* updates current notify list */ - wodPlayer_NotifyCompletions(wwo, uDevID, FALSE); + wodPlayer_NotifyCompletions(wwo, FALSE); /* flush all possible output */ if (ioctl(wwo->unixdev, SNDCTL_DSP_RESET, 0) == -1) { @@ -706,17 +658,16 @@ } /* Clear partial wavehdr */ - wwo->dwPartialBytes=0; - wwo->lpPartialData=NULL; + wwo->dwPartialOffset = 0; if (reset) { /* empty notify list */ - wodPlayer_NotifyCompletions(wwo, uDevID, TRUE); + wodPlayer_NotifyCompletions(wwo, TRUE); wwo->lpPlayPtr = wwo->lpQueuePtr = wwo->lpLoopPtr = NULL; wwo->state = WINE_WS_STOPPED; wwo->dwPlayedTotal = 0; - wwo->dwWrittenTotal = 0; + wwo->dwWrittenTotal = 0; } else { /* FIXME: this is not accurate when looping, but can be do better ? */ wwo->lpPlayPtr = (wwo->lpLoopPtr) ? wwo->lpLoopPtr : wwo->lpQueuePtr; @@ -725,41 +676,9 @@ } /************************************************************************** - * wodPlayer_AwaitEvent [internal] - * Wait for a command to be sent to the wodPlayer or for time to pass - * until wodPlayer needs to do something again. - */ -static void wodPlayer_AwaitEvent( WINE_WAVEOUT* wwo, - DWORD dwNextFeedTime, - DWORD dwNextNotifyTime ) -{ - DWORD dwSleepTime; - - /** Wait for the shortest time before an action is required. If there - * are no pending actions, wait forever for a command. - */ - if( dwNextFeedTime == 0 ) { - if( dwNextNotifyTime == 0 ) - dwSleepTime=INFINITE; - else - dwSleepTime=dwNextNotifyTime; - } else { - if( dwNextNotifyTime == 0 ) - dwSleepTime=dwNextFeedTime; - else - dwSleepTime=min( dwNextFeedTime, dwNextNotifyTime ); - } - TRACE( "waiting %lu millis (%lu,%lu)\n", dwSleepTime, - dwNextFeedTime,dwNextNotifyTime ); - WaitForSingleObject(wwo->msgRing.msg_event, dwSleepTime); - TRACE( "wait returned\n"); - -} - -/************************************************************************** * wodPlayer_ProcessMessages [internal] */ -static void wodPlayer_ProcessMessages( WINE_WAVEOUT* wwo, WORD uDevID ) +static void wodPlayer_ProcessMessages(WINE_WAVEOUT* wwo) { LPWAVEHDR lpWaveHdr; int msg; @@ -767,11 +686,10 @@ HANDLE ev; while (OSS_RetrieveRingMessage(&wwo->msgRing, &msg, &param, &ev)) { - TRACE( "Received %s %lx\n", - wodPlayerCmdString[msg-WM_USER-1], param ); + TRACE("Received %s %lx\n", wodPlayerCmdString[msg - WM_USER - 1], param); switch (msg) { case WINE_WM_PAUSING: - wodPlayer_Reset(wwo, uDevID, FALSE); + wodPlayer_Reset(wwo, FALSE); wwo->state = WINE_WS_PAUSED; SetEvent(ev); break; @@ -788,12 +706,13 @@ for (wh = &(wwo->lpQueuePtr); *wh; wh = &((*wh)->lpNext)); *wh = lpWaveHdr; } - wodPlayer_BeginWaveHdr(wwo,lpWaveHdr); + if (!wwo->lpPlayPtr) + wodPlayer_BeginWaveHdr(wwo,lpWaveHdr); if (wwo->state == WINE_WS_STOPPED) wwo->state = WINE_WS_PLAYING; break; case WINE_WM_RESETTING: - wodPlayer_Reset(wwo, uDevID, TRUE); + wodPlayer_Reset(wwo, TRUE); SetEvent(ev); break; case WINE_WM_CLOSING: @@ -804,6 +723,17 @@ SetEvent(ev); ExitThread(0); /* shouldn't go here */ + case WINE_WM_UPDATE: + { + audio_buf_info info; + + if (ioctl(wwo->unixdev, SNDCTL_DSP_GETOSPACE, &info) < 0) { + ERR("ioctl failed (%s)\n", strerror(errno)); + } else { + wodUpdatePlayedTotal(wwo, info.bytes); + } + } + break; default: FIXME("unknown message %d\n", msg); break; @@ -816,77 +746,45 @@ * Feed as much sound data as we can into the DSP and return the number of * milliseconds before it will be necessary to feed the DSP again. */ -static DWORD wodPlayer_FeedDSP( WINE_WAVEOUT* wwo ) +static DWORD wodPlayer_FeedDSP(WINE_WAVEOUT* wwo) { - LPWAVEHDR lpWaveHdr=wwo->lpPlayPtr; - DWORD written=0; - DWORD bytesToWrite; audio_buf_info dspspace; + DWORD availInQ; - /* Read output space info so we know how much writing to do */ if (ioctl(wwo->unixdev, SNDCTL_DSP_GETOSPACE, &dspspace) < 0) { - ERR("IOCTL can't 'SNDCTL_DSP_GETOSPACE' !\n"); + ERR("IOCTL can't 'SNDCTL_DSP_GETOSPACE' !\n"); + return INFINITE; } + TRACE("fragments=%d/%d, fragsize=%d, bytes=%d\n", + dspspace.fragments, dspspace.fragstotal, dspspace.fragsize, dspspace.bytes); - TRACE( "fragments=%d, fragsize=%d, fragstotal=%d, bytes=%d\n", - dspspace.fragments, dspspace.fragsize, - dspspace.fragstotal, dspspace.bytes ); + availInQ = dspspace.bytes; + wodUpdatePlayedTotal(wwo, availInQ); - /* Do nothing if the DSP isn't hungry */ - if( dspspace.fragments==0 ) { - return wodPlayer_DSPWait(wwo,dspspace.fragments); - } - - /* If there's a partially written wavehdr, feed more of it - * ------------------------------------------------------- - */ - bytesToWrite=wwo->dwPartialBytes; - if( bytesToWrite > 0 ) { - TRACE("partial write %lu bytes at %p\n", - wwo->dwPartialBytes, - wwo->lpPartialData ); - written=wodPlayer_WriteMaxFrags( wwo, wwo->lpPartialData, - bytesToWrite, - &dspspace ); - if( written >= bytesToWrite ) { - /* If we wrote it all, skip to the next header */ - wwo->dwPartialBytes=0; - wwo->lpPartialData=NULL; - lpWaveHdr=wodPlayer_PlayPtrNext( wwo ); - } else { - /* Remove the amount written */ - wwo->lpPartialData+=written; - wwo->dwPartialBytes-=written; - } + /* input queue empty and output buffer with less than one fragment to play */ + if (!wwo->lpPlayPtr && wwo->dwBufferSize < availInQ + 2 * wwo->dwFragmentSize) { + TRACE("Run out of wavehdr:s... flushing\n"); + ioctl(wwo->unixdev, SNDCTL_DSP_SYNC, 0); + wodUpdatePlayedTotal(wwo, wwo->dwBufferSize); + return INFINITE; } - /* Feed wavehdrs until we run out of wavehdrs or DSP space - * ------------------------------------------------------- - */ - while( lpWaveHdr && dspspace.fragments > 0 ) { - TRACE( "Writing wavehdr %p %lu bytes\n", lpWaveHdr, - lpWaveHdr->dwBufferLength ); + /* no more room... no need to try to feed */ + if (dspspace.fragments == 0) return wodPlayer_DSPWait(wwo, 0); - /* note the value that dwPlayedTotal will be when this - * wave finishes playing - */ - lpWaveHdr->reserved=wwo->dwWrittenTotal+lpWaveHdr->dwBufferLength; + /* Feed from partial wavehdr */ + if (wwo->lpPlayPtr && wwo->dwPartialOffset != 0) { + wodPlayer_WriteMaxFrags(wwo, &availInQ); + } - written=wodPlayer_WriteMaxFrags( wwo, lpWaveHdr->lpData, - lpWaveHdr->dwBufferLength, - &dspspace ); - /* If it's all written, on to the next one, else remember the - * partial write for next FeedDSP call. - */ - if( written >= lpWaveHdr->dwBufferLength ) { - lpWaveHdr=wodPlayer_PlayPtrNext( wwo ); - } else { - wwo->dwPartialBytes=lpWaveHdr->dwBufferLength-written; - wwo->lpPartialData=lpWaveHdr->lpData+written; - } + /* Feed wavehdrs until we run out of wavehdrs or DSP space */ + if (wwo->dwPartialOffset == 0) while (wwo->lpPlayPtr && availInQ > 0) { + /* note the value that dwPlayedTotal will return when this wave finishes playing */ + wwo->lpPlayPtr->reserved = wwo->dwWrittenTotal + wwo->lpPlayPtr->dwBufferLength; + wodPlayer_WriteMaxFrags(wwo, &availInQ); } - return lpWaveHdr ? wodPlayer_DSPWait(wwo,dspspace.fragments) : 0 ; + return wodPlayer_DSPWait(wwo, availInQ); } @@ -897,20 +795,26 @@ { WORD uDevID = (DWORD)pmt; WINE_WAVEOUT* wwo = (WINE_WAVEOUT*)&WOutDev[uDevID]; - DWORD dwNextFeedTime=0; /* Time before DSP needs feeding */ - DWORD dwNextNotifyTime=0; /* Time before next wave completion */ + DWORD dwNextFeedTime = INFINITE; /* Time before DSP needs feeding */ + DWORD dwNextNotifyTime = INFINITE; /* Time before next wave completion */ + DWORD dwSleepTime; - wwo->state=WINE_WS_STOPPED; - SetEvent( wwo->hStartUpEvent ); + wwo->state = WINE_WS_STOPPED; + SetEvent(wwo->hStartUpEvent); - for(;;) { - wodPlayer_AwaitEvent(wwo,dwNextFeedTime,dwNextNotifyTime); - wodPlayer_ProcessMessages(wwo,uDevID); - if( wwo->state== WINE_WS_PLAYING ) { - dwNextFeedTime=wodPlayer_FeedDSP(wwo); - dwNextNotifyTime=wodPlayer_NotifyCompletions(wwo,uDevID,FALSE); + for (;;) { + /** Wait for the shortest time before an action is required. If there + * are no pending actions, wait forever for a command. + */ + dwSleepTime = min(dwNextFeedTime, dwNextNotifyTime); + TRACE("waiting %lums (%lu,%lu)\n", dwSleepTime, dwNextFeedTime, dwNextNotifyTime); + WaitForSingleObject(wwo->msgRing.msg_event, dwSleepTime); + wodPlayer_ProcessMessages(wwo); + if (wwo->state == WINE_WS_PLAYING) { + dwNextFeedTime = wodPlayer_FeedDSP(wwo); + dwNextNotifyTime = wodPlayer_NotifyCompletions(wwo, FALSE); } else { - dwNextFeedTime=dwNextNotifyTime=0; + dwNextFeedTime = dwNextNotifyTime = INFINITE; } } } @@ -1039,7 +943,7 @@ if (dsp_stereo != (wwo->format.wf.nChannels > 1) ? 1 : 0) ERR("Can't set stereo to %u (%d)\n", (wwo->format.wf.nChannels > 1) ? 1 : 0, dsp_stereo); - if (!NEAR_MATCH(sample_rate,wwo->format.wf.nSamplesPerSec)) + if (!NEAR_MATCH(sample_rate, wwo->format.wf.nSamplesPerSec)) ERR("Can't set sample_rate to %lu (%d)\n", wwo->format.wf.nSamplesPerSec, sample_rate); @@ -1062,11 +966,10 @@ /* Remember fragsize and total buffer size for future use */ wwo->dwFragmentSize = info.fragsize; wwo->dwBufferSize = info.fragstotal * info.fragsize; - wwo->dwMillisPerFragment = info.fragsize * 1000 / wwo->format.wf.nAvgBytesPerSec; wwo->uWaitForFragments = info.fragstotal * REFILL_BUFFER_WHEN; - TRACE( "wait for %d fragments at %lu millis/fragment\n", - wwo->uWaitForFragments, - wwo->dwMillisPerFragment ); + wwo->dwPlayedTotal = 0; + wwo->dwWrittenTotal = 0; + TRACE("wait for %d fragments\n", wwo->uWaitForFragments); OSS_InitRingMessage(&wwo->msgRing); @@ -1091,11 +994,7 @@ wwo->format.wf.nSamplesPerSec, wwo->format.wf.nChannels, wwo->format.wf.nBlockAlign); - if (OSS_NotifyClient(wDevID, WOM_OPEN, 0L, 0L) != MMSYSERR_NOERROR) { - WARN("can't notify client !\n"); - return MMSYSERR_INVALPARAM; - } - return MMSYSERR_NOERROR; + return wodNotifyClient(wwo, WOM_OPEN, 0L, 0L); } /************************************************************************** @@ -1130,10 +1029,7 @@ close(wwo->unixdev); wwo->unixdev = -1; wwo->dwFragmentSize = 0; - if (OSS_NotifyClient(wDevID, WOM_CLOSE, 0L, 0L) != MMSYSERR_NOERROR) { - WARN("can't notify client !\n"); - ret = MMSYSERR_INVALPARAM; - } + ret = wodNotifyClient(wwo, WOM_CLOSE, 0L, 0L); } return ret; } @@ -1246,10 +1142,7 @@ /* FIXME: is NotifyClient with WOM_DONE right ? (Comet Busters 1.3.3 needs this notification) */ /* FIXME: Myst crashes with this ... hmm -MM - if (OSS_NotifyClient(wDevID, WOM_DONE, 0L, 0L) != MMSYSERR_NOERROR) { - WARN("can't notify client !\n"); - return MMSYSERR_INVALPARAM; - } + return wodNotifyClient(wwo, WOM_DONE, 0L, 0L); */ return MMSYSERR_NOERROR; @@ -1293,7 +1186,8 @@ if (lpTime == NULL) return MMSYSERR_INVALPARAM; wwo = &WOutDev[wDevID]; - val = updatePlayedTotal(wwo); + OSS_AddRingMessage(&wwo->msgRing, WINE_WM_UPDATE, 0, TRUE); + val = wwo->dwPlayedTotal; TRACE("wType=%04X wBitsPerSample=%u nSamplesPerSec=%lu nChannels=%u nAvgBytesPerSec=%lu\n", lpTime->wType, wwo->format.wBitsPerSample, @@ -1307,7 +1201,7 @@ TRACE("TIME_BYTES=%lu\n", lpTime->u.cb); break; case TIME_SAMPLES: - lpTime->u.sample = val * 8 / wwo->format.wBitsPerSample; + lpTime->u.sample = val * 8 / wwo->format.wBitsPerSample /wwo->format.wf.nChannels; TRACE("TIME_SAMPLES=%lu\n", lpTime->u.sample); break; case TIME_SMPTE: @@ -1498,7 +1392,7 @@ * clear it, or we get junk noise */ /* some libc implementations are buggy: their memset reads from the buffer... * to work around it, we have the 0 the block by hand and do not call: - * memset(wwo->mapping,0,wwo->maplen); + * memset(wwo->mapping,0, wwo->maplen); */ { char* p1 = wwo->mapping; @@ -1902,6 +1796,31 @@ *======================================================================*/ /************************************************************************** + * widNotifyClient [internal] + */ +static DWORD widNotifyClient(WINE_WAVEIN* wwi, WORD wMsg, DWORD dwParam1, DWORD dwParam2) +{ + TRACE("wMsg = 0x%04x dwParm1 = %04lX dwParam2 = %04lX\n", wMsg, dwParam1, dwParam2); + + switch (wMsg) { + case WIM_OPEN: + case WIM_CLOSE: + case WIM_DATA: + if (wwi->wFlags != DCB_NULL && + !DriverCallback(wwi->waveDesc.dwCallback, wwi->wFlags, wwi->waveDesc.hWave, + wMsg, wwi->waveDesc.dwInstance, dwParam1, dwParam2)) { + WARN("can't notify client !\n"); + return MMSYSERR_ERROR; + } + break; + default: + FIXME("Unknown CB message %u\n", wMsg); + return MMSYSERR_INVALPARAM; + } + return MMSYSERR_NOERROR; +} + +/************************************************************************** * widGetDevCaps [internal] */ static DWORD widGetDevCaps(WORD wDevID, LPWAVEINCAPSA lpCaps, DWORD dwSize) @@ -1929,10 +1848,7 @@ WAVEHDR* lpWaveHdr; DWORD dwSleepTime; DWORD bytesRead; - LPVOID buffer = HeapAlloc(GetProcessHeap(), - HEAP_ZERO_MEMORY, - wwi->dwFragmentSize); - + LPVOID buffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, wwi->dwFragmentSize); LPVOID pOffset = buffer; audio_buf_info info; int xs; @@ -1997,11 +1913,7 @@ lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; lpWaveHdr->dwFlags |= WHDR_DONE; - if (OSS_NotifyClient(uDevID, WIM_DATA, - (DWORD)lpWaveHdr, 0) != MMSYSERR_NOERROR) - { - WARN("can't notify client !\n"); - } + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); lpWaveHdr = wwi->lpQueuePtr = lpNext; } } @@ -2041,11 +1953,7 @@ lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; lpWaveHdr->dwFlags |= WHDR_DONE; - if (OSS_NotifyClient(uDevID, WIM_DATA, - (DWORD)lpWaveHdr, 0) != MMSYSERR_NOERROR) - { - WARN("can't notify client !\n"); - } + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); wwi->lpQueuePtr = lpWaveHdr = lpNext; if (!lpNext && bytesRead) { @@ -2116,10 +2024,7 @@ lpWaveHdr->dwFlags &= ~WHDR_INQUEUE; lpWaveHdr->dwFlags |= WHDR_DONE; - if (OSS_NotifyClient(uDevID, WIM_DATA, - (DWORD)lpWaveHdr, 0) != MMSYSERR_NOERROR) { - WARN("can't notify client !\n"); - } + widNotifyClient(wwi, WIM_DATA, (DWORD)lpWaveHdr, 0); } wwi->lpQueuePtr = NULL; SetEvent(ev); @@ -2258,11 +2163,7 @@ CloseHandle(wwi->hStartUpEvent); wwi->hStartUpEvent = INVALID_HANDLE_VALUE; - if (OSS_NotifyClient(wDevID, WIM_OPEN, 0L, 0L) != MMSYSERR_NOERROR) { - WARN("can't notify client !\n"); - return MMSYSERR_INVALPARAM; - } - return MMSYSERR_NOERROR; + return widNotifyClient(wwi, WIM_OPEN, 0L, 0L); } /************************************************************************** @@ -2289,11 +2190,7 @@ close(wwi->unixdev); wwi->unixdev = -1; wwi->dwFragmentSize = 0; - if (OSS_NotifyClient(wDevID, WIM_CLOSE, 0L, 0L) != MMSYSERR_NOERROR) { - WARN("can't notify client !\n"); - return MMSYSERR_INVALPARAM; - } - return MMSYSERR_NOERROR; + return widNotifyClient(wwi, WIM_CLOSE, 0L, 0L); } /**************************************************************************

1 0

RE: Wine, Office, and the antitrust settlement
by Patrik Stridvall 10 Dec '01

10 Dec '01

> I'm proposing that Wine be part of the settlement of the > Microsoft antitrust trial. See > http://www.kegel.com/remedy.html > Comments welcome. Well. I think the paragraph below is far to much to ask and I don't think anti-trust law can force Microsoft to do this. >From http://www.kegel.com/remedy.html: < Contracting with a Third Party to Enhance Wine to Support < Microsoft Office. "Within 60 days of entry of this Final Judgement, < Microsoft must contract with one or more outside firms to enhance the < Open Source Windows Emulator WINE to be able to install and run < Office 2000 under Linux. The work shall continue,with new releases < of Wine occurring every 60 days, until completed, or until the expenses < incurred by the outside firms reach 2 percent of the total development < and marketing costs of Office 2000. Furthermore, as soon as practicable, < but in no case later than 60 days prior to the date each new version of < Office becomes commercially available for use with a Windows Operating < System Product, Microsoft shall again contract with one or more outside < firms to enhance the Open Source Windows Emulator WINE to be able to < install and run the new version of Office under Linux. The work shall < continue, with new releases of Wine occurring every 60 days, until < completed, or until the expenses incurred by the outside firms < reach 2 percent of the total development and marketing costs < of the new version of Office. What is perhaps more realistic to require IMHO that Office and other Microsoft applications shouldn't crash or behave in a inconsistant way just because some odd feature in some API call is not available. Instead it should say, sorry can't do that not supported in the OS. This would prevent Microsoft from sabotaging Wine as well preventing users of say Windows 95 from needlessly having to upgrade. Yes, I'm aware of that Microsoft of course not can check every API call and have a fallback for each function, but groups of features that is potentially unneeded for basic features in Office like: 1. DirectX 2. MAPI 3. .NET 4. DAO 5. "Sound" 6. "Networking" 7. <Insert whatever favorite technology from Microsoft that you like> shouldn't be required to do normal stuff in Office. > I have a few questions for Wine developers, especially > the good folks at Codeweavers and Transgaming: > > 1. How much would it cost to achieve full support for > Office 2000 in Wine? That is an impossible question to answer. > 2. Is it true that Office uses undocumented Windows APIs? > If so, how many? Are they a significant part of the > challenge of supporting Office? Yes. But I don't rember which ones right know but there are quite a lot of undocumented API calls used by a lot of different programs. Perhaps somebody else on the list can be more specific.

2 1

Re: UNC patch
by Eric Pouech 09 Dec '01

09 Dec '01

> Ok, I thing i got it now. You are asking for a configuration option in > e.g. ~/.wine/config to enable or disable UNC support like this: yup... A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

6 13

Where do I start on DDX_Radio?
by Bill Medland 08 Dec '01

08 Dec '01

Any chance of a quick pointer on this? I have a dialog containing a group of radio buttons, managed using DDX_Radio etc. On windows the DDX_Radio sets the correct button. However under WINE it always seems to set the first button of the group. Does anyone know what part of the code I should even be investigating (i.e. where is the dialog management code) Bill

2 1

Re: MIDL and COM
by Peter Samuelson 07 Dec '01

07 Dec '01

I know this thread is a couple weeks old, I saw it on Wine Weekly News... [A. Julliard] > > If we want to use .idl files we'll have to come up with our own > > compiler, and then we can put the .idl source in the tree and > > compile it at build time. [Ove Kaaven] > Hmm. Even when using flex and bison, it sounds like a fair amount of > work... wonder who would volunteer? The FreeDCE Project has a DCE IDL compiler which I understand is mostly compatible with MIDL.EXE. See http://sf.net/projects/freedce and http://www.dcerpc.net/ (the latter seems to be malfunctioning at the moment). Peter

2 4

Re: Read/WriteProcessMemory fix
by Alexandre Julliard 07 Dec '01

07 Dec '01

Andrew <andrew(a)transgaming.com> writes: > This fixes a bug in ReadProcessMemory and WriteProcessMemory, and > rearranges some of the code. (In particular, all the code that knows > that ptrace works in ints has been contained to server/ptrace.c.) What bug is it fixing? I'm not sure the reorganisation is a good idea; it seems less efficient, less portable, and AFAICS broken for accesses of less than an int size. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: SystemParametersInfo: DoubleClick actions
by Andriy Palamarchuk 07 Dec '01

07 Dec '01

The last week I submitted this patch, but it is not applied yet. Are there any problems with the patch? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 1

Re: Fix for MS debug info problems with winedbg
by Francois Gouget 06 Dec '01

06 Dec '01

On Thu, 6 Dec 2001, Dave Hawkes wrote: > Fix for some types of C++ debug info that can cause winedbg to crash. Seems like the patch is missing :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

2 1

Re:UNC patch
by Eric Pouech 06 Dec '01

06 Dec '01

I think we should need some kind of configuration for this (to provide a bit more flexibility to end users) this would means,for example, allow or not automatic UNC operations (for now only binding a UNC name to a mounted SMB share). As in Wine, we don't allow mounting, as a default, all the file hierarchy, it would be interesting to provide the same type of functionnalities (bazed on host names for example... but I fear this would be a bit too complex to do). But as a starter, the option to enable binding should be made available. A+ > Hello, > > as suggested awhile ago from Dan Kegel on cemw. > > > If Wine handled UNC paths as follows: > > Given a UNC path \\foo\bar, > > look at /etc/mtab for a matching smbfs mount. > > If one is found, look at .wine/config for a drive letter mapped to that mount. > > If one is found, convert the UNC path to be relative to that drive letter. > > ChangeLog > --------- > * files/file.c: > Stefan.Leichter(a)camLine.com > implemented UNC filenames using samba shares mounted according to > /etc/mtab --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

3 2

Re:UNC patch
by Eric Pouech 06 Dec '01

06 Dec '01

> Sorry, I have no idea what you are talking about. Maybe it is my bad > english or my little knowledge about windows. no, it's my French ;-) what I'm talking about binding is the operation of making the relationship between a UNC name and a (samba-) mounted SMB share. the equivalent operation for names (making the relationship between a DOS driver letter and a Unix directory) is driven by the Wine configuration. Even, if both schemes are a bit different, I thought we need the same configuration capabilities in Wine. These are several things we could do (first one is a must have IMO, the others are open to discussion) - enable / disable the UNC to mount point parsing - enable / disable the UNX to mount point parsing on a per host basis - fully configure the UNC to mount point (like we do for DOS drive letters) - ... A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

2 1

SHLWAPI pre-submit questions
by Jon Griffiths 06 Dec '01

06 Dec '01

Hi, I've been hacking on SHLWAPI.dll for a couple of months now while holidaying around Thailand, using a beaten up laptop. Since I just obtained free use of a real machine with a good net connection, I want to start submitting my work but I thought I'd clear up a few style issues beforehand: 1. Is it OK to give meaningful names to undocumented functions? e.g. SHLWAPI_1/2 => UrlGetInfoA/W SHLWAPI_5/6 => PathFindOnPathExA/W I want to do this where the names are no-brainers, as in the case above, and the functions are referenced by the dll internally. 2. Is it OK to sync shlwapi.h with the windows version ? e.g. Remove undocumented entries Remove its dependence on obj_base.h (windows has none) Add the function exclusion defines as per windows I assume this is fine, but doing this causes the next question - 3. How to deal with shared undocumented functions? e.g. StrRetToBufA/W is used by shell32, but should not defined in shlwapi.h. Here there are 4 Choices: 1. Define twice (Ugly) 2. Put into a new wine/undocshlwapi.h (Seems that these are depreciated?) 3. Define anyway (Im not a fan of having undoc functions in public headers) 4. Have shell32 functions #include "../shlwapi/internal.h" (A little unclean) I'd like to go for 4, any objections? I'll start feeding in the new function implementations over the next little while, once the structure is sorted. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com

5 7

Happy Christmas wine
by Russell Howe 05 Dec '01

05 Dec '01

I got sent a Christmas card in Windows EXE format. Since it works perfectly with wine I thought I'd share it :) The file is at http://www2.cs.man.ac.uk/~hower0/crimbo.exe.gz -- Russell Howe rhowe(a)mindless.com

1 0

dlls/winedos/module.c:632: `write_pipe' undeclared
by Gerald Pfeifer 05 Dec '01

05 Dec '01

revision 1.10 date: 2001/12/04 19:54:45; author: julliard; state: Exp; lines: +41 -60 Moved most of the real-mode stuff to dlls/winedos. of dlls/winedos/module.c causes the following build failure on FreeBSD 4.4: /usr/bin/gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o module.o module.c module.c: In function `MZ_AllocDPMITask': module.c:614: warning: `return' with a value, in function returning void module.c: In function `MZ_Current': module.c:632: `write_pipe' undeclared (first use in this function) module.c:632: (Each undeclared identifier is reported only once module.c:632: for each function it appears in.) module.c:633: warning: control reaches end of non-void function gmake[2]: *** [module.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/dlls/winedos' gmake[1]: *** [winedos/libwinedos.so] Error 2 Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

Re: [RFC] Async I/O patch: server code + ReadFileEx()
by Mike McCormack 05 Dec '01

05 Dec '01

Hi Martin, i hadn't heard from you in a while, so i though you might have given up after nobody said anything about the last patch, but i see you've been busy :-) i also had a go at fixing the problems you pointed out. i've attached the patch i've been working on... don't use it, it _will_ crash your wineserver! i need to create a requeue async request like yours, and activate my queues properly. The code is written to support async on serial port objects, not file objects. Some thoughts: * Shouldn't each wineserver object should manage it's own queues? Many different types of requests can be overlapped ... for example WaitNamedPipe can be overlapped. Should every object keep a queue for waiting on named pipes? * wineserver should manage the timeouts and activation of requests (i see we agree there) * Wouldn't it be better to pass an status code back to the client rather than the poll events? That way we can have STATUS_TIMEOUT, STATUS_PENDING, STATUS_CANCELLED, etc. STATUS_PENDING can be the signal to start reading/writing/etc. Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi, > >here is a patch that fixes some of the issues with the async IO >implementation in Wine that we discussed previously. My work on this >was delayed by other duties, sorry. To make matters worse, I'll be >out of office for the next 4 weeks (vacation :-) > > THIS PATCH IS NOT FOR PRODUCTION USE. > >I am submitting it as a RFC to show the basic concepts I am aiming at. >Most important is the server-side code (server/async.h, server/async.c) >that demonstrates the basic mechanism I am suggesting. ------------------------------------------ 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

__p___argc, MSVCRT,__wine_get_main_args and ParseOptions
by Uwe Bonnes 04 Dec '01

04 Dec '01

Hallo, running with builtin msvcrt like > wine --dll msvcrt=b a.exe for the following source: #include <stdio.h> #include <stdlib.h> #define _stat stat int main( void ) { printf("%d\n",__p___argc()); printf("%d\n",*(__p___argc())); return 0; } still counts _two_ arguments, as it sees "wine a.exe". OPTIONS_ParseOptions,__wine_get_main_args and __wine_get_wmain_args are very delicate stocked on each other, so I don't know which one to change. For a short test I did hertz:/spare/bon/wine-clean> cvs -d $CVSROOT diff -u wine/misc/options.c Index: wine/misc/options.c =================================================================== RCS file: /home/wine/wine/misc/options.c,v retrieving revision 1.29 diff -u -r1.29 options.c --- wine/misc/options.c 2001/11/06 00:49:48 1.29 +++ wine/misc/options.c 2001/11/20 20:18:44 @@ -356,8 +356,8 @@ */ int __wine_get_main_args( char ***argv ) { - *argv = app_argv; - return app_argc; + *argv = &app_argv[1]; + return app_argc-1; } (leaving aside __wine_get_wmain_args for the moment) and was able to run some programm that didn't run before. Can anybody help with the right fix? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 4

Linear and segmented memory drifting apart
by Uwe Bonnes 04 Dec '01

04 Dec '01

Hallo, the installer of MS Encarta 99 is a mixture of 16 and 32 bit code. Soemthing seems wrong here: Some 16 bit memory if filled with a string 89497 08483bf8:Call KERNEL.88: LSTRCPY(0x03f7781a,0x03177044 "%CMDLINE%") ret=030f:0687 ds=031f 89498 08483bf8:Ret KERNEL.88: LSTRCPY() retval=0x03f7781a ret=030f:0687 ds=031f A 32 bit handle to that memory is aquired: 89503 08483bf8:Call KERNEL.516: GETVDMPOINTER32W(0x03f7781a,0x0001) ret=030f:ae4a ds=031f 89504 08483bf8:Ret KERNEL.516: GETVDMPOINTER32W() retval=0x40498d2e ret=030f:ae4a ds=031f Access to the 32 bit view of that memory goes astray 113220 08483bf8:Call kernel32.lstrcmpA(40498d2e "\021\021\021\021\021\021\021\021...1 113221 08483bf8:Ret kernel32.lstrcmpA() retval=ffffffff ret=10001464 But the 16 bit view still gives the right result: 113785 08483bf8:Call KERNEL.90: LSTRLEN(0x03f7781a "%CMDLINE%") ret=030f:a525 ds=031f 113786 08483bf8:Ret KERNEL.90: LSTRLEN() retval=0x0009 ret=030f:a525 ds=031f Trying to debug a little, I looked at the 32 bit view and it's content is right right after the GETVDMPOINTER32W call. If I debugged right, the content of *0x40498d2e seemed to change inside the application code and not in a wine function. But why at all gives the lstrlen call in line 113785 still the right result? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

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