- 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

[RFC] Async I/O patch: server code + ReadFileEx()
by Martin Wilck 04 Dec '01

04 Dec '01

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. As an example, I recoded ReadFileEx() to use the new approach. Basic testing with disk file I/O works as expected. The code no longer messes up the order of requests. Please have a look at this code and tell me if you consider it a reasonable basis for further development. The patch is against today's (04/12/2001) CVS version. Regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy diff -ruN -X diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Mon Dec 3 13:08:10 2001 +++ MW/wine/files/file.c Tue Dec 4 22:10:16 2001 @@ -57,6 +57,19 @@ static HANDLE dos_handles[DOS_TABLE_SIZE]; +typedef struct file_async_request { + int fd; + HANDLE request_handle; + LPOVERLAPPED ovl; + LPOVERLAPPED_COMPLETION_ROUTINE completion_func; + LPVOID buffer; + unsigned int count; + mode_t flags; +} file_async_request; + +/* A trick to avoid clash with S_IFMT */ +#define _FILE_ASYNC_CANSEEK S_IXOTH +#define FILE_ASYNC_CANSEEK(as_req) ((as_req)->flags & _FILE_ASYNC_CANSEEK) /*********************************************************************** * FILE_ConvertOFMode @@ -1256,6 +1269,231 @@ return FALSE; } +static void FILE_AsyncIoFinish (struct file_async_request* as) +{ + LPOVERLAPPED ovl = as->ovl; + + NtSetEvent (ovl->hEvent, NULL); + + /* This will dequeue the request in the server */ + CloseHandle (as->request_handle); + close (as->fd); + + HeapFree (GetProcessHeap(), 0, as); + SetLastError (ovl->Internal); /* FIXME: correct ?? */ +} + +/*********************************************************************** + * FILE_AsyncIoFinish (INTERNAL) + * + */ +static void CALLBACK FILE_AsyncIoCallCompletion (ULONG_PTR data) +{ + struct file_async_request *as = (struct file_async_request*) data; + LPOVERLAPPED ovl = as->ovl; + + TRACE ("as %p, ovl %p, func %p, status %lx, transferred %ld\n", + as, ovl, as->completion_func, ovl->Internal, ovl->InternalHigh); + + as->completion_func (ovl->Internal, ovl->InternalHigh, ovl); + + FILE_AsyncIoFinish (as); + +} + +/*********************************************************************** + * FILE_ReadFile_APC (INTERNAL) + * + */ +static void FILE_ReadFile_APC (struct file_async_request *as, int events) +{ + int r; + int already; + LPOVERLAPPED ovl = as->ovl; + + TRACE ("events: %x, request: %p\n", events, as); + + if (ovl->Internal != STATUS_PENDING) + { + ERR ("status is %lx, should be %x\n", ovl->Internal, STATUS_PENDING); + r = STATUS_UNSUCCESSFUL; + goto apc_end; + } + + if (events & (POLLHUP | POLLERR | POLLNVAL)) + { + TRACE ("poll error condition for fd %d in async request %p\n", as->fd, as); + r = STATUS_UNSUCCESSFUL; + goto apc_end; + } + + if (!events) + { + TRACE ("read timed out\n"); + r = STATUS_TIMEOUT; + goto apc_end; + } + + already = ovl->InternalHigh; + + if (FILE_ASYNC_CANSEEK (as)) + { + off_t ofs = already + ovl->Offset + ((off_t) ovl->OffsetHigh << 32); + r = pread (as->fd, as->buffer + already, as->count - already, ofs); + } + else + r = read (as->fd, as->buffer + already, as->count - already); + + if (r < 0) + { + int err = errno; + TRACE ("read returned errno %d\n", err); + r = (err == EAGAIN || err == EINTR ? STATUS_PENDING : STATUS_UNSUCCESSFUL); + goto apc_end; + } + + else if (!r) + { + r = STATUS_END_OF_FILE; + goto apc_end; + } + + TRACE ("read %d bytes, cumul: %d, requested: %d\n", r, already + r, as->count); + ovl->InternalHigh += r; + + /* FIXME: is this correct behaviour ? */ + /* If less then count (but > 0) bytes were read, we return success for FIFOs */ + /* For regular files, this should only happen at EOF */ + + if (ovl->InternalHigh >= as->count || !S_ISREG (as->flags)) + r = STATUS_SUCCESS; + else + r = STATUS_END_OF_FILE; + +apc_end: + + ovl->Internal = r; + + if (r == STATUS_PENDING) + { + + TRACE ("rescheduling request\n"); + SERVER_START_REQ (requeue_async_request) + { + req->handle = as->request_handle; + r = wine_server_call_err (req); + } + SERVER_END_REQ; + + if (r) + ovl->Internal = RtlNtStatusToDosError (r); + else + return; + } + + TRACE ("request finished, status: %x\n", r); + + if (as->completion_func) + QueueUserAPC (FILE_AsyncIoCallCompletion, GetCurrentThread(), (ULONG_PTR) as); + else + FILE_AsyncIoFinish (as); +} + +/*********************************************************************** + * FILE_ReadFileEx (INTERNAL) + */ +static BOOL FILE_ReadFileEx (HANDLE hFile, LPVOID buffer, DWORD bytesToRead, + LPOVERLAPPED overlapped, + LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) +{ + struct file_async_request *as; + int fd, r, err; + struct stat st; + + TRACE ("file %d to buf %p num %ld %p func %p\n", + hFile, buffer, bytesToRead, overlapped, lpCompletionRoutine); + + /* check that there is an overlapped struct with an event flag */ + if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) + { + TRACE ("Overlapped not specified or invalid event flag\n"); + err = ERROR_INVALID_PARAMETER; + goto out_err; + } + + fd = FILE_GetUnixHandle( hFile, GENERIC_READ ); + if(fd < 0) + { + TRACE ("Cannot get fd\n"); + err = ERROR_INVALID_HANDLE; + goto out_err; + } + + as = (struct file_async_request*) + HeapAlloc (GetProcessHeap(), 0, sizeof (struct file_async_request)); + + if(!as) + { + TRACE ("HeapAlloc Failed\n"); + err = ERROR_NOT_ENOUGH_MEMORY; + goto out_close; + } + + overlapped->InternalHigh = 0; + overlapped->Internal = STATUS_PENDING; + + as->fd = fd; + as->ovl = overlapped; + as->completion_func = lpCompletionRoutine; + as->buffer = buffer; + + if (fstat (fd, &st) == -1) + { + TRACE ("cannot fstat fd %d\n", fd); + err = ERROR_FILE_INVALID; + goto out_free; + } + + as->flags = st.st_mode & S_IFMT; + if (lseek (fd, 0, SEEK_CUR) != -1) + as->flags |= _FILE_ASYNC_CANSEEK; + + SERVER_START_REQ (create_async_request) + { + req->type = ASYNC_TYPE_READ; + req->io_handle = hFile; + req->count = as->count = bytesToRead; + req->func = FILE_ReadFile_APC; + req->data = as; + r = wine_server_call_err (req); + if (!r) + as->request_handle = reply->handle; + } + SERVER_END_REQ; + + if (r) + { + TRACE ("Couldn't create request: %lx\n", GetLastError()); + err = RtlNtStatusToDosError (r); + goto out_free; + } + + TRACE ("success\n"); + return TRUE; + +out_free: + HeapFree (GetProcessHeap(), 0, as); + +out_close: + close (fd); + +out_err: + SetLastError (err); + return FALSE; + +} + + /*********************************************************************** * FILE_AsyncReadService (INTERNAL) * @@ -1354,7 +1592,7 @@ /*********************************************************************** * FILE_ReadFileEx (INTERNAL) */ -static BOOL FILE_ReadFileEx(HANDLE hFile, LPVOID buffer, DWORD bytesToRead, +static BOOL FILE_ReadFileExOLD(HANDLE hFile, LPVOID buffer, DWORD bytesToRead, LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { @@ -1456,27 +1694,32 @@ } /* see if we can read some data already (this shouldn't block) */ - result = read( unix_handle, buffer, bytesToRead ); - close(unix_handle); - if(result<0) - { - FILE_SetDosError(); - return FALSE; - } +/* !! MW: commented out immediate reading for testing purposes (test overlapped IO) !! */ + + result = 0; + +/* result = read( unix_handle, buffer, bytesToRead ); */ +/* close(unix_handle); */ + +/* if(result<0) */ +/* { */ +/* FILE_SetDosError(); */ +/* return FALSE; */ +/* } */ /* if we read enough to keep the app happy, then return now */ - if(result>=bytesToRead) - { - *bytesRead = result; - return TRUE; - } +/* if(result>=bytesToRead) */ +/* { */ +/* *bytesRead = result; */ +/* return TRUE; */ +/* } */ /* at last resort, do an overlapped read */ overlapped->Internal = STATUS_PENDING; overlapped->InternalHigh = result; - if(!FILE_ReadFileEx(hFile, buffer, bytesToRead, overlapped, NULL)) + if(!FILE_ReadFileEx (hFile, buffer, bytesToRead, overlapped, NULL)) return FALSE; /* fail on return, with ERROR_IO_PENDING */ diff -ruN -X diffignore CVS/wine/server/async.c MW/wine/server/async.c --- CVS/wine/server/async.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/async.c Tue Dec 4 22:05:19 2001 @@ -3,20 +3,477 @@ * * Copyright (C) 1998 Alexandre Julliard * Copyright (C) 2000 Mike McCormack + * Copyright (C) 2001 Martin Wilck * */ #include "config.h" #include <assert.h> +#include <stdio.h> #include <string.h> #include <stdlib.h> #include <unistd.h> +#include <sys/poll.h> #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" +/* This is a wine server object only because we need a client handle for later reference */ +struct async_request +{ + struct object obj; + struct async_request *next; /* Linked list of requests */ + struct async_request *prev; + struct thread *thread; /* Thread or process that issued this request */ + struct object *io_obj; /* The object that represents the IO in the server */ + unsigned int events; /* Events this request is interested in */ + unsigned int flags; /* Request type, misc flags */ + struct timeout_user *timeout; /* For timeout requests */ + struct timeval tv; /* Time at which request times out */ + int count; /* Number of bytes to transfer, needed for setup */ + int result; /* Async IO result - FIXME: do we need this ? */ + async_io_handler_t func; /* Client handler function */ + void *data; /* Client handler data */ +}; + +static void async_request_dump (struct object *, int); +static void async_request_destroy (struct object *obj ); +static const struct object_ops async_request_ops = +{ + sizeof (struct async_request), /* size */ + async_request_dump, /* dump */ + no_add_queue, /* add_queue */ + NULL, /* remove_queue */ + NULL, /* signaled */ + NULL, /* satisfied */ + NULL, /* get_poll_events */ + NULL, /* poll_event */ + no_get_fd, /* get_fd */ + no_flush, /* flush */ + no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ + async_request_destroy /* destroy */ +}; + +static void +async_request_dump (struct object *obj, int verbose) +{ + struct async_request *r = (struct async_request*) obj; + + assert (obj->ops == &async_request_ops); + + fprintf (stderr, "async_request: io_obj: %p events: %x, flags: %x\n", + r->io_obj, r->events, r->flags); + if (!verbose) + return; + fprintf (stderr, " %s" + " func: %p, data: %p\n", + (r->timeout ? "with timeout\n" : ""), + r->func, r->data); +} + +struct async* +alloc_async (struct object *obj) +{ + struct async *async = NULL; + async = mem_alloc (sizeof (struct async)); + if (async) { + async->readers = async->writers = async->others = NULL; + async->flags = 0U; + async->wait.obj = obj; + async->poll_event = async_poll_event_1; + async->get_poll_events = async_get_poll_events_1; + async->setup_request = async_setup_request; + } + return async; +} + +static inline struct async_request** +get_async_queue (struct async* async, struct async_request* request) +{ + switch (ASYNC_REQUEST_TYPE (request)) + { + case ASYNC_TYPE_READ: + return &async->readers; + case ASYNC_TYPE_WRITE: + return &async->writers; + default: + return &async->others; + } +} + +static void +queue_async_request (struct object *obj, struct async* async, struct async_request* req) +{ + struct async_request **queue = get_async_queue (async, req); + int must_add = (! (async->readers || async->writers || async->others)); + + if (!(*queue)) + *queue = req->prev = req->next = req; + else + { + struct async_request *last = (*queue)->prev; + last->next = req; + req->next = *queue; + req->prev = last; + (*queue)->prev = req; + } + + if (must_add) + obj->ops->add_queue (obj, &async->wait); +} + +static void +dequeue_async_request (struct object* obj, struct async_request* req) +{ + struct async *async; + struct async_request **queue; + + obj->ops->get_async (obj, &async); + + if (!async) + { + fprintf (stderr, "dequeue_async_request: invalid IO object\n"); + goto do_req; + } + + queue = get_async_queue (async, req); + + if (!(*queue)) + { + fprintf (stderr, "dequeue_async_request: no queue\n"); + goto do_req; + } + + if (!(req->next && req->prev)) + { + fprintf (stderr, "dequeue_async_request: request isn't queued\n"); + goto do_req; + } + + if (req->next == req) /* One-element-list */ + { + if (*queue == req) + { + *queue = NULL; + + /* remove the IO object from poll wait queue if all request queues are empty */ + if (! (async->readers || async->writers || async->others)) + obj->ops->remove_queue (obj, &async->wait); + } + else /* One element lists must be queue heads */ + { + fprintf (stderr, "dequeue_async_request: invalid request\n"); + goto do_req; + } + } + else + { + req->next->prev = req->prev; + req->prev->next = req->next; + if (*queue == req) + *queue = req->next; + } + + /* The event set may have changed after we removed this request */ + set_select_events (obj, obj->ops->get_poll_events (obj)); + +do_req: + /* After handling the queues, carry out the necessary steps for this request */ + + if (req->timeout) + { + remove_timeout_user (req->timeout); + req->timeout = NULL; + } + + req->next = req->prev = NULL; + return; +} + +static void +async_request_destroy (struct object *obj ) +{ + struct async_request *r = (struct async_request*) obj; + struct object *io; + + assert (obj->ops == &async_request_ops); + + io = r->io_obj; + grab_object (io); + dequeue_async_request (io, r); + release_object (io); +} + +static inline int +queue_async_apc (struct async_request *request, int event) +{ + if (ASYNC_REQUEST_APC_QUEUED (request)) + return 0; + + request->flags |= _ASYNC_REQUEST_APC_QUEUED; + + if (request->timeout) /* Not a timeout */ + { + remove_timeout_user (request->timeout); + request->timeout = NULL; + } + + thread_queue_apc (request->thread, + NULL, /* no owner - don't dequeue other APCs */ + request->func, + APC_ASYNC, + 1, /* use system queue */ + 2, /* number of arguments */ + request->data, /* client data */ + event); + return 1; +} + +static void +async_timeout (void* private) +{ + struct async_request *r = (struct async_request*) private; + r->timeout = NULL; + queue_async_apc (r, 0); +} + +static void +async_queue_all (struct async_request* queue, int event) +{ + struct async_request* r; + + if (!queue) + return; + + r = queue; + + queue_async_apc (r, event); + for (r = r->next; r != queue; r = r->next) + queue_async_apc (r, event); +} + +static void +async_queue_all_matching (struct async_request* queue, int event) +{ + struct async_request* r; + + if (!queue) + return; + + r = queue; + if (r->events & event) + queue_async_apc (r, event); + for (r = r->next; r != queue; r = r->next) + if (r->events & event) + queue_async_apc (r, event); +} + +/* This function never dequeues anything. Requests are only + taken off the queue(s) if the client side signals they have finished. */ +/* This variant queues only the first reader / writer. */ +/* Other variations may follow that queue more than a single request at a time + for objects that support it. */ +/* Note that objects that implement async IO may use their own function instead, + which should provide similar functionality . */ +void +async_poll_event_1 (struct object* obj, int event) +{ + struct async *async; + struct async_request *request; + obj->ops->get_async (obj, &async); + + if (!async) + { + fprintf (stderr, "aync_poll_event: invalid object\n"); + return; + } + + if ((request = async->readers) && (event & POLLIN) && queue_async_apc (request, event)) + event &= ~POLLIN; /* FIXME: is this correct ? */ + + if ((request = async->writers) && (event & POLLOUT) && queue_async_apc (request, event)) + event &= ~POLLOUT; /* FIXME: is this correct ? */ + + async_queue_all_matching (async->others, event); + + /* Queue everything unconditionally if we got errors - client side must cancel the requests */ + if (event & (POLLHUP | POLLERR | POLLNVAL)) + { + async_queue_all (async->readers, event); + async_queue_all (async->writers, event); + async_queue_all (async->others, event); + } + + /* re-check the event list we listen to */ + set_select_events (obj, obj->ops->get_poll_events (obj)); + return; +} + +/* Requests that are already queued do not take part in polling anymore */ +/* This variant assumes only one reader / writer can receive events */ +/* Note that objects that implement async IO may use their own function instead, + which should provide similar functionality . */ +int +async_get_poll_events_1 (struct object* obj) +{ + struct async *as = NULL; + int ret = POLLHUP | POLLERR | POLLNVAL; /* catch errors */ + + obj->ops->get_async (obj, &as); + + if (!as) + return -1; + + if (as->readers && !ASYNC_REQUEST_APC_QUEUED(as->readers)) + ret |= POLLIN; + + if (as->writers && !ASYNC_REQUEST_APC_QUEUED(as->writers)) + ret |= POLLOUT; + + if (as->others) + { + struct async_request *r = as->others; + if (!ASYNC_REQUEST_APC_QUEUED(r)) + ret |= r->events; + for (r = r->next; r != as->others; r = r->next) + if (!ASYNC_REQUEST_APC_QUEUED(r)) + ret |= r->events; + } + + return ret; +} + +/* Default (dummy) setup function. Supports only read and write, and disables timeouts. */ +/* This will be overwritten e.g. by the serial port implementation. */ +int +async_setup_request (struct async* async, struct async_request* request) +{ + request->tv.tv_usec = request->tv.tv_sec = 0; + + request->events = 0; + switch (ASYNC_REQUEST_TYPE (request)) + { + case ASYNC_TYPE_READ: + request->events |= POLLIN; + break; + case ASYNC_TYPE_WRITE: + request->events |= POLLOUT; + break; + default: + fprintf (stderr, "async_setup_request: unsupported request type\n"); + return -1; + }; + return 0; +} + +static struct async_request* +alloc_async_request (struct object *obj) +{ + struct async_request* r = NULL; + r = alloc_object (&async_request_ops, -1); + if (r) + { + r->io_obj = obj; + r->thread = current; + r->prev = r->next = NULL; + r->timeout = NULL; + r->result = 0; + } + return r; +} + +DECL_HANDLER (create_async_request) +{ + struct object *obj; + struct async *async; + struct async_request *request; + int err = STATUS_INVALID_HANDLE; + + if (!(obj = get_handle_obj( current->process, req->io_handle, 0, NULL ))) + goto out; + + if ((err = obj->ops->get_async (obj, &async)) != STATUS_SUCCESS) + goto error; + + request = alloc_async_request (obj); + + if (!request) + { + err = STATUS_NO_MEMORY; + goto error; + } + + /* FIXME: flags other than type ? */ + request->flags = req->type & (~_ASYNC_REQUEST_APC_QUEUED & ASYNC_REQUEST_TYPE_MASK); + request->count = req->count; + request->func = req->func; + request->data = req->data; + + if (async->setup_request (async, request) < 0) + { + err = STATUS_UNSUCCESSFUL; + goto free; + } + + if (ASYNC_USES_TIMEOUT (async)) + request->timeout = add_timeout_user (&request->tv, async_timeout, request); + + queue_async_request (obj, async, request); + + reply->handle = alloc_handle (current->process, request, GENERIC_READ|GENERIC_WRITE, 0); + set_error (STATUS_SUCCESS); /* FIXME - is that necessary ?? */ + + release_object (request); + release_object (obj); /* FIXME: should we skip this release_object to prevent + the io-object to be freed while there are async requests around, + or should the destroy routine of the object handle that ?? */ + + return; + +free: + release_object (request); + +error: + release_object (obj); + +out: + reply->handle = 0; + set_error (err); + return; +} + +/* This is called when an APC does not finish */ +DECL_HANDLER(requeue_async_request) +{ + struct async_request *request; + int err = STATUS_INVALID_HANDLE; + struct object *io; + + if (!(request = (struct async_request*) get_handle_obj (current->process, req->handle, 0, NULL)) + || request->obj.ops != &async_request_ops + || !ASYNC_REQUEST_APC_QUEUED (request)) + goto out; + + io = request->io_obj; + grab_object (io); + + request->flags &= ~_ASYNC_REQUEST_APC_QUEUED; + set_select_events (io, io->ops->get_poll_events (io)); + + release_object (io); + err = STATUS_SUCCESS; + +out: + set_error (err); + return; +} + + +/* The current CVS code, in order not to break Wine */ DECL_HANDLER(create_async) { @@ -32,3 +489,4 @@ release_object(obj); } + diff -ruN -X diffignore CVS/wine/server/async.h MW/wine/server/async.h --- CVS/wine/server/async.h Thu Jan 1 01:00:00 1970 +++ MW/wine/server/async.h Tue Dec 4 16:19:54 2001 @@ -0,0 +1,48 @@ +/* + * Wine server async I/O support + * + * Copyright (C) 2001 Martin Wilck + */ + +#ifndef __WINE_SERVER_ASYNC_H +#define __WINE_SERVER_ASYNC_H + +#include "object.h" + +#define _ASYNC_USES_TIMEOUT 0x01U +#define ASYNC_USES_TIMEOUT(async) ((async)->flags & _ASYNC_USES_TIMEOUT) + +#define ASYNC_REQUEST_TYPE_MASK 0xffU +#define ASYNC_REQUEST_TYPE(req) ((req)->flags & ASYNC_REQUEST_TYPE_MASK) +#define _ASYNC_REQUEST_APC_QUEUED 0x100U +#define ASYNC_REQUEST_APC_QUEUED(req) ((req)->flags & _ASYNC_REQUEST_APC_QUEUED) + +struct async_request; +typedef int (*async_get_poll_events_t) (struct object*); +typedef void (*async_poll_event_t) (struct object*, int); +typedef int (*async_setup_request_t) (struct async*, struct async_request*); +typedef void (*async_io_handler_t) (void*, int); + +/* This struct contains information about async IO features + of a given I/O object (file, comm port, socket ...) */ +struct async +{ + struct async_request *readers; /* List of read requests */ + struct async_request *writers; /* List of write requests */ + struct async_request *others; /* List of requests that dont't read or write */ + unsigned int flags; /* Misc flags */ + struct wait_queue_entry wait; /* wait queue entry */ + async_poll_event_t poll_event; /* Function: react on poll event */ + async_get_poll_events_t get_poll_events; /* Function: get events to react on */ + async_setup_request_t setup_request; /* Function: Setup an event (timeout, events) at queue time */ +}; + +/* Default handlers, can be overwritten */ +int async_get_poll_events_1 (struct object*); +void async_poll_event_1 (struct object*, int); +int async_setup_request (struct async*, struct async_request*); + +/* Utility functions */ +struct async* alloc_async (struct object*); + +#endif /* #ifndef __WINE_SERVER_ASYNC_H */ diff -ruN -X diffignore CVS/wine/server/atom.c MW/wine/server/atom.c --- CVS/wine/server/atom.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/atom.c Mon Dec 3 13:09:03 2001 @@ -59,6 +59,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ atom_table_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/change.c MW/wine/server/change.c --- CVS/wine/server/change.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/change.c Mon Dec 3 13:09:03 2001 @@ -37,6 +37,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/console.c MW/wine/server/console.c --- CVS/wine/server/console.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/console.c Mon Dec 3 13:43:50 2001 @@ -40,6 +40,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ console_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ console_input_destroy /* destroy */ }; @@ -68,6 +69,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ console_input_events_destroy /* destroy */ }; @@ -108,6 +110,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ console_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ screen_buffer_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/debugger.c MW/wine/server/debugger.c --- CVS/wine/server/debugger.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/debugger.c Mon Dec 3 13:09:04 2001 @@ -58,6 +58,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ debug_event_destroy /* destroy */ }; @@ -78,6 +79,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ debug_ctx_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/device.c MW/wine/server/device.c --- CVS/wine/server/device.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/device.c Mon Dec 3 13:09:04 2001 @@ -44,6 +44,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ device_get_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/event.c MW/wine/server/event.c --- CVS/wine/server/event.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/event.c Mon Dec 3 13:09:04 2001 @@ -38,6 +38,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/file.c Tue Dec 4 17:57:22 2001 @@ -29,6 +29,7 @@ #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" struct file { @@ -39,6 +40,7 @@ unsigned int flags; /* flags (FILE_FLAG_*) */ unsigned int sharing; /* file sharing mode */ int drive_type; /* type of drive the file is on */ + struct async *async; /* Control structure for async IO */ }; #define NAME_HASH_SIZE 37 @@ -47,10 +49,12 @@ static void file_dump( struct object *obj, int verbose ); static int file_get_poll_events( struct object *obj ); +static void file_poll_event(struct object *,int); static int file_get_fd( struct object *obj ); static int file_flush( struct object *obj ); static int file_get_info( struct object *obj, struct get_file_info_reply *reply ); static void file_destroy( struct object *obj ); +static int file_get_async(struct object *,struct async **); static const struct object_ops file_ops = { @@ -61,10 +65,11 @@ default_poll_signaled, /* signaled */ no_satisfied, /* satisfied */ file_get_poll_events, /* get_poll_events */ - default_poll_event, /* poll_event */ + file_poll_event, /* poll_event */ file_get_fd, /* get_fd */ file_flush, /* flush */ file_get_info, /* get_file_info */ + file_get_async, /* get_async */ file_destroy /* destroy */ }; @@ -115,6 +120,7 @@ file->flags = attrs; file->sharing = sharing; file->drive_type = drive_type; + file->async = NULL; } return file; } @@ -247,11 +253,27 @@ struct file *file = (struct file *)obj; int events = 0; assert( obj->ops == &file_ops ); + + if (file->flags & FILE_FLAG_OVERLAPPED && file->async) + return async_get_poll_events_1 (obj); + if (file->access & GENERIC_READ) events |= POLLIN; if (file->access & GENERIC_WRITE) events |= POLLOUT; return events; } +static void file_poll_event(struct object *obj, int events) +{ + struct file *file = (struct file *)obj; + assert( obj->ops == &file_ops ); + + if (file->flags & FILE_FLAG_OVERLAPPED && file->async) + /* FIXME: Could we have non-async requests waiting for input also ? */ + async_poll_event_1 (obj, events); + else + default_poll_event (obj, events); +} + static int file_get_fd( struct object *obj ) { struct file *file = (struct file *)obj; @@ -307,7 +329,23 @@ reply->index_low = st.st_ino; reply->serial = 0; /* FIXME */ } + + if (file->flags & FILE_FLAG_OVERLAPPED) + return FD_TYPE_OVERLAPPED; + return FD_TYPE_DEFAULT; +} + +static int file_get_async(struct object *obj,struct async **pasync) +{ + struct file *file = (struct file *)obj; + assert (obj->ops == &file_ops); + if (!file->async) + { + file->async = alloc_async (obj); + } + *pasync = file->async; + return (file->async ? 0 : STATUS_NO_MEMORY); } static void file_destroy( struct object *obj ) diff -ruN -X diffignore CVS/wine/server/handle.c MW/wine/server/handle.c --- CVS/wine/server/handle.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/handle.c Mon Dec 3 13:09:04 2001 @@ -92,6 +92,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ handle_table_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/mapping.c MW/wine/server/mapping.c --- CVS/wine/server/mapping.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/mapping.c Mon Dec 3 13:09:04 2001 @@ -51,6 +51,7 @@ mapping_get_fd, /* get_fd */ no_flush, /* flush */ mapping_get_info, /* get_file_info */ + no_get_async, /* get_async */ mapping_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/mutex.c MW/wine/server/mutex.c --- CVS/wine/server/mutex.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/mutex.c Mon Dec 3 13:09:04 2001 @@ -42,6 +42,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ mutex_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/named_pipe.c MW/wine/server/named_pipe.c --- CVS/wine/server/named_pipe.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/named_pipe.c Mon Dec 3 13:09:04 2001 @@ -80,6 +80,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ named_pipe_destroy /* destroy */ }; @@ -101,6 +102,7 @@ pipe_user_get_fd, /* get_fd */ no_flush, /* flush */ pipe_user_get_info, /* get_file_info */ + no_get_async, /* get_async */ pipe_user_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/object.c MW/wine/server/object.c --- CVS/wine/server/object.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/object.c Mon Dec 3 13:09:04 2001 @@ -269,6 +269,13 @@ return FD_TYPE_INVALID; } +int no_get_async(struct object *obj,struct async **as) +{ + if (as) + *as = NULL; + return STATUS_OBJECT_TYPE_MISMATCH; +} + void no_destroy( struct object *obj ) { } diff -ruN -X diffignore CVS/wine/server/object.h MW/wine/server/object.h --- CVS/wine/server/object.h Mon Dec 3 13:08:11 2001 +++ MW/wine/server/object.h Mon Dec 3 13:16:09 2001 @@ -48,6 +48,8 @@ int (*flush)(struct object *); /* get file information */ int (*get_file_info)(struct object *,struct get_file_info_reply *); + /* fill in object-type specific async information */ + int (*get_async)(struct object *,struct async **); /* destroy on refcount == 0 */ void (*destroy)(struct object *); }; @@ -90,6 +92,7 @@ extern int no_get_fd( struct object *obj ); extern int no_flush( struct object *obj ); extern int no_get_file_info( struct object *obj, struct get_file_info_reply *info ); +extern int no_get_async(struct object *,struct async **); extern void no_destroy( struct object *obj ); extern int default_poll_add_queue( struct object *obj, struct wait_queue_entry *entry ); extern void default_poll_remove_queue( struct object *obj, struct wait_queue_entry *entry ); diff -ruN -X diffignore CVS/wine/server/pipe.c MW/wine/server/pipe.c --- CVS/wine/server/pipe.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/pipe.c Mon Dec 3 13:09:04 2001 @@ -53,6 +53,7 @@ pipe_get_fd, /* get_fd */ no_flush, /* flush */ pipe_get_info, /* get_file_info */ + no_get_async, /* get_async */ pipe_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/process.c MW/wine/server/process.c --- CVS/wine/server/process.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/process.c Mon Dec 3 13:09:06 2001 @@ -53,6 +53,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ process_destroy /* destroy */ }; @@ -92,6 +93,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ startup_info_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Mon Dec 3 13:08:11 2001 +++ MW/wine/server/protocol.def Tue Dec 4 13:54:13 2001 @@ -1541,6 +1541,21 @@ #define ASYNC_TYPE_WRITE 0x02 #define ASYNC_TYPE_WAIT 0x03 +/* Schedule an ansync I/O request */ +@REQ(create_async_request) + handle_t io_handle; /* Handle to IO object that is capable of async IO */ + unsigned int type; /* READ / WRITE / WAIT */ + int count; /* Number of bytes to transfer, -1 if unknown */ + void* func; /* IO handler function */ + void* data; /* pointer to arbitrary data object, handled by func */ +@REPLY + handle_t handle; /* handle to request object for later use */ +@END + +/* Reschedule an unfinished async I/O request */ +@REQ(requeue_async_request) + handle_t handle; /* handle to the request object to be rescheduled */ +@END /* Create a named pipe */ @REQ(create_named_pipe) diff -ruN -X diffignore CVS/wine/server/queue.c MW/wine/server/queue.c --- CVS/wine/server/queue.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/queue.c Mon Dec 3 13:09:08 2001 @@ -112,6 +112,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ msg_queue_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/registry.c MW/wine/server/registry.c --- CVS/wine/server/registry.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/registry.c Mon Dec 3 13:09:09 2001 @@ -142,6 +142,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ key_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/request.c MW/wine/server/request.c --- CVS/wine/server/request.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/request.c Mon Dec 3 13:09:09 2001 @@ -66,6 +66,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ master_socket_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/request.h MW/wine/server/request.h --- CVS/wine/server/request.h Mon Dec 3 13:08:11 2001 +++ MW/wine/server/request.h Tue Dec 4 16:20:02 2001 @@ -210,6 +210,8 @@ DECL_HANDLER(get_serial_info); DECL_HANDLER(set_serial_info); DECL_HANDLER(create_async); +DECL_HANDLER(create_async_request); +DECL_HANDLER(requeue_async_request); DECL_HANDLER(create_named_pipe); DECL_HANDLER(open_named_pipe); DECL_HANDLER(connect_named_pipe); @@ -364,6 +366,8 @@ (req_handler)req_get_serial_info, (req_handler)req_set_serial_info, (req_handler)req_create_async, + (req_handler)req_create_async_request, + (req_handler)req_requeue_async_request, (req_handler)req_create_named_pipe, (req_handler)req_open_named_pipe, (req_handler)req_connect_named_pipe, diff -ruN -X diffignore CVS/wine/server/semaphore.c MW/wine/server/semaphore.c --- CVS/wine/server/semaphore.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/semaphore.c Mon Dec 3 13:09:09 2001 @@ -38,6 +38,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/serial.c MW/wine/server/serial.c --- CVS/wine/server/serial.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/serial.c Mon Dec 3 13:09:09 2001 @@ -74,6 +74,7 @@ serial_get_fd, /* get_fd */ no_flush, /* flush */ serial_get_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/snapshot.c MW/wine/server/snapshot.c --- CVS/wine/server/snapshot.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/snapshot.c Mon Dec 3 13:09:09 2001 @@ -50,6 +50,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ snapshot_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/sock.c MW/wine/server/sock.c --- CVS/wine/server/sock.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/sock.c Mon Dec 3 13:09:09 2001 @@ -77,6 +77,7 @@ sock_get_fd, /* get_fd */ no_flush, /* flush */ sock_get_info, /* get_file_info */ + no_get_async, /* get_async */ sock_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/thread.c MW/wine/server/thread.c --- CVS/wine/server/thread.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/thread.c Mon Dec 3 13:09:09 2001 @@ -76,6 +76,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ destroy_thread /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/timer.c MW/wine/server/timer.c --- CVS/wine/server/timer.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/timer.c Mon Dec 3 13:09:09 2001 @@ -45,6 +45,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ timer_destroy /* destroy */ };

1 0

thread safing dlls
by Michael Zayats 04 Dec '01

04 Dec '01

this might be off topic, but let's try: I have a dll that is not thread safe (i.e. has many global variables, about 500). I have the sources for the dll. The target is to make it thread safe. Moving all the variables to thread specific storage is very complicated. Making it thread safe on ansi C level is very, very complicated too. I guess that you thoroughly deal with PE format. Is there a way to play with executable sections, such that every thread will use it's own copy of the data? I know one guy, that claimed that he has achieved this with 20 lines of code by directly modifying smth in executable, he doesn't want to tell me what he has done :( I also heard of __attribute((section... in gcc that should do the work (I am generally talking about windoze platform only), can you explain me what does it do in gcc? thank you in advance, Michael Zayats

2 1

Re:[PATCH] Horrid wineoss hack
by Eric Pouech 03 Dec '01

03 Dec '01

this is not the correct fix. there are several problems in the OSS driver (at least I know 3 of them, but didn't have time to fix them all yet in a proper way) this is not correct either (it's just a workaround) A+ > I have found that since a few weeks my Eudora was hanging > with current Cvs when I tried to get a new message off the server. > This occurred exactly when it was trying to play a sound to > warn about the new message. > > I have found that playing any sound using PlaySound is > triggering the new problem. On my older computer, the problem > just does not exist. After investigation, the older computer has a > true sound card (a sound blaster) while the new has just a Via > chip on the mother board (via82cxx_audio) > > This is the reason : the Via wineoss driver seems to be buggy, > when a sound is finished, the available space never goes back > to the total available. > > This problem did not happen with versions of audio.c < 1.45, > where the Wine code has been made to rely on this feature. > > ChangeLog: > > * dlls/winmm/wineoss/audio.c > Works around a bug in Via wineoss driver > > --------------- 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.

1 0

Re: Win XP installation support?
by Hetz Ben-Hamo 03 Dec '01

03 Dec '01

Yes, that helps, could you commit it to the CVS please? Thanks, Hetz On Monday 03 December 2001 19:27 pm, you wrote: > At 05:57 PM 03/12/2001 +0200, you wrote: > >It doesn't patches currectly, got rejection (which is enclosed). > > Try with -l option > > Gerard

1 0

Re: Proposed solution for mouse capture problems
by Alexandre Julliard 03 Dec '01

03 Dec '01

Jukka Heinonen <jhei(a)iki.fi> writes: > 1. Function process_raw_mouse_message should only determine which > window was under mouse and resend message to that window as > a cooked message. Everything else (especially separating normal > messages from nonclient messages and handling mouse captures) > should be moved to process_cooked_mouse_message. Actually, > I fail to see why raw messages are needed at all, since function > SendInput could do this as well. No, processing raw messages requires sending messages to the app (mainly WM_NCHITTEST) and you cannot do this from anywhere. Also if you separate the window determination from the rest you'll have to send two WM_NCHITTEST for every message which is clearly wrong. Maybe what we should do is when the cooked message is rejected by the message filter it should be queued back as a raw message and processed again next time around. > 3. Supporting multi-threaded capture is actually the easiest part, > although it might be quite useless (Does any application really > require it?). When mouse button is pressed in capturing window, > process_cooked_mouse_message sets process-wide flag that states > that global capture is in effect. After that, either > process_raw_mouse_message or SendInput sees that this flag is > set and resends all mouse messages to capturing window until > button release message is received, which clears the flag. I'm not sure what you are trying to fix here. This should already work fine, X takes care of sending messages to the right thread when mouse is captured. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Win XP installation support?
by Gerard Patel 03 Dec '01

03 Dec '01

At 04:47 AM 03/12/2001 +0200, you wrote: >I thought about that too, but it's not - here is the line from my /etc/fstab > >/dev/hda5 /mnt/win vfat defaults 0 0 >/dev/hda3 /mnt/dosc vfat defaults 0 0 > Try to apply the following patch to wineconf : --- wineconf.orig Thu Jun 7 22:25:06 2001 +++ wineconf Mon Dec 3 08:40:42 2001 @@ -146,6 +146,7 @@ my(@FATD)=@::FatDrives; my(@wininis) = (); my ($winini); + my ($ThisDrive); if (!$::opt_windir && !$::opt_fast && !$::opt_thorough) { $::opt_thorough++; @@ -161,8 +162,7 @@ } elsif ($::opt_thorough) { if ($::opt_debug) { print STDERR "DEBUG: Num FATD = ", $#FATD+1, "\n"; } - foreach(@FATD) { - my $ThisDrive = shift(@FATD); + foreach $ThisDrive (@FATD) { my $MntPoint = $ThisDrive->[1]; push(@wininis, `find $MntPoint -iname win.ini -print`); }¨\ Gerard

1 0

Win XP installation support?
by Hetz Ben-Hamo 03 Dec '01

03 Dec '01

Hi, I have installed wine cvs and I have here on this machine Windows XP pro installed.. now - the partition is fat32 and I can access it with /mnt/win without any problem. However, the tools/wineinstall script simply doesn't recognize my windows partition: windows]$ ls -l win* -rwxrwxrwx 1 root root 256192 Aug 23 13:00 winhelp.exe -rwxrwxrwx 1 root root 266752 Aug 23 13:00 winhlp32.exe -rwxrwxrwx 1 root root 504 Dec 1 22:25 win.ini -rwxrwxrwx 1 root root 48680 Aug 23 15:00 winnt256.bmp -rwxrwxrwx 1 root root 48680 Aug 23 15:00 winnt.bmp [hetz@witch windows]$ pwd /mnt/win/windows Now - running tools/wineinstall gives me this: wine]$ tools/wineinstall WINE Installer v0.7 Warning !! wine binary (still) found, which may indicate a (conflicting) previous installation. You might want to abort and uninstall Wine first. I see that WINE has already been configured, so I'll skip that. Hmm, looks like WINE is already compiled. I'll skip that too, I guess. You aren't root, so I'll skip the make install. NOTE! To run Wine without installing, you must set the environment variable LD_LIBRARY_PATH to /home/hetz/wine:/home/hetz/wine/dlls in your logon scripts. Create local config file ~/.wine/config? (yes/no) yes Found existing /home/hetz/.wine/config, if you continue this file will be overwritten. Continue running wineinstall? (yes/no) yes Searching for an existing Windows installation... not found. (no matching /etc/fstab mount entry found) Windows was not found on your system, so I assume you want a Wine-only installation. Am I correct? (yes/no) No, it's not correct. Any suggestions? (sorry if the email doesn't belong to this list) Thanks, -- Hetz Ben Hamo

2 3

Re: Include only needed headers in programs/winhelp
by Francois Gouget 03 Dec '01

03 Dec '01

On Sun, 2 Dec 2001, James Juran wrote: > James Juran <jamesjuran(a)alumni.psu.edu> > Only include the necessary files to avoid conflicts in gethostname > prototypes between winsock.h and unistd.h 'unistd.h' does not exist on Windows. Since this is a Winelib application it would be good to try to make it compile on Windows too. So I would rather be in favor of removing the 'unistd.h' #include directive unless something prevents that. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

2 4

gethostname prototypes [was: Re: wine's winhelp doesn't compile]
by James Juran 02 Dec '01

02 Dec '01

[taken to wine-devel, thread originally started in newsgroup] gerard patel wrote: > > >james[1]%rpm -qf /usr/include/unistd.h > >glibc-devel-2.2.4-19 > > glibc-devel-2.2.2-4mdk > > >james[2]%grep gethostname /usr/include/unistd.h > >extern int gethostname (char *__name, size_t __len) __THROW; > > extern int gethostname (char *__name, socklen_t __len) __THROW; > > ./include/bits/types.h:typedef unsigned int __socklen_t; This could be a problem. According to the glibc CVS, http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/include/unistd.h.diff?r1=…, the type of the 2nd argument changed from int to size_t on 2001/3/21. According to the CVS tags, this change was first released in glibc-2.2.3. We were able to work around this problem in programs/winhelp by not including winsock.h, but could this problem crop up anyplace else? It seems that it is currently impossible to include unistd.h and winsock.h on a machine with glibc >= 2.2.3. -- James Juran jamesjuran(a)alumni.psu.edu

2 1

Re: compatible DC/Bitmap fixes
by Ove Kaaven 02 Dec '01

02 Dec '01

On Sat, 1 Dec 2001, eric pouech wrote: > as Marcus reported, the console was only working in black & white > the cause of the error comes from the following flow > > 1/ GetDC (physical and/or display) > 2/ CreateCompatibleDC (on DC gotten from 1/) > 3/ CreateCompatibleBitmap (on DC gotten from 2/) What you *should* do is to call CreateCompatibleBitmap on the DC you got from GetDC. That's what all the Windows code I know of does. > the trouble is as follows : > - when a mem DC is created, its bits per pixel is always set to 1 Yes, that's documented Windows behaviour. You need to select a bitmap into it to change it. No Windows code expects otherwise.

1 0

DOS issue
by Johan Gill 01 Dec '01

01 Dec '01

Trying Monkey Island 1 & 2 with wine, I get very slow animation and a lot of err:module:DOSVM_Wait dosvm wait error=5. It seems to be wineserver related, so I'd rather not dig too deep without some feedback. There is a brief trace without any special flags at http://www.lysator.liu.se/~johane/monkey2_brief.txt. I ended the execution with Ctrl-C. A trace with +server,+module,+relay is available as http://www.lysator.liu.se/~johane/monkey2_zoom.txt. I've cut everything after the second occurence of the error. /Johan Gill, johane(a)lysator.liu.se

1 0

Re: Access Control Functions
by Mike McCormack 01 Dec '01

01 Dec '01

Hi Karl, > Everything works okay until we get to the access control functions. > advapi32.OpenProcessToken calls ntdll.OpenProcessToken, which is just a > stub. Did you try different -winver flags? it OpenProcessToken shouldn't be used in Win98.... That being said, it would be a very good thing to have a better security framework. Maybe we can even use it to integrate with samba-tng one day. i think you'd be looking to make a "token" object in the server. > I also am having trouble finding documentation on the make_requests tool. Well, run it after modifying server/protocol.def to propagate you changes to server/trace.c and include/wine/server.h. The format of the protocol.def file should be self explanatory... if i remember correctly, there are some small quirks like "void* xxx" works, but "void *xxx" doesn't. Mike ------------------------------------------ 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

Access Control Functions
by Karl Bielefeldt 01 Dec '01

01 Dec '01

I am new to open source development and to the wine project so please forgive me for sounding like a newbie. I think wine is great and the key to the growth of Linux in the desktop market. I decided to begin my efforts by debugging the installation of MS Money 2001 (my wife's must-have MS program) on a completely non-windows box. This led to needing to install the msiexec installer (instmsia.exe, available from MS website). Everything works okay until we get to the access control functions. advapi32.OpenProcessToken calls ntdll.OpenProcessToken, which is just a stub. Now, as far as I can tell, the stubs default to the least restrictive set of permissions, which I believe is fine for our purposes. The problem comes when the program calls kernel32.CloseHandle on the non-existent handle that was returned by the OpenProcessToken stub. Somebody please stop me if there is an easier way of solving this problem. It looks like we at least need to create some sort of dummy handle that can be removed by kernel32.CloseHandle without causing an error. To do this we would need to add an open_process_token request handler to the wineserver (perhaps in a new file server/access.c). Another alternative would be to create an open_dummy_handle request handler in server/handle.c that could be used for any generic dummy handle. The advantage of the first method is that if someone decides to implement all the access control functions properly, the framework is already in place. Probably some combination of the two is best. I am willing to do the coding myself, but I'm unsure of the procedures for open source development. How do you decide what changes are to be made, how do you submit your changes, how do you make sure you don't undo what someone else did, and things like that? I also am having trouble finding documentation on the make_requests tool. Thanks for tolerating my newbieness. I'm looking forward to being able to start contributing to this great project. --Karl Bielefeldt kbielefe(a)hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

3 2

Re: Is there a good reason why we ...
by Alexandre Julliard 30 Nov '01

30 Nov '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > Is there a good reason why we have to specify the full correct path to a dll > in the dll overrides section if it isn't in the windows system? Because you can have multiple versions of the same dll in different directories, and we need a way of distinguishing them. For instance an app may include its own version of shell32 in its private directory, and you want to be able to switch this one to builtin without impacting other apps using the standard shell32. There may be better ways to provide this feature though, suggestions are welcome. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PROBLEM REPORT] Focus problem for mdi children
by Gerard Patel 30 Nov '01

30 Nov '01

At 09:35 PM 29/11/2001 -0800, you wrote: >*Doesn't this fix the problem in Word where if you have multiple >documents open and you switch between them, you can't use the menu bar >any longer?* Sorry, I don't know. I doubt it, since in mdi code it is stated that Word does not use MDI. Of course the comment has been here for a long time and could be obsolete, but I doubt that Ms could have switched Word to use MDI since they have obsoleted MDI since a long time. Gerard

1 0

Re: [PROBLEM REPORT] Focus problem for mdi children
by Michael Cardenas 30 Nov '01

30 Nov '01

*Doesn't this fix the problem in Word where if you have multiple documents open and you switch between them, you can't use the menu bar any longer?* ------------------------------------------------------------------------------- * From:* Alexandre Julliard (/ julliard(a)winehq.com/ <mailto:julliard@winehq.com?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E> ) *Date:* Wed Nov 07 2001 - 19:46:37 EST * ** Gerard Patel <gerard.patel(a)nerim.net <mailto:gerard.patel@nerim.net?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E>> writes: > Using this patch : > --- winpos.c.orig Wed Nov 7 10:41:32 2001 > +++ winpos.c Thu Nov 8 00:44:29 2001 > @@ -955,7 +955,20 @@ > ShowCaret(winpos->hwnd); > } > > - if (!(winpos->flags & SWP_NOACTIVATE)) SetActiveWindow( winpos->hwnd ); > + if (!(winpos->flags & SWP_NOACTIVATE)) > + { > + SetActiveWindow( winpos->hwnd ); > + if (!(wndPtr = WIN_FindWndPtr(winpos->hwnd))) return FALSE; > + > + /* child windows get WM_CHILDACTIVATE message */ > + if( (wndPtr->dwStyle & (WS_CHILD | WS_POPUP)) == WS_CHILD ) > + { > + WIN_ReleaseWndPtr(wndPtr); > + SendMessageA(winpos->hwnd, WM_CHILDACTIVATE, 0, 0L); > + } > + else > + WIN_ReleaseWndPtr(wndPtr); > + } > > /* And last, send the WM_WINDOWPOSCHANGED message */ > > > seems to fix the problem. It may be too simple though :-) No actually it's pretty much the right thing. I have applied a slightly simplified version of your patch, thanks for the report. -- Alexandre Julliard julliard(a)winehq.com <mailto:julliard@winehq.com?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E> -- //------------------------------------------ Michael Cardenas Software Engineer Lindows.com, Inc. http://www.lindows.com 858-410-5950 619-972-8153 //------------------------------------------- --

1 0

Is there a good reason why we ...
by Bill Medland 29 Nov '01

29 Nov '01

I've just tripped over this again which reminded me to ask why we do it. Is there a good reason why we have to specify the full correct path to a dll in the dll overrides section if it isn't in the windows system? A program runs at some location on the path. It uses a dll which is in the same directory. I want explicitly to use a winelib builtin "dll" instead of it. I can't simply say "a4wwine"="builtin"; I have to use the full path. That would cause problems if the exe and dll moved. Is there a good reason for this behaviour? (i.e. would it be a waste of my time changing the dll override stuff?) Bill

1 0

FoxPro 5 Applications
by Rick Romero 29 Nov '01

29 Nov '01

Hello, I've been attempting to get Foxpro 5 applications running for a while now. Actually, I just download from cvs randomly, and see what happens. It's been a while, but I decided to try again in October. At that time, there was an OLE error, but the only other strange occurance was a 'locking' of the screen on a print preview. Since then, this 'locking' is the only issue (though I havn't yet attempted to print). The apps I'm trying are my own, basically just a form is called, the user puts in a date range, and a report is run. You can view the report in the print preview window, close the window, use the scroll button on the mouse to change pages, etc. BUT, if you click on the preview itself, and attempt to scroll down to the bottom of the page, a 'lockup' appears to happen. I've just been waiting around hoping for it to be fixed. Today, for giggles, I decided to run the whole Visual Foxpro development environment. It ran! (BTW, I'm trying to do this all with fake windows, and all I've added is the VFP 5 runtime) BUT, anytime I click in an edit Window, MDI interface, the program acts as if I'm holding the shift key down, and as I move my mouse, all the text gets highlighted. I can't 'turn it off', so if there wasn't any text there, it surely would appear locked. I've changed the config from the fake_windows, to point to my Win2k install, but the behavior is the same. I'm actually getting kind of excited now, because we're a small company, and all we run is Fox5 apps (SBT / Skyline -- well, and a couple Fox2.6 win), and Office 2k. If I can run the development environment in Linux, I can take a real look at using linux desktops, either directly, or via LTSP. I don't get any debug info when the 'shift' occurs, and I'm not sure how to dump enough information to see the 'shift keypress' happen (assuming I could fix the problem myself in a way that doesn't interfere with the programming standards..), can someone point me in the right direction? Thanks for your time. Rick Romero

1 0

Proposed solution for mouse capture problems
by Jukka Heinonen 29 Nov '01

29 Nov '01

Okay, here is my proposal about how to fix broken message handling when mouse capturing is in effect. I would like to get some comments so that I can see that I haven't missed anything essential and because I would like to know whether someone is already working on this... Proposal has three parts, but part number one is the most important one, other two parts just show what would need to be done to make capturing work like described in MSDN documentation. 1. Function process_raw_mouse_message should only determine which window was under mouse and resend message to that window as a cooked message. Everything else (especially separating normal messages from nonclient messages and handling mouse captures) should be moved to process_cooked_mouse_message. Actually, I fail to see why raw messages are needed at all, since function SendInput could do this as well. 2. When requesting queued messages from wineserver, the request should also include the window that is capturing mouse input in the current thread - or this could be stored in the wineserver. If there are queued cooked mouse messages, wineserver considers them as if all child windows of capturing window had the handle of the capturing window. This should prevent problems if application requests messages about a single window. 3. Supporting multi-threaded capture is actually the easiest part, although it might be quite useless (Does any application really require it?). When mouse button is pressed in capturing window, process_cooked_mouse_message sets process-wide flag that states that global capture is in effect. After that, either process_raw_mouse_message or SendInput sees that this flag is set and resends all mouse messages to capturing window until button release message is received, which clears the flag. Function process_cooked_mouse_message needs to eat these messages if target window was not capturing window anymore. Proper locking should make sure that no important messages are lost (mouse move events are not important; we might lose button release event, but only if capture has been stopped manually before that and in that case not delivering button release is likely the best thing to do). -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: [patch] Winsock fixes
by Ove Kaaven 29 Nov '01

29 Nov '01

On Wed, 28 Nov 2001, Paul Rupe wrote: > I have found two bugs in dlls/winsock/socket.c. One I posted about a > few days ago in wine.devel. WS_accept calls WS_getpeername but passes > it the Unix file descriptor rather than the Windows socket handle. A > simple one-line change takes care of that. That's Francois's fault, when he split out the sockaddr_xxx conversions. > The second problem is more subtle, and I'm not sure if my solution is > enough. In WINSOCK_DoAsyncEvent there is a loop that dispatches all > events currently available on the socket. The problem is the order, it > simply calls them in increasing order by FD_xxx values. Since FD_READ > is numerically smaller than FD_CONNECT, a socket that has both events > will fire the read event before the connect. When that happens, the app > gets a read event before it thinks it's connected and ignores it. > Ideally, the loop should post them in the order in which they occurred, > but does wine keep track of that? Instead, I changed the loop so that > it checks FD_CONNECT and FD_CLOSE before FD_READ and FD_WRITE. I'm not > sure if the order I chose is the optimal one, but the app I was testing > (Xnews) works every time now. It'd seem to me that FD_CLOSE should be dispatched last, not first... Anyway, now that Alexandre moved the window message queues away from the wine clients and into the wineserver, these event message dispatches could also be done in the wineserver (where the winsock events are generated), instead of using the service thread callback WINSOCK_DoAsyncEvent. Alexandre wants to phase out the service thread anyway, so he probably won't oppose this. Any volunteers for that?

1 0

New Idea
by Matt Q 29 Nov '01

29 Nov '01

I don't know if this is the right news group for this but what the heck... This is a new idea I had. It strikes me that it would be better if wine some how customised it's self to a single users software/configuration... I'd heard that sometimes when one thing is fixed it sometimes breaks another... This wouldn't be a problem if the thing that would hypothetically get broken wasn't installed on the end users machine... so theoretically if you had some way of sending a patch to an end user which corrected the problem at hand it would be good... so what if every time wine crashed it popped up a window and if the user wished it it would send it's very verbose out put to some kind of a bug reporting system (repository)... and in return search the repository for a patch for this particular problem... (using the verbose output).... there is a chance that the patch might break something else but in that case there is a chance that it might find another patch to fix the whole situation... they have a system like this under M$ Win and netscape except that they rely on periodic updates to take care of the problem... but who is to say that every computer is built the Same and has the Same sofware so that the Same super patch will fix every one's computer... Note 1... If M$ screws anyone on rights to this idea they can claim next logical step kind of like one step shopping... Note 2... Basically the only two weakness of the system would be One the inablility to match the output with a patch... but with a decent database program should that be problem? and Two having enough programers to right mini patches..... I'm writing from memory but I think there are 300 developers.... wouldn't that be enough..... just a thought though so take it with a grain of salt... p.s. what brought this to mind back when I was following the wine project much more closely, 2-3 years ago, when it was almost the only way to run windows programs under linux, I'd heard that many of the problems could be fixed by just a tweak here or there and mabey a few lines of code changed... still don't know much C so I doubt I'll be much help as a developer if you want to get back with me over this : ) ICQ# 135184436 turtleislow

1 0

Re: x11ddraw fix
by Glenn Schrader 28 Nov '01

28 Nov '01

Ove Kaaven wrote: > On Mon, 12 Nov 2001, geschrader wrote: > > Your reasoning makes sense but with your patch I get the following error: > > > > X Error of failed request: XF86DGADirectNotActivated > > Major opcode of failed request: 138 (XFree86-DGA) > > Minor opcode of failed request: 26 (XDGACreateColormap) > > Serial number of failed request: 3691 > > Current serial number in output stream: 3951 > > > > I'm not sure how to interpret this. Documentation for DGA seems to be > > pretty non-existant. Is this complaining that the CreateColormap failed > > because DGA wasn't activated or that DGA wasn't activated because > > of the colormap failure? > It's probably the former. I'm guessing that you need to create the > colormap on the same display that XDGAOpenFrameBuffer and XDGASetMode was > done on (those are currently done on thread_display(), you'll probably > have to change them too, then?) The two attached patches seem to do the job. Thanks for the hints. --- Glenn Schrader ------------------------------------------------------------------------ Index: dga2.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/dga2.c,v retrieving revision 1.5 diff -u -r1.5 dga2.c --- dga2.c 2001/09/11 00:32:33 1.5 +++ dga2.c 2001/11/20 22:13:32 @@ -102,7 +102,7 @@ { LPDDRAWI_DIRECTDRAW_LCL ddlocal = data->lpDD->lpExclusiveOwner; DWORD vram; - Display *display = thread_display(); + Display *display = gdi_display; data->ddRVal = DD_OK; if (data->dwModeIndex) { @@ -174,7 +174,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_CreatePalette(LPDDHAL_CREATEPALETTEDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(display, DefaultScreen(display), dga_dev, AllocAll); if (data->lpColorTable) X11DRV_DDHAL_SetPalEntries(data->lpDDPalette->u1.dwReserved1, 0, 256, @@ -185,7 +185,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_Flip(LPDDHAL_FLIPDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; if (data->lpSurfCurr == X11DRV_DD_Primary) { DWORD ofs = data->lpSurfCurr->lpGbl->fpVidMem - dga_mem.fpStart; TSXDGASetViewport(display, DefaultScreen(display), @@ -199,7 +199,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_SetPalette(LPDDHAL_SETPALETTEDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; if ((data->lpDDSurface == X11DRV_DD_Primary) && data->lpDDPalette && data->lpDDPalette->u1.dwReserved1) { TSXDGAInstallColormap(display, DefaultScreen(display), data->lpDDPalette->u1.dwReserved1); Index: x11ddraw.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11ddraw.c,v retrieving revision 1.12 diff -u -r1.12 x11ddraw.c --- x11ddraw.c 2001/08/27 19:04:18 1.12 +++ x11ddraw.c 2001/11/20 22:13:42 @@ -49,7 +49,7 @@ static LRESULT WINAPI GrabWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { - Display *display = thread_display(); + Display *display = gdi_display; if(message != X11DRV_DD_GrabMessage) return CallWindowProcA(X11DRV_DD_GrabOldProcedure, hWnd, message, wParam, lParam); @@ -81,7 +81,7 @@ if(grab) { Window window = X11DRV_get_whole_window(GetFocus()); if(window) - XSetInputFocus(thread_display(), window, RevertToParent, CurrentTime); + XSetInputFocus(gdi_display, window, RevertToParent, CurrentTime); } if(!X11DRV_DD_GrabMessage)

2 4

Re: PATCH: xterm support for wineconsole
by eric pouech 28 Nov '01

28 Nov '01

Marcus Meissner wrote: > > Hi, > > This patch adds a XTERM backend to wineconsole. > > Some problems: > - In full screen text applications (like IDA), the cursor shows sometimes > up in the wrong spot. > - Scrolling does not work yet (so winedbg doesn't really work). > - Uses config.h. I still have some questions... from a technical point of view, what didn't you use an ncurse (for example) lib to handle the TERM issues ? the old code you grabbed doesn't work correctly for all TERM configurations... rewriting everythind isn't the solution IMO from a more usage point of view, it seemed that TERM support for wineconsole was more intended for supporting an existing UNIX console (like when starting a command line tool and use the current TERM for interacting with it), which would mean in wineconsole case passing to wineconsole the handles of current TERM. furthermore, how to you plan to choose, when starting wineconsole, from the Win32 and the xterm backend ? in other words, I'm more in favor of : - Win32 backend for normal usage - reusing current UNIX console when run in TERM mode (and not xterm), and with the support of text mode lib (like ncurses) A+

2 2

(no subject)
by Ryan C. Stallings 28 Nov '01

28 Nov '01

Hello all, I am new to the wine scene and would like to try my hand at a little wine hacking. Are there any bugs out there that would be easy for a newbie to fix while letting me learn a bit about the inner workings of wine? I have read all the material about getting started developing, but I am just lacking a bit of direction on what to work on :) Thanks for your help, ryan

4 3

fix triggers crash
by Michael Stefaniuc 28 Nov '01

28 Nov '01

Hello! I found a bug in ImageList_Merge (the count of the images in the imagelist wasn't set) and the trivial fix Index: imagelist.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.43 diff -u -r1.43 imagelist.c --- imagelist.c 2001/09/10 23:09:04 1.43 +++ imagelist.c 2001/11/26 22:37:31 @@ -1918,6 +1918,7 @@ DeleteDC (hdcSrcImage); DeleteDC (hdcDstImage); + himlDst->cCurImage = 1; } return himlDst; =================================================================== triggers with FreeSolitaire (got it from tucows.com) following error (with crash): X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 19761 Current serial number in output stream: 19852 This happens with the cvs code from today and I'm pretty shure that it worked perfectly with the cvs code from two days before. And without the patch above the error dosn't get triggered. This seems strange because the error seems to occur in x11drv.StretchBlt and ImageList_Merge dosn't call StretchBlt. To reproduce the crash start FreeSolitaire with the patch above applied, select a solitaire game and start dragging a card around and wine will crash. With --debugmsg +relay it takes sometimes longer to trigger the bug, just release the card I try dragging an other card (i never needed to release the second card yet, wine crashed before). I've attached the last 1000 lines of relay output, hope that helps. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 1

Re: Another pack4 issue (fwd)
by Francois Gouget 27 Nov '01

27 Nov '01

On Thu, 22 Nov 2001, Dmitry Timoshkov wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: > > > After the recent patch sent by Dmitry Timoshkov I checked for other > > similar issues. AFAICS, at this time there is only one place where a > > pack4 is really necessary. > > Well, I don't know why you are so sure. My testing revealed the following > differences in structure sizes between Wine and Windows: Well, I had just performed a search on 'pshpck4.h' and checked that against Wine's headers to see whether there would be a difference. Your method seems much more thorough. I am a bit surprised that we have so many differences. We should see tons of crashes... (maybe that's good news) [...] > What is really fun, that usage of FILETIME instead of LARGE_INTEGER leads > to differences in size of structures. That's very strange. It would be good to understand why because this should not happen. diff -u cvs/hq/wine/dlls/advapi32/registry.c wine/dlls/advapi32/registry.c --- cvs/hq/wine/dlls/advapi32/registry.c Mon Jul 23 22:19:41 2001 +++ wine/dlls/advapi32/registry.c Thu Nov 22 17:52:05 2001 @@ -287,7 +287,7 @@ DWORD len = info->NameLength / sizeof(WCHAR); DWORD cls_len = info->ClassLength / sizeof(WCHAR); - if (ft) *ft = info->LastWriteTime; + if (ft) *ft = *(FILETIME *)&info->LastWriteTime; This cast should not be necessary. Both sides are FILETIMEs. --- cvs/hq/wine/dlls/ntdll/reg.c Thu Nov 8 16:15:30 2001 +++ wine/dlls/ntdll/reg.c Thu Nov 22 17:45:36 2001 @@ -161,9 +161,9 @@ WCHAR *class_ptr = (WCHAR *)((char *)name_ptr + name_size); int class_size = server_data_size(req) - sizeof(WCHAR) - name_size; int fixed_size; - FILETIME modif; + LARGE_INTEGER modif; - RtlSecondsSince1970ToTime( req->modif, &modif ); + RtlSecondsSince1970ToTime( req->modif, (FILETIME *)&modif ); Here I don't understant why you changed modif to a LARGE_INTEGER since RtlSecondsSince1970ToTime takes a FILETIME* switch(info_class) { diff -u cvs/hq/wine/include/commctrl.h wine/include/commctrl.h --- cvs/hq/wine/include/commctrl.h Wed Aug 8 17:37:12 2001 +++ wine/include/commctrl.h Thu Nov 22 16:50:13 2001 @@ -744,6 +744,8 @@ LPARAM lParam; INT iImage; INT iOrder; + UINT type; + LPVOID pvFilter; } HDITEMA, *LPHDITEMA; I don't see these two fields on Windows. Same thing for the W version. That's with the VC 6 headers. @@ -2959,9 +2958,11 @@ typedef struct { DWORD cb; - BYTE DeviceName[32]; - BYTE DeviceString[128]; + CHAR DeviceName[32]; + CHAR DeviceString[128]; DWORD StateFlags; + CHAR DeviceID[128]; + CHAR DeviceKey[128]; } DISPLAY_DEVICEA,*PDISPLAY_DEVICEA,*LPDISPLAY_DEVICEA; Hmm, no. It is 'BYTE' on Windows. And I don't see the two extra fields either. diff -u cvs/hq/wine/include/winnt.h wine/include/winnt.h --- cvs/hq/wine/include/winnt.h Mon Aug 13 00:51:56 2001 +++ wine/include/winnt.h Thu Nov 22 18:00:57 2001 @@ -396,8 +396,6 @@ typedef a *P##a, *LP##a #endif /*STRICT*/ - -#include "pshpack1.h" /* Defines */ /* Argument 1 passed to the DllEntryProc. */ @@ -576,6 +574,8 @@ DWORD Cr0NpxState; } FLOATING_SAVE_AREA, *PFLOATING_SAVE_AREA; +#define MAXIMUM_SUPPORTED_EXTENSION 512 + typedef struct _CONTEXT86 { DWORD ContextFlags; @@ -612,6 +612,8 @@ DWORD EFlags; DWORD Esp; DWORD SegSs; + + BYTE ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION]; } CONTEXT86; I don't have this field in CONTEXT86, but it is there in CONTEXT. It seems that it's our definition of CONTEXT which is wrong: typedef CONTEXT86 CONTEXT; @@ -2923,11 +2923,15 @@ WORD Reserved; } IMAGE_BOUND_FORWARDER_REF, *PIMAGE_BOUND_FORWARDER_REF; +#include "pshpack2.h" + typedef struct _IMAGE_BASE_RELOCATION { DWORD VirtualAddress; DWORD SizeOfBlock; +#ifdef __WINE__ WORD TypeOffset[1]; +#endif } IMAGE_BASE_RELOCATION,*PIMAGE_BASE_RELOCATION; Do we handle this correctly in the code? I.e. is there APIs where the application gives us a pointer to a struct without the field and we write to it? I wonder how this is supposed to work. +#include "pshpack4.h" typedef struct _LUID_AND_ATTRIBUTES { LUID Luid; DWORD Attributes; } LUID_AND_ATTRIBUTES; +#include "poppack.h" Is this really necessary? LUID is 8 bytes so the DWORD should be aligned just fine with or without the pack4... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

3 4

SetActiveWindow problem
by bperkins＠netspace.org 27 Nov '01

27 Nov '01

Sorry, I'm new to wine hacking, so bear with me. I was playing around a bit the other day trying to see if the tahni deskmate worked at all. I tried to run the installer (tahnisetup.exe available at tahni.com). It would run, and then crash with a stack overflow. I've attached the sequence in a backtrace that was repeated many times at the bottom. It's wine-20011108, BTW. Since I don't have the source to tahnisetup it made things a bit tricky to decipher. My guess was(is) that the program is trying to the window as active, which sends a message to the program. It sees that it's not active, so it again tries to set it as be active, which eventually causes a stack overflow. My awful hack was to just put a sanity counter in SetActiveWindow and return true after being called a certain number of times. This seems to work, as in it causes to program to get farther (it gets stuck on something else). Presumably one could check if it was being called recursively. I realize that this isn't really useful info, but I was curious to see if I was right about this, or if anyone had an insight. Am I right or did I just get lucky with the hack? 25246 0x0040266f (tahnisetup.exe..text+0x166f in E:\tahnisetup.exe) (ebp=437e6444) 25247 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6468) 25248 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6498) 25249 0x407c95ca (CallWindowProcA+0x4a(func=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2623] in libuser32.so) (ebp=437e64cc) 25250 0x4097b54c (FILEDLG_CallWindowProc+0x54(lfs=0x40400dbc, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:294] in libcomdlg32.so) (ebp=437e64f4) 25251 0x4097d944 (FileOpenDlgProc+0x78(hWnd=0x1002f, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:1440] in libcomdlg32.so) (ebp=437e651c) 25252 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6540) 25253 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6570) 25254 0x407c91f4 (WINPROC_CallProc32WTo32A+0x80(func=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2435] in libuser32.so) (ebp=437e6598) 25255 0x407c972b (CallWindowProcW+0xab(func=0x430c0984, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2675] in libuser32.so) (ebp=437e65cc) 25256 0x4079f744 (DefDlgProcW+0x48(hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [defdlg.c:389] in libuser32.so) (ebp=437e65f8) 25257 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e661c) 25258 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e664c) 25259 0x407c9152 (WINPROC_CallProc32ATo32W+0x7e(func=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2412] in libuser32.so) (ebp=437e6674) 25260 0x407c9647 (CallWindowProcA+0xc7(func=0x430c0259, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2643] in libuser32.so) (ebp=437e66a8) 25261 0x4076957e (call_window_proc+0xf2(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, unicode=0x0) [message.c:1146] in libuser32.so) (ebp=437e6704) 25262 0x4076a1af (SendMessageTimeoutA+0xdf(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, flags=0x0, timeout=0xffffffff, res_ptr=0x437e6788) [message.c:1577] in libuser32.so) (ebp=437e6764) 25263 0x4076a317 (SendMessageA+0x37(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026) [message.c:1622] in libuser32.so) (ebp=437e6798) 25264 0x407c2e92 (WINPOS_SetActiveWindow+0x196(hWnd=0x10026, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in libuser32.so) (ebp=437e67f0) 25265 0x407c229a (SetForegroundWindow+0x7a(hwnd=0x10026) [winpos.c:781] in libuser32.so) (ebp=437e680c) -- "Only CmdrTaco can save us now" -- The Register Brian Perkins bperkins(a)netspace.org

1 0

winedbg error
by Dave Hawkes 26 Nov '01

26 Nov '01

Hi all, I keep getting an assertion in winedbg, before I try and find out the cause does anyone know the possible reason for this? winedbg: types.c:573: DEBUG_CopyFieldList: Assertion 'dt->type == dt2->type && ((dt->type == DT_STRUCT) || (dt->type == DT_ENUM))' failed. It looks like its an issue with parsing the debug info, but the windows application debugs just fine with MS Developer Studio 6. Thanks, Dave Hawkes

3 10

ITypeInfo_fnGetContainingTypeLib
by lawson_whitney＠juno.com 25 Nov '01

25 Nov '01

Good day! Anyone like to take a swat at this? I don't normally shy from a page fault, but frankly, ICOM confuses me. Anyway, maybe Ove can spot it in a second. If I have to do it it may take weeks. Backtrace attached. Wineconsole seems to be working nicely, as long as the resolution is good and high. I wanted to include a typelib trace, but that crashes at an earlier spot. I haven't really looked at that one yet; I can send it along if anyone is interested. At least Wine is starting to get its teeth into InstallSh**** and its confounded IKernel.exe. Regards Lawson ---oof---

3 5

Re: Crashing menus, event handling broken?
by Alexandre Julliard 25 Nov '01

25 Nov '01

Jukka Heinonen <jhei(a)iki.fi> writes: > The reason for this is that raw hardware messages get processed > before menu event loop starts. Raw event processing turns raw events > into cooked events and because menu event loop has not started yet, > game window is not capturing events and thus clicks on menu bar > are turned into nonclient messages. These cooked messages are > put back into message queue. Raw messages are not supposed to get processed while there is a cooked message in the queue. Is the app filtering messages in GetMessage? Could you please do a +server trace showing the problem? -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: ttydrv fix (adds missing ShowWindow function)
by lawson_whitney＠juno.com 25 Nov '01

25 Nov '01

On Thu, 22 Nov 2001, Eric Laforest wrote: > tydrv/ttydrv.spec > =================================================================== > RCS file: /cvsroot/winex/wine/dlls/ttydrv/ttydrv.spec,v > retrieving revision 1.1.1.8 > diff -r1.1.1.8 ttydrv.spec > 71a72 > > @ cdecl ShowWindow(long long) TTYDRV_ShowWindow > Index: dlls/ttydrv/wnd.c > =================================================================== > RCS file: /cvsroot/winex/wine/dlls/ttydrv/wnd.c,v > retrieving revision 1.1.1.10 > diff -r1.1.1.10 wnd.c > 648a649,809 > > I think it is worth reading <wine>/README all the way to the end, where you will see: If you add something, or fix a bug, please send a patch ('diff -u' format preferred) to julliard(a)winehq.com or to the wine-patches(a)winehq.com mailing list for inclusion in the next release. -- Alexandre Julliard julliard(a)winehq.com Is it asking too much to use diff -u? Would you like to get patches from all over the world against who knows which version of wine in random formats? I think -u is the only format suitable for an open-source project. Regards, Lawson ---oof---

1 1

Re: wineconsole compile error
by Gerard Patel 24 Nov '01

24 Nov '01

At 06:59 PM 24/11/2001 +0100, you wrote: >make[1]: Entre dans le répertoire `/home/wine/programs/wineconsole' >gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DUNICODE -D_REENTRANT -I/usr/X11R6/include -o >dialog.o dialog.c >dialog.c: In function `WCUSER_GetProperties': >dialog.c:492: structure has no member named `u' <snip> Yes, me too. Does the patch posted on Wine-patches by Chris Green not fix it for you ? Gerard

3 2

Re: mmsystem should be loaded at startup
by eric pouech 24 Nov '01

24 Nov '01

Joshua Thielen wrote: > > Note: I'm not sure if I should have called ExitProcess if mmsystem.dll > can't be loaded not needed, if it couldn't be loaded, then no need to free it > and if I needed to call FreeLibrary. I just took the > LoadLibrary("user32") as an example. well, error reporting for 16 bit DLL is a bit different (see below) > + if(!(mmsystem = LoadLibrary16("mmsystem.dll"))) the correct test should be > + if((mmsystem = LoadLibrary16("mmsystem.dll")) < 32) (the other values (< 32) are the error codes) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

mmsystem should be loaded at startup
by Joshua Thielen 24 Nov '01

24 Nov '01

Hello everybody, Finale expects mmsystem to be present without having to call LoadLibrary on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm extensions are available. I checked out windows 95, and it has mmsystem and winmm loaded when no apps are runing besides the desktop / explorer. This patch links wine with winmm andmakes winmm load mmsystem on init. Finale gets by this ok now. I don't know if this the correct approach, though. Could someone (Eric or Alexandre?) please take a look at it before I send it to wine-patches? TIA, Josh Thielen Index: wine/miscemu/wine.spec =================================================================== RCS file: /home/wine/wine/miscemu/wine.spec,v retrieving revision 1.3 diff -u -r1.3 wine.spec --- wine/miscemu/wine.spec 2000/12/15 03:38:11 1.3 +++ wine/miscemu/wine.spec 2001/11/23 19:11:47 @@ -4,3 +4,4 @@ init wine_initial_task import ntdll.dll +import winmm.dll Index: wine/dlls/winmm/mmsystem.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.46 diff -u -r1.46 mmsystem.c --- wine/dlls/winmm/mmsystem.c 2001/11/13 21:58:32 1.46 +++ wine/dlls/winmm/mmsystem.c 2001/11/23 19:11:59 @@ -114,6 +114,7 @@ */ BOOL WINAPI WINMM_LibMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID fImpLoad) { + HINSTANCE16 mmsys16; TRACE("0x%x 0x%lx %p\n", hInstDLL, fdwReason, fImpLoad); switch (fdwReason) { @@ -124,9 +125,15 @@ MULTIMEDIA_DeleteIData(); return FALSE; } + mmsys16 = LoadLibrary16("mmsystem.dll"); + if (!mmsys16) { + ERR("Could not load sibling mmsystem.dll\n"); + return FALSE; + } break; case DLL_PROCESS_DETACH: MULTIMEDIA_DeleteIData(); + if(mmsys16) FreeLibrary16(mmsys16); break; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: @@ -2549,7 +2556,7 @@ TRACE("(%d, %p, %d);\n", uDeviceID, lpCaps, uSize); if ((wmld = MMDRV_Get(uDeviceID, MMDRV_MIDIIN, TRUE)) == NULL) - return MMSYSERR_INVALHANDLE; + return MMSYSERR_BADDEVICEID; return MMDRV_Message(wmld, MIDM_GETDEVCAPS, (DWORD)lpCaps, uSize, TRUE); }

3 3

Re: mmsystem should be loaded at startup
by Alexandre Julliard 24 Nov '01

24 Nov '01

Joshua Thielen <thielen(a)netprince.net> writes: > Finale expects mmsystem to be present without having to call LoadLibrary > on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm > extensions are available. I checked out windows 95, and it has mmsystem > and winmm loaded when no apps are runing besides the desktop / > explorer. This patch links wine with winmm andmakes winmm load mmsystem > on init. Finale gets by this ok now. I don't know if this the correct > approach, though. Could someone (Eric or Alexandre?) please take a look > at it before I send it to wine-patches? It would be better to do the LoadLibrary16("mmsystem") in wine_initial_task, this way it only impacts 16-bit applications. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wineconsole compile error
by Alexandre Julliard 24 Nov '01

24 Nov '01

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > dialog.o dialog.c > dialog.c: In function `WCUSER_GetProperties': > dialog.c:492: structure has no member named `u' > dialog.c:496: structure has no member named `u' > dialog.c:500: structure has no member named `u' > dialog.c:509: structure has no member named `u3' > > This is happening on gcc 3.0.2 (nameless union support, I suppose). It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

1 0

wineconsole compile error
by Andreas Mohr 24 Nov '01

24 Nov '01

Hi all, people get make[1]: Entre dans le répertoire `/home/wine/programs/wineconsole' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DUNICODE -D_REENTRANT -I/usr/X11R6/include -o dialog.o dialog.c dialog.c: In function `WCUSER_GetProperties': dialog.c:492: structure has no member named `u' dialog.c:496: structure has no member named `u' dialog.c:500: structure has no member named `u' dialog.c:509: structure has no member named `u3' This is happening on gcc 3.0.2 (nameless union support, I suppose). On my system, this file compiles painlessly: root@andi:/root# gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20010902 (Debian prerelease) (no nameless union support, I suppose) I told this guy to replace .u. and .u3. in dialog.c with DUMMYUNIONNAME and DUMMYUNIONNAME3, respectively. This caused: dialog.c:492: parse error before `.' dialog.c:496: parse error before `.' dialog.c:500: parse error before `.' dialog.c:509: parse error before `.' I thought that this particular error was caused by a missing #include "winnt.h", but adding this didn't help either. Please fix this "mess" ASAP (in an appropriate way, one that I seem to not be able to find out :-\). Thank you ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany "Point is, nothing here is unfamiliar or unexpected. How long does it take before there's general recognition that Microsoft software has no business on the Internet? - Dennis E. Powell re: Code Red

1 0

Re: Where are we going on multiuser?
by Alexandre Julliard 24 Nov '01

24 Nov '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > What is our vision on support for multiple users on a single computer? > > I know that WINEPREFIX allows us to use something other than $HOME/.wine for > the base of everything but as far as I can see the whole design still > requires a different WINEPREFIX for each user. (e.g. the socket is in > wine-server-<hostname> and there is no apparent support for the system.reg, > user.reg and userdef.reg being in different places). You need one WINEPREFIX per user yes. You can use global registry files by creating symlinks to global files in the user WINEPREFIX. The usual way is to wrap your app in a shell script that will populate the user's WINEPREFIX if it doesn't exist yet. There are plans for splitting registry files into separate sections with some kind of include mechanism, but nothing implemented yet. -- Alexandre Julliard julliard(a)winehq.com

1 0

Where are we going on multiuser?
by Bill Medland 23 Nov '01

23 Nov '01

What is our vision on support for multiple users on a single computer? I know that WINEPREFIX allows us to use something other than $HOME/.wine for the base of everything but as far as I can see the whole design still requires a different WINEPREFIX for each user. (e.g. the socket is in wine-server-<hostname> and there is no apparent support for the system.reg, user.reg and userdef.reg being in different places). Bill

1 0

Re: fix documentation compilation error
by Andreas Mohr 23 Nov '01

23 Nov '01

On Fri, Nov 23, 2001 at 01:35:14AM +0100, Michael Stefaniuc wrote: > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > Add missing </para> in documentation/packaging.sgml Ouch ! Hmm, better make an actual compile next time :-\ Sorry !! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

A window painting problem.
by Duane Clark 23 Nov '01

23 Nov '01

Howdy, Perhaps this is one of those things that is in work. But this patch causes one of the (sub)windows in the app Xilinx fpga_editor (commercial) to never get painted. The app has several windows within a window, including a scrolled window, which after the patch I can zoom in and out and move the scrollbars just fine. But the contents never get painted, no matter what I do, including hiding and reshowing, etc. All the other pieces and windows are painted fine. http://cvs.winehq.com/patch.py?id=1005773317852080273907632 Log message: Moved WIN_FindWinToRepaint functionality to the server. Duane

1 0

Re: Which is correct? listview or treeview?
by Gerard Patel 22 Nov '01

22 Nov '01

At 01:58 PM 21/11/2001 -0800, you wrote: >With regard to my problem that I was getting infinite redraws in my listview >following Alexandre's change to server/user/message.c: > >I eventually tracked it down to the fact our code used >SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be >demonstrated easily on e.g. the MFC RowList sample with a two-line change). >Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and >then RedrawWindow. >In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's >data. > >Which is (more) correct? I have seen the same problem with the plain listbox I have an app (Eudora) that is using WM_SETREDRAW on a listbox and found that it was not possible to reproduce the app's behaviour without doing directly a RedrawWindow. Andi commented it was ugly and unefficient (IIRC) and Alexandre Julliard ignored the patch anyway. So I intended at some point to look at Listview and Treeview (with the nasty intent to prove that I am right and they are wrong of course :-)) If you find that doing an explicit RedrawWindow is the right way (TM) I am all for it. OTOH, I have myself - at least ;-( - one regression pending for this patch. The attached hack (on dlls/x11drv/winpos.c) fixes it, maybe with a lot of luck it could fix your problem too ? I'm not too hopeful as it does not seem related but you never know. Gerard --- winpos.c.orig Tue Nov 13 23:02:20 2001 +++ winpos.c Thu Nov 22 00:24:35 2001 @@ -1464,6 +1464,14 @@ /*********************************************************************** * X11DRV_ConfigureNotify */ + +Bool predicate(Display *display, XEvent *event, char *arg) +{ + Window w = *((Window *) arg); + return ((event->type == ConfigureNotify) && + (event->xany.window == w)); +} + void X11DRV_ConfigureNotify( HWND hwnd, XConfigureEvent *event ) { HWND oldInsertAfter; @@ -1472,8 +1480,20 @@ RECT rect; WINDOWPOS winpos; int x = event->x, y = event->y; + XConfigureEvent ev; if (!(win = WIN_GetPtr( hwnd ))) return; + + while (XCheckIfEvent(event->display, (XEvent *)&ev, + predicate, (XPointer)&event->window)) + { + event->x = ev.x; + event->y = ev.y; + event->width = ev.width; + event->height = ev.height; + event->above = ev.above; + event->send_event = ev.send_event; + } data = win->pDriverData; /* Get geometry */

2 1

thanksgiving prayer
by lee 22 Nov '01

22 Nov '01

...wishing everyone a special thanksgiving filled with great joy, special friends and loved ones as we move forward to a brighter tomorrow, carrying with us the best of yesterday and the promise of today- lee

1 0

Crashing menus, event handling broken?
by Jukka Heinonen 22 Nov '01

22 Nov '01

While playing Civilization 2, I noticed that Wine crashes if I click menu bar twice while the game is thinking. The reason for this is that raw hardware messages get processed before menu event loop starts. Raw event processing turns raw events into cooked events and because menu event loop has not started yet, game window is not capturing events and thus clicks on menu bar are turned into nonclient messages. These cooked messages are put back into message queue. When menu event loop starts, it receives the second nonclient button press event and passes it to DispatchMessage. Default window procedure creates a new menu event loop and since the nonclient message was still in the event queue (it would have been removed if DispatchMessage had returned), we get a nice stack overflow. The real problem is not in menu event loop but in the fact that Wine event handling forgets that we can't determine whether a mouse event is nonclient event or not unless we have already called window procedure for all previous mouse events. This is because one of those calls might have for example captured mouse input after which we no longer report nonclient events. Since event handling is quite complicated and this flaw looks more like a design error than coding bug, I would like to get some discussion about what should be done to fix this problem. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: Packing in mmsystem16 and supporting broken GetWindowLong use cases
by Joshua Thielen 21 Nov '01

21 Nov '01

Jukka Heinonen wrote: >The second patch is because Wine mmsystem16 header does not use >correct packing which results into 48 byte structure taking >52 bytes and overwriting a pointer. This makes Civilization 2 >quite unhappy. Took almost a day to debug the game and >find out that the bugger who messes the pointer is really >waveOutGetDevCaps16... > Yessss! Thanks for finding this bug! It would have taken me ages to find it. Finale was choking awfully after calling midiInGetDevCaps. It would go into an endless loop, trashing my hard-drive and forcing me to do a hard reset on my box. Your patch fixes the problem. Cheers! Josh Thielen

1 0

Which is correct? listview or treeview?
by Bill Medland 21 Nov '01

21 Nov '01

With regard to my problem that I was getting infinite redraws in my listview following Alexandre's change to server/user/message.c: I eventually tracked it down to the fact our code used SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be demonstrated easily on e.g. the MFC RowList sample with a two-line change). Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and then RedrawWindow. In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's data. Which is (more) correct? (And how does calling RedrawWindow once result in the repeated repainting of the treeview anyway?) I'm prepared to do the fix if no-one else can but I must admit that I am not really up on the details of the invalidation/paint etc Bill

1 0

New level of Shlwapi (parts 1 & 2)
by Guy L. Albertelli 21 Nov '01

21 Nov '01

Most of the shlwapi upgrades have been driven by my desire to be able to run Outlook Express under Wine. (I know that there are other mail packages, but the rest of the home uses Windows - anyway it is a great test vehicle, uses everything ever implemented). The current status is as follows: With V4 or IE and OE - with builtin shlwapi,commctrl,comctl32 . IE displays page, can even do www.cnn.com, even runs javascript. + Certain menu popups either fail to display, or bomb. + Needs work in comctl32 rebar for extra space. . OE seems to basicly work. + Can display messages, change folders, and create messages. + Cannot invoke address book, but can request address list when creating new message. V5 of OE - requires native commctrl, comctl32: . With builtin comctl32 + OE fails to startup . With native commctrl, comctl32: + OE comes up but is mostly non-functional. Bombs on shutdown due to shlwapi.208 and shlwapi.210 V5 of IE - Does not start up yet. Requires native shlwapi . With native shlwapi, builtin comctl32 + IE has black toolbars with white lines. Menu line real small. . With native shlwapi and comctl32: + IE has black bitmaps for button bar. Mostly functional, however cannot access dropdown arrow for address bar. <sarcasm> I really appreciate the MS developer that decided to implement menus in OE5 with objects and put some of his "common" code in shlwapi. </sarcasm> Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Re: Improving DIB support for SHM
by Gavriel State 21 Nov '01

21 Nov '01

Doh! I guess we've been too lax about integrating some of our non D3D work back into WineHQ. We did this in WineX some time ago, but with a couple of differences: 1) We don't restrict using XShmGetImage to the whole-screen case and 2) We save and restore the XImage mask fields around the call to XShmGetImage, which seems to like to write over those fields to no useful purpose. IE: /* We must save and restore the bmpImage's masks in order * to preserve them across the call to XShmGetImage, which * decides to eliminate them since it doesn't happen to know * what the format of the image is supposed to be, even though * we do. */ saveRed = bmpImage->red_mask; saveBlue= bmpImage->blue_mask; saveGreen = bmpImage->green_mask; XShmGetImage( gdi_display, descr->drawable, bmpImage, descr->xSrc, descr->ySrc, AllPlanes); bmpImage->red_mask = saveRed; bmpImage->blue_mask = saveBlue; bmpImage->green_mask = saveGreen; We'll probably get around to doing some merging back into WineHQ after our next release. -Gav Jukka Heinonen wrote: > > The following patch halves the time it takes to move units > from one square to another in Civilization 2. If SHM is supported, > the patch uses XShmGetImage instead of XGetSubImage when filling > the whole XImage (which is probably way too careful since SHM is > much faster than the alternative...). Hopefully this > version is paranoid enough to work with older XFree86 servers > where XShmGetImage might change the underlying XImage format > into XYPixmap. > > Changelog: > Try to use XShmGetImage instead of XGetSubImage if SHM is supported. > Do a sanity check before using XShmPutImage. > > Index: wine/graphics/x11drv/dib.c > =================================================================== > RCS file: /home/wine/wine/graphics/x11drv/dib.c,v > retrieving revision 1.82 > diff -u -r1.82 dib.c > --- wine/graphics/x11drv/dib.c 2001/11/05 23:52:18 1.82 > +++ wine/graphics/x11drv/dib.c 2001/11/21 12:39:42 > @@ -4473,7 +4473,7 @@ > descr->xSrc, descr->ySrc, descr->xDest, descr->yDest, > descr->width, descr->height); > #ifdef HAVE_LIBXXSHM > - if (descr->useShm) > + if (descr->useShm && descr->image) > { > XShmPutImage( gdi_display, descr->drawable, descr->gc, bmpImage, > descr->xSrc, descr->ySrc, descr->xDest, descr->yDest, > @@ -4519,9 +4519,26 @@ > TRACE("XGetSubImage(%ld,%d,%d,%d,%d,%ld,%d,%p,%d,%d)\n", > descr->drawable, descr->xSrc, descr->ySrc, descr->width, > lines, AllPlanes, ZPixmap, bmpImage, descr->xDest, descr->yDest); > - XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc, > - descr->width, lines, AllPlanes, ZPixmap, > - bmpImage, descr->xDest, descr->yDest ); > + > +#ifdef HAVE_LIBXXSHM > + if (descr->useShm && descr->image && > + descr->xDest == 0 && descr->yDest == 0 && > + descr->width == bmpImage->width && > + lines == bmpImage->height && > + XShmPixmapFormat( gdi_display ) == ZPixmap) > + { > + XShmGetImage( gdi_display, descr->drawable, bmpImage, > + descr->xSrc, descr->ySrc, AllPlanes ); > + if (bmpImage->format != ZPixmap) > + ERR( "XShmGetImage changed image format!\n" ); > + } > + else > +#endif > + { > + XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc, > + descr->width, lines, AllPlanes, ZPixmap, > + bmpImage, descr->xDest, descr->yDest ); > + } > > TRACE("Dib: depth=%2d r=%lx g=%lx b=%lx\n", > descr->infoBpp,descr->rMask,descr->gMask,descr->bMask); > > -- > Jukka Heinonen <http://www.iki.fi/jhei/> -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

cleaning up pthreads implementation - ABI problem
by Peter Hunnisett 21 Nov '01

21 Nov '01

Howdy, I was just looking at cleaning up the pthreads implementation but I don't think that it's possible to have our pthreads implementation without providing binary compatibility with the pthread implementation we're hijacking. The reason is that the mutex and rwlock objects are supposed to be opaque to the programmer but in fact they are not opaque to the compiler. According to the standard, one doesn't have to call pthread_{mutex,rwlock}_init before using a {mutex,rwlock} as would be required with a totally opaque type. The standard allows for static initialization of the mutex and rwlock using PTHREAD_{MUTEX,RWLOCK}_INITIALIZER if you don't want any special attributes. libc does just this with its rwlock for gettext's global data. If you look at the ream of FIXME:pthread_rwlock_{rd,un}lock that sometimes come out starting wine you'll see that there's no call to pthread_rwlock_init. Of course, this stuff is safe because there's generally no writers wanting the pthread_rwlock_wrlock. So our current pthreads mutex implementation works in Linux by the skin of its teeth, becuase the first field in the mutex is reserved and initialized to 0 (in both the static and pthread_mutex_init cases), provided the version of LinuxThreads is new enough and a pointer is the same size as an int. Now I assume that this would mean it fails curiously for things that don't use LinuxThreads. This would also seem to mean, since we need binary compatibility, that things could even fail if someone upgrades their libc :( BTW, our check is presently basically only on __GLIBC__. Flavour me ignorant, and lazy, but I would assume that this not a Linux only symbol. So in fact the wine pthreads implementation might be already used incorrectly. Reader/Writer locks can be made to work the same way, as the mutex, since there are several fields which are initialized to NULL and we can then HeapAlloc our own structure off that field. We can then come up with weird and wonderful exceptions for the wonky cases that are sure to exist in some implementation of pthreads. Can anyone see a nice way out of this that I'm remaining ignorant to? I can't even think of a runtime way of detecting if our implementation is going to work. All in all I'm not too enthusiatic about the potential maintenance nightmare that this may provide but it would seem the only way is to have different mutex and rwlock structures depending on the pthreads implementation we're hijacking. Some code if people are more interested in details: >From glibc 2.2.4 /* Mutexes (not abstract because of PTHREAD_MUTEX_INITIALIZER). */ /* (The layout is unnatural to maintain binary compatibility with earlier releases of LinuxThreads.) */ typedef struct { int __m_reserved; /* Reserved for future use */ int __m_count; /* Depth of recursive locking */ _pthread_descr __m_owner; /* Owner thread (if recursive or errcheck) */ int __m_kind; /* Mutex kind: fast, recursive or errcheck */ struct _pthread_fastlock __m_lock; /* Underlying fast lock */ } pthread_mutex_t; #define PTHREAD_MUTEX_INITIALIZER \ {0, 0, 0, PTHREAD_MUTEX_TIMED_NP, __LOCK_INITIALIZER} What WINE uses (scheduler/pthread.c): /* assume that pthread_mutex_t has room for at least one pointer, * and hope that the users of pthread_mutex_t considers it opaque * (never checks what's in it) */ typedef struct { CRITICAL_SECTION *critsect; } *wine_mutex; rwlocks on the other hand are not so lucky as there's no unused bits: >From glibc-2.2.4 /* Read-write locks. */ typedef struct _pthread_rwlock_t { struct _pthread_fastlock __rw_lock; /* Lock to guarantee mutual exclusion */ int __rw_readers; /* Number of readers */ _pthread_descr __rw_writer; /* Identity of writer, or NULL if none */ _pthread_descr __rw_read_waiting; /* Threads waiting for reading */ _pthread_descr __rw_write_waiting; /* Threads waiting for writing */ int __rw_kind; /* Reader/Writer preference selection */ int __rw_pshared; /* Shared between processes or not */ } pthread_rwlock_t; # define PTHREAD_RWLOCK_INITIALIZER \ { __LOCK_INITIALIZER, 0, NULL, NULL, NULL, \ PTHREAD_RWLOCK_DEFAULT_NP, PTHREAD_PROCESS_PRIVATE } Ciao, Peter hunnise(a)yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

2 1

Re: _dev_t for MSVCRT
by Marcus Meissner 21 Nov '01

21 Nov '01

On Tue, Nov 20, 2001 at 10:16:14PM +0100, Uwe Bonnes wrote: > Changelog: > include/msvcrt/sys/types: > _dev_t in a unsigned integer > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > Index: wine/include/msvcrt/sys/types.h > =================================================================== > RCS file: /home/wine/wine/include/msvcrt/sys/types.h,v > retrieving revision 1.2 > diff -u -r1.2 types.h > --- wine/include/msvcrt/sys/types.h 2001/10/22 18:59:24 1.2 > +++ wine/include/msvcrt/sys/types.h 2001/11/20 19:44:21 > @@ -15,7 +15,7 @@ > #endif > > > -typedef unsigned short _dev_t; > +typedef unsigned _dev_t; Dann sollte da aber 'unsigned int' stehen ;) Ciao, Marcus

1 1

Re: (no subject) (msvcrt.getenv)
by Francois Gouget 20 Nov '01

20 Nov '01

On Tue, 20 Nov 2001, Uwe Bonnes wrote: > > Changelog: > dlls/msvcrt/environ.c: MSVCRT_getenv > Compare for the length of the key and return NULL in case of failure Good catch. Another thing to keep in mind: IIRC environment strings are not case sensitive on Windows. This means that normally getenv("PATH")==getenv("path") and that putenv("Path") would overwrite that same environment variable... This does not appear to be the case in the current code. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

1 0

winsock2.h
by lawson_whitney＠juno.com 20 Nov '01

20 Nov '01

Good day! To try debugging techniques for winelib apps, I had in mind to make a winelib app with an intentional segment fault, and found that _my_ winelib app will no longer compile. (gcc-2.95.3, glibc-2.2.3, current wine CVS). Please, it needs unistd.h so it can comfortably log to syslog. running winemaker on it again didn't help. checking for wrc... /usr/local/bin/wrc updating cache ./config.cache creating ./config.status creating Make.rules creating Makefile creating launcher Configure finished. Do 'make' to build the project. [whit@giftie wlp]$ make gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o t oj2.o toj2.c In file included from /usr/local/include/wine/winsock2.h:30, from /usr/local/include/wine/windows.h:39, from toj2.h:29, from toj2.c:19: /usr/local/include/wine/winsock.h:886: conflicting types for `gethostname' /usr/include/unistd.h:734: previous declaration of `gethostname' make: *** [toj2.o] Error 1 [whit@giftie wlp]$ I would be glad of a bit of advice thanks, Lawson Constants aren't, and variables won't.

2 4

Civilization2 segment register troubles
by Jukka Heinonen 20 Nov '01

20 Nov '01

Hi. I noticed that Civilization 2 has several problems under Wine. First, the game wants to access memory using segment register value zero, which causes protection exception since that is not allowed in protected mode. Second problem is that the game uses segment register value 0xf8, which Wine does not like. If I drop null-pointer protection [call to DOSMEM_Init(TRUE)], emulate cmp and mov commands so that they work even if using segment register value zero [added stuff to memory/instr.c] and make Wine accept segment register value 0xf8 [by hacking INSTR_ReplaceSelector], Civilization 2 starts to work without any problems. There are several possible reasons why the above changes make the game work: Wine corrupts segment registers somewhere, Civilization 2 wants to use privileged commands and Windows emulates them or the game runs in VM86 mode under Windows. So, I would like to get some ideas what should be done with Wine in order to get the game working. Oh, the above modifications fix protection faults that happen when the game tries to access the following addresses: 0x22, 0xc8, 0xf6, 0xf07c and 0xf0aa. P.S. Civilization 2 seems to work almost perfectly but it is painfully slow. I am pretty certain that I know the reason for this, but I would like to get the game working under official Wine before trying to make it run faster. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 2

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 20 Nov '01

20 Nov '01

Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes: > What I questioned was the criticism that FreeBSD was guilty > of namespace pollution. Alexandre isn't the only wine > developer who made this statement (check usenet). The header > files in question are implementation dependent and can > contain any variable name or #define or typedef. The fact is > that both wine and FreeBSD have struct thread in implementation > header files. AFAICT, neither is incorrect. The Wine headers that define struct thread are only used inside Wine; the FreeBSD headers are used by applications, no matter how much you argue they are internal headers. So the situation is very different. > But, to have > a wine developer emphatically state that FreeBSD needs to > fix its system header files is somewhat surprising. Why is > it surprising to me? Because this reminds me a company here > in Seattle. I couldn't care less whether FreeBSD fixes its headers or not; we will need to work around the problem in Wine in any case. I was simply expressing the opinion that changing this would make FreeBSD better. I'm certainly not demanding that the FreeBSD guys fix it, if they feel exporting struct thread is a good idea it's their choice. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: LibaudioIO Patch for Solaris
by eric pouech 20 Nov '01

20 Nov '01

Robert Lunnon wrote: > > Attached find files for libaudioio patch for audio on solaris 7 > > winmm.diff - Only the makefile patch is significant wavemap, just contains > some extra debugging traces > > libaudioio.tar, libaudioio goes under winmm > > base.diff, Patches to configure.in and Makefile.in to better support Solaris > and Libaudioio > > config.h.in added HAVE_SOLARIS and HAVE_LIBAUDIOIO and added a way for force > a 32 bit mmap. a few comments : - why do you add the libaudioio lib to winmm ? it should only be linked against the libaudioio (or whatever) driver... winmm should be independant of any driver... - in the libaudioio subdir: + you shouldn't use C++ comment. wine is a C project + it would a good idea to remove any reference to OSS in libaudioio... + I don't think that libaudioio supports midi... so, the preferred way to handle this would be to create a driver which doesn't export the midMessage and modMessage, and to get rid of midi.c and midipatch.c (same for mixMessage/mixer.c and auxMessage/aux.c) (it seems midi.c and mixer.c are protected by non existent HAVE_LIBAUDIO_MIDI and HAVE_LIBAUDIOIO_MIXER which are defined nowhere) + so the driver should only be made of the wave.c part and oss.c (which should be renamed to IMO) + anyway, I think that the libaudioio subdir should be named against the name of the DLL, which is audioio (eventually, since it's a wine only DLL, and to prevent DLL name collisions, I'd call it wineaudioio(.drv) - I don't see any reasons to define HAVE_SOLARIS... this is a wrong practice for system dependancies anyway A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 20 Nov '01

20 Nov '01

Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes: > Can you please explain how this is namespace pollution on the > part of the OS? AFAIK, <sys/user.h> is not specified by any > Standard (ISO C89, C90, or C99). <sys/user.h> can include > any (unprotected) variable name. Yes of course it can, but the fact that this isn't explicitly forbidden by some standard doesn't mean it's good practice or that it doesn't pollute the namespace. sys/user.h is also legally allowed to do "#define if else"; that doesn't make it a good idea. > If an application includes > <sys/user.h>, then the application should be prepared to > deal with conflicts. Great, then you need to fix all applications every time someone feels like exporting a new symbol from user.h. Of course user.h is a pretty obscure header so it's no big deal, but it would be easier to avoid exporting stuff under such common names as "struct thread". -- Alexandre Julliard julliard(a)winehq.com

4 4

interesting comment about WINE from MS
by Igor 20 Nov '01

20 Nov '01

As far as WINE and Mono are concerned, I'm just not sure whether these organizations will end up being able to produce satisfactory products. The real problem is this: it is not good enough for WINE to run some Windows apps. If the general public is going to consume it, it must run all Windows apps. Windows 2000/XP has a significant level of POSIX compliancy, but many developers just don?t write their apps with these standards in mind. You'll find pieces of code everywhere in third party apps which run statements like if (WINVER==4.0 && GrokTheBIOSForSomeACPIGoo()), which have not been tested to see whether they will run on non-Windows/x86 platforms. In fact, Microsoft has had to put in significant time and effort to insure that older Win32 applications originally written to run in Win95 will run in NT." original article is here http://www.osnews.com/story.php?news_id=314

1 0

Implementation of TB_REPLACEBITMAP
by Marco Bizzarri 20 Nov '01

20 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I'm trying to provide an implementation of TB_REPLACEBITMAP Included is the patch I've done to record the bitmaps which are provided to the toolbar and to replace them when the message arrives. Even though the number of buttons displayed is correct, the output is otherwise garbled. I would appreciate any suggestion on this topic. The platform is a RH Linux 6.2. wine is from CVS (20/11/2001) - -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE7+oUXXhfyAQQVoaIRAudsAJ9QEbPYChk0YpTonozvkjUge4HtjACgl8cg A87v4vPHKOeeCgj6LpW18dw= =J2rq -----END PGP SIGNATURE-----

1 0

audio.c fault reproduction
by Simon Britnell 20 Nov '01

20 Nov '01

I downloaded and ran the QuickTime installer and the Pajama Sam demo last PM. I have reproduced the problem with Pajama Sam (it seems that ends of samples are either not playing or being overwritten), but I can't get QuickTimePlayer.exe to do anything at all. I'll investigate the Pajama Sam problems over the remainder of the week. __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

2 1

RE: MIDL and COM
by Patrik Stridvall 20 Nov '01

20 Nov '01

> On 16 Nov 2001, Alexandre Julliard wrote: > > > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > > > But can the machine-generated sources that MIDL outputs > be put into the > > > official Wine source? > > > > I'd prefer not. 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. > > Hmm. Even when using flex and bison, it sounds like a fair amount of > work... wonder who would volunteer? There already are a multitude of open souce (GPL and otherwise) CORBA .idl compilers. Of course Wine have probably slightly different requirements but I should guess that we could save 90% of the work compared to writing it from scratch. Alexandre: Is a GPL:ed (or possible different licenced) .idl compiler acceptable? > > > And how about source IDL files? Can we put into Wine IDL > extracted from > > > real Windoze .tlb files with a tool like oleview.exe, or > IDL parsed from > > > MIDL-generated Windows SDK .h files, like objidl.h, with a script? > > > > No, anything generated from a Windows file is copyrighted by > > Microsoft, so we cannot distribute it. We need to rewrite > these files > > from scratch, just like we do for the normal headers. > > Now where are all the usual non-lawyers on this list who > would argue that > API definitions, like prototypes in header files (which of > course IDL, as > a formalized API spec format, is all about), cannot be copyrighted? > Oh well... I'm here. :-) Well, I wouldn't really go quite that far. The API definitions in themselves can't be copyrighted, true. But a specific way of expressing them is, so compiling any Microsoft file will generate create a derived work copyrighted by Microsoft as the main rule. However it is not quite that easy, since only the specific expression is protected, the compilation result is only a derived work if it still contains any protected expression. In light of this you could argue that since, I presume, MIDL removes whitespace and commments which is IIRC the only really expression, since the rest the API defintions are just facts, that the MIDL compiled files just contains facts not any part of the protected expression. However that is a little thin line to walk, since there is quite of lack of real cases in the area, so I would recommend that we do as Alexandre suggest. Beside having the real .idl files in the Wine tree might be useful for other things as well.

1 0

Re: MIDL and COM
by Alexandre Julliard 20 Nov '01

20 Nov '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Problem 1: MIDL-generated code. > midl.exe is Microsoft's IDL compiler, it reads .idl files which describe > RPC and COM interface, from which it generates .c files, .h files, and > typelibs. (It is possible to find copies of midl.exe floating on the net, > as some people have put together "COM kits" for Borland C++ that contains > midl.exe and some standard .idl files and put them on the web) > > But can the machine-generated sources that MIDL outputs be put into the > official Wine source? I'd prefer not. 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. > And how about source IDL files? Can we put into Wine IDL extracted from > real Windoze .tlb files with a tool like oleview.exe, or IDL parsed from > MIDL-generated Windows SDK .h files, like objidl.h, with a script? No, anything generated from a Windows file is copyrighted by Microsoft, so we cannot distribute it. We need to rewrite these files from scratch, just like we do for the normal headers. > Problem 2: RPCSS > rpcss.exe is the place that keeps track of which process owns which RPC > endpoints, exported COM objects, and object activation tables. > The IRunningObjectTable interface, for example, is managed by rpcss.exe, > and keeps track of certain kinds of COM objects on the computer, so that > other processes can connect to running COM objects. We probably don't want > Wine to have to run a separate process for this? If not, can we put this > kind of COM stuff into the wineserver? I'd prefer having a separate process, at least in the first stage. -- Alexandre Julliard julliard(a)winehq.com

2 1

audio.c regression on Nov. 10th
by Ori Pessach 19 Nov '01

19 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Despite my previous report on this, something did break in audio.c between November 9th and November 10th. I checked out a version from 11/09/2001, and it works. I updated just audio.c with -D 11/10/2001, and Humongous Entertainment games don't recognize the sound card anymore. There have been substantial changes to audio.c during those 24 hours - enough to confuse diff, as a matter of fact. I'll look into it, but I wanted to report this first. The reason I thought earlier that the problem went away was that I had a sticky date on audio.c that I wasn't aware of. Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE7+VXUzA/uWWyw6uQRAmkHAJ94A+IW82jXdhhLl6ODWaUs7I+SwACg16oT FIIymJ5xAP6eNc+5GlbQ3SU= =zHkd -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 19 Nov '01

19 Nov '01

Francois Gouget <fgouget(a)free.fr> writes: > I guess that one day Alexandre is going to argue that Linux should > stop polluting the namespace with 'struct user'... Well, struct user is the only reason for including sys/user.h, so I guess it can be considered acceptable; but anything else defined in there (like struct user_regs_struct on Linux) is namespace pollution too IMO. And if there comes a day when the server is managing users, the corresponding struct will definitely be named struct user, not struct wine_unique_prefix_0918274_user or whatever (and note that we don't really need user.h even on Linux, we could just as well hardcode the offset). -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 19 Nov '01

19 Nov '01

Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes: > FreeBSD isn't polluting the namespace. <sys/user.h> is a > a non-standard header file. It's still made available to applications, and there is really no reason for exporting internal kernel names this way. At least it could be renamed or put inside #ifdef _KERNEL. The alternative is of course to avoid sys/user.h, or play with #defines on the Wine side; but prefixing our structures with wine_ is not a solution. -- Alexandre Julliard julliard(a)winehq.com

4 4

Re: Fix to audio.c 1.46 loop problem + choppy sound
by Michael Stefaniuc 19 Nov '01

19 Nov '01

On Fri, Nov 16, 2001 at 07:59:20PM -0800, Simon Britnell wrote: > This patch should fix a loop playing failure reported > by Eric and a problem with choppy sound I experienced > playing total annihilation Hmm ... this patch horrible breaks the sound in Quicktime. The sound is now (audio.c 1.47) practicaly nonexistand: every 5-7 seconds you hear something for about 1/2 seconds. Before that (audio.c 1.45,1.46) the sound was choppy and played at 4/5 of the normal speed whereas with audio.c 1.44 the sound plays perfect. I'm using Quicktime 5.02 standalone in the german version. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 19 Nov '01

19 Nov '01

Francois Gouget <fgouget(a)free.fr> writes: > Renaming struct thread it the right thing to do though. Why > doesn't changing thread to wine_thread in request.h work? No, the right thing is to fix the FreeBSD headers to stop polluting the namespace. struct thread is a perfectly valid identifier for an application to use (and we are certainly not the only application using it). -- Alexandre Julliard julliard(a)winehq.com

2 1

Kdevelop and Wine
by Chuck Fischer 19 Nov '01

19 Nov '01

Hello, I'm new to Linux, Kdevelop and Wine. I've been given the task of getting a Windows application to run on *nix. After some surfing I found KDevelop and Wine. I would like to use KDevelop to build my Windows app with WineLib. Can this be done? Has it been done? What do I need to do to get it to work? Also, are there any plans or thoughts about integrating WineLib with KDevelop? TIA, Chuck

2 1

Re: Build failure due to winsock.h changes, specifically htonl
by Gerald Pfeifer 19 Nov '01

19 Nov '01

On Thu, 15 Nov 2001, Francois Gouget wrote: > Yes. This one is actually simple to solve: do not include > 'winsock2.h'. AFAICT including 'winsock2.h' is not necessary since 1.66 > (2000/08/31) when get_socket_event and FD_MAX_EVENTS where removed. > I am working on the other compilation problems... I just performed a cvs update and now was able to again build Wine on FreeBSD 4.4 due to your latest changes. Thanks a lot! Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

readdir broken when called from wine
by Lionel Elie Mamane 19 Nov '01

19 Nov '01

Hi, After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled from tarballs), suddenly it didn't find my "C:\Windows" any more. Worked before, same 'puter, config files, etc (TM). Tried with CVS version. Nope. I recruited Andreas Mohr on #WineHQ for help, we ruled out the obvious (yes, the directory exists, here is my config file, no, I don't confuse root and non-root, ...), and got down to add traces and dug in the code. So, for some reason, the readdir calls from files/dos_fs.c:DOSFS_ReadDir() report success (ie return non-NULL), but the directory entry name returned (dirent->d_name) is always the empty string (*(dirent->d_name)=='\0')! So I checked if readdir worked generally on my system, it does, this program does the expected thing: int main(void) {//Tst code DIR *mydir; struct dirent *entr; mydir = opendir("/"); while ((entr = readdir(mydir))) { TRACE("Dir_entry: %s\n", entr->d_name); } closedir(mydir); } I even went the extra mile and compiled it with exactly the same options (minus the various -I's) as dos_fc.c gets in wine, it works. Then, I added that code snippet (without the "int main(void)", obviously) to wine's main(). Worked. So I went down the stack of called functions, putting that same snippet in each function to see when it breaks: It works "up to" (or down to?) loader/main.c:MAIN_MainInit(). That function calls files/directory.c:DIR_Init(), and there, it doesn't work (ie name is always empty string) in DIR_Init(). After DIR_Init() returns, it still works in MAIN_MainInit(). I tried to find a difference between these files, but they get compiled with the same compile options, combined by "ld -r" along with other .o's in files/files.o, resp. loader/loader.o, and the two latter go in libntdll.so. What could be the difference that makes readdir "break"? I've put the test code snippet just before the call to DIR_Init in MAIN_MainInit, and just after variable declaration in DIR_Init, so it's not a function that DIR_Init calls that "breaks havoc". Well... We're lost there. No idea. Anyone of you? Anyway, here's some info on my system, just giving random info, I don't really know which one will be useful: Pentium III 500 / 440BX motherboard SuSE 6.4 distrib "base" with several self-compiled "add-ons", "upgrades", and some newer SuSE RPM's installed (from 7.0, 7.1 or 7.2). Along the latter (newer RPM than SuSE 6.4), the glibc... glibc-2.2-9 Linux 2.2.20 (Was using .19 when problem started) Soundblaster AWE32 3Com NIC (3C905B) Adaptec SCSI controller (AHA-3950U2) gcc 2.95.2 GNU ld 2.9.5 binutils-2.9.5.0.24-30 Err... What more??? Any additional info useful? Just ask. (except r00t password, "of course" ;-> ) Thank you for your time, -- Lionel Elie Mamane RFC 1991 (PGP 2.x) 2048 bits Key Fingerprint (KeyID: 20C897E9): 85CF 986F 263E 8CD0 80FD 4B8C F5F9 C17D OpenPGP DH/DSS 4096/1024 Key Fingerprint (KeyID: 3E7B4B73): 9DAD 3131 3ADA F50B D096 002A B1C4 7317 3E7B 4B73

3 3

Query on ActiveX components support from Wine.
by Ganesh.S 19 Nov '01

19 Nov '01

Hi, Is it possible to run an application that uses MSGrid ActiveX component and other database related components. My application was developed in VB6.0 which uses Microsoft Access in the backend. When I run the application the datas are not comming. Also few of the screens are not coming up saying that can't load the ActiveX component and the application gets killed. Is there any patch or solution for this. Can you suggest me the solution for this. thanks in advance, with regards, Ganesh.S Success is the progressive Realisation of a Worthy Goal. HCL Peripherals

1 0

Re: misc. code fixes
by Alexandre Julliard 19 Nov '01

19 Nov '01

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > - make listbox.c use reasonable bounds checking That's a completely gratuitous change, it makes absolutely no difference to the code. If you like your way better you are free to use it on your own code; but please don't go around "fixing" other people's code like this. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Patches for FreeBSD 5.x compilation
by Francois Gouget 19 Nov '01

19 Nov '01

On Sun, 18 Nov 2001, Steve Kargl wrote: > The following patches are required to compile > the latest wine sources on FreeBSD 5.x. Note, I have a patch that I think should fix this compilation problem. I sent it on the 15th but it got loast without a trace so I resent it today (search for 'Solaris and FreeBSD compilation fixes (fwd)'). > Index: wine/dlls/wsock32/socket.c > =================================================================== > RCS file: /home/wine/wine/dlls/wsock32/socket.c,v > retrieving revision 1.16 > diff -u -r1.16 socket.c > --- wine/dlls/wsock32/socket.c 2001/11/14 21:26:23 1.16 > +++ wine/dlls/wsock32/socket.c 2001/11/18 18:42:14 > @@ -42,6 +42,7 @@ > #include <stdio.h> > #include <stdlib.h> > #include <unistd.h> > +#include <sys/socket.h> > #ifdef HAVE_SYS_SOCKIO_H > # include <sys/sockio.h> > #endif This should have a #ifdef HAVE_SYS_SOCKET_H around it. See my patch. > Index: wine/include/winsock.h > =================================================================== > RCS file: /home/wine/wine/include/winsock.h,v > retrieving revision 1.37 > diff -u -r1.37 winsock.h > --- wine/include/winsock.h 2001/11/14 21:26:24 1.37 > +++ wine/include/winsock.h 2001/11/18 18:42:17 > @@ -894,14 +894,10 @@ > struct WS(servent)* WINAPI WS(getservbyport)(int,const char*); > int WINAPI WS(getsockname)(SOCKET,struct WS(sockaddr)*,int*); > int WINAPI WS(getsockopt)(SOCKET,int,int,char*,int*); > -u_long WINAPI WS(htonl)(u_long); > -u_short WINAPI WS(htons)(u_short); > unsigned long WINAPI WS(inet_addr)(const char*); > char* WINAPI WS(inet_ntoa)(struct WS(in_addr)); > int WINAPI WS(ioctlsocket)(SOCKET,long,u_long*); > int WINAPI WS(listen)(SOCKET,int); > -u_long WINAPI WS(ntohl)(u_long); > -u_short WINAPI WS(ntohs)(u_short); > int WINAPI WS(recv)(SOCKET,char*,int,int); > int WINAPI WS(recvfrom)(SOCKET,char*,int,int,struct WS(sockaddr)*,int*); > int WINAPI WS(send)(SOCKET,const char*,int,int); This will break Winelib. I guess this was to fix the compilation errors in 'server/trace.c'. In that case I think a better solution is to not include 'winsock2.h' at all in server/trace.c since it appears to no longer be needed. > Index: wine/server/context_i386.c > =================================================================== > RCS file: /home/wine/wine/server/context_i386.c,v > retrieving revision 1.18 > diff -u -r1.18 context_i386.c > --- wine/server/context_i386.c 2001/07/11 17:30:59 1.18 > +++ wine/server/context_i386.c 2001/11/18 18:42:55 > @@ -20,9 +20,6 @@ > #ifdef HAVE_SYS_PARAM_H > # include <sys/param.h> > #endif > -#ifdef HAVE_SYS_USER_H > -# include <sys/user.h> > -#endif What is the problem with 'sys/user.h' ? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

2 2

Re: Excessive redraw in Lotus Notes with Wine 20011108
by Glenn Schrader 19 Nov '01

19 Nov '01

Toby Haynes wrote: >I've just compiled up Wine 20011108 and given it a little testing. QuickTime >installer works fine and QuickTime player comes up, although it wants to be >fullscreen most of the time (something to do with strange mouse click handling >I think). SameTime installer runs (at least for version 1.5) although I can't >get the actual program to start (Unhandled exception). > >Lotus Notes 5.0.4 also appears to run fine with this build (I couldn't reply to >messages with the October WINE release) but there is one headache-inducing >problem. When composing a message or editing a document, the screen redraws for >every letter. It does this pretty quickly but the effect is that the screen >flashes as I type. It's bad enough that I type with my eyes closed to avoid >looking at the screen and edit any mistakes I make at the end. It's not a >problem at other times such as reading messages or browsing databases - only >editing seems to suffer from this. > >Setting double-buffer visuals doesn't seem to help. Managed or desktop >configurations both suffer from this. > >Does anyone have any clues as to settings to tweak to minimise/stop this >happening? I'd rather not go back to 20010326 (my stable backup build) but I >will if I can't solve this problem. > >Thanks, >Toby Haynes > I have been having a similar problem with a different app. Try the attached patch and see if it helps. --- Glenn Schrader Index: painting.c =================================================================== RCS file: /home/wine/wine/windows/painting.c,v retrieving revision 1.61 diff -u -r1.61 painting.c --- painting.c 2001/10/16 21:58:59 1.61 +++ painting.c 2001/11/18 22:48:09 @@ -345,23 +345,12 @@ TRACE("hrgnUpdate = %04x, \n", hrgnUpdate); - if (GetClassLongA( hwnd, GCL_STYLE ) & CS_PARENTDC) - { - /* Don't clip the output to the update region for CS_PARENTDC window */ - if( hrgnUpdate ) - DeleteObject(hrgnUpdate); - lps->hdc = GetDCEx( hwnd, 0, DCX_WINDOWPAINT | DCX_USESTYLE | - (bIcon ? DCX_WINDOW : 0) ); - } - else - { - if( hrgnUpdate ) /* convert to client coordinates */ - OffsetRgn( hrgnUpdate, wndPtr->rectWindow.left - wndPtr->rectClient.left, - wndPtr->rectWindow.top - wndPtr->rectClient.top ); - lps->hdc = GetDCEx(hwnd, hrgnUpdate, DCX_INTERSECTRGN | - DCX_WINDOWPAINT | DCX_USESTYLE | (bIcon ? DCX_WINDOW : 0) ); - /* ReleaseDC() in EndPaint() will delete the region */ - } + if( hrgnUpdate ) /* convert to client coordinates */ + OffsetRgn( hrgnUpdate, wndPtr->rectWindow.left - wndPtr->rectClient.left, + wndPtr->rectWindow.top - wndPtr->rectClient.top ); + lps->hdc = GetDCEx(hwnd, hrgnUpdate, DCX_INTERSECTRGN | + DCX_WINDOWPAINT | DCX_USESTYLE | (bIcon ? DCX_WINDOW : 0) ); + /* ReleaseDC() in EndPaint() will delete the region */ TRACE("hdc = %04x\n", lps->hdc);

1 0

Re: readdir broken when called from wine
by Gerard Patel 18 Nov '01

18 Nov '01

At 08:17 PM 18/11/2001 +0100, you wrote: >After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled >from tarballs), suddenly it didn't find my "C:\Windows" any >more. Worked before, same 'puter, config files, etc (TM). Tried with >CVS version. <snip> >What could be the difference that makes readdir "break"? Take a look at the 'cvs-regression' file in the documentation directory. Gerard

2 1

Re: cleanup patch
by Marcus Meissner 18 Nov '01

18 Nov '01

> diff -u -r1.5 dib.c > --- dlls/ddraw/dsurface/dib.c 10 Sep 2001 23:12:16 -0000 1.5 > +++ dlls/ddraw/dsurface/dib.c 18 Nov 2001 13:47:22 -0000 > @@ -386,7 +386,11 @@ > > dbuf = (BYTE*)ddesc.lpSurface+(xdst.top*ddesc.u1.lPitch)+(xdst.left*bpp); > > - dwFlags &= ~(DDBLT_WAIT|DDBLT_ASYNC);/* FIXME: can't handle right now */ > + if (dwFlags & (DDBLT_WAIT|DDBLT_ASYNC)) > + { > + FIXME("dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now.\n"); > + dwFlags &= ~(DDBLT_WAIT|DDBLT_ASYNC); > + } I do not want to see this FIXME 50 times or more per second. Ciao, Marcus

1 0

I've been too damn bored today...
by Andreas Mohr 18 Nov '01

18 Nov '01

Hi all, that was the result: http://home.nexgo.de/andi.mohr/download/nicegraph.png -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

2 1

Re: SystemParametersInfo: Screen Save actions
by Alexandre Julliard 17 Nov '01

17 Nov '01

Francois Gouget <fgouget(a)free.fr> writes: > In fact, I disagree with Alexandre when he says: > > > If users want to reconfigure X behavior, they have to use the X > > configuration programs. > > I think Wine is about more than just running Windows applications on > Linux. It's about integrating Windows and Linux applications and thus > they should be able to manipulate these kind of settings. Otherwise Wine > would only support the 'desktop mode' or it would not exist at all and > everyone would be happy with running Windows in a sand-box ala VMWare. I also said there could be exceptions... I agree temporarily disabling the screen saver can be useful, so we probably want to allow at least that. I'm not sure we want to allow messing with the timeout though. -- Alexandre Julliard julliard(a)winehq.com

5 7

AutoCad2000 Error ...
by Ancient Computers 16 Nov '01

16 Nov '01

Wine release 20011108 Standard config. starting with wine acad.exe in a windows install ... fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--12-120-75-75-p-64-tis620.2533-1' has unknown character encoding '1' in known registry 'tis620 .2533' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--13-130-75-75-p-71-tcvn-5712' has unknown character encoding '5712' in known registry 'tcvn' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-75-p-46-iso8859-9e' has unknown character encoding '9e' in known registry 'iso8859' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-75-p-49-tatar-cyr' has unknown registry 'tatar' and character encoding 'cyr' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-75-p-50-koi8-c' has unknown character encoding 'c' in known registry 'koi8' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-75-p-51-koi8-k' has unknown character encoding 'k' in known registry 'koi8' err:font:XFONT_BuildMetrics failed to load -macromedia-king richard-medium-r-normal--100-*-100-100-p-0-ascii-0 err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

1 0

Re: SystemParametersInfo: Screen Save actions
by Andreas Mohr 16 Nov '01

16 Nov '01

On Wed, Nov 14, 2001 at 07:22:39AM -0800, Andriy Palamarchuk wrote: > Change log: > > SystemParametersInfo. Implemented processing for > actions SPI_GET/SETSCREENSAVETIMEOUT, > SPI_GET/SETSCREENSAVEACTIVE, > SPI_GET/SETSCREENSAVERRUNNING. Removed integration > with X Window screen saving. Hmm, why did you remove X11 screen saving completely ?? Probably because it was horribly broken, right ? (SPI_SETSCREENSAVEACTIVE *activated* screen saver instead of *enabling* it - doh !) Why don't you fix this strange code instead of removing it ? I guess I should do it... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

3 3

RE: wine/ dlls/user/message.c include/win.h server ...
by Medland, Bill 16 Nov '01

16 Nov '01

Found the problem, not the fix. message.c function PeekMessageW. It used to call FindWinToRepaint but that has been moved into the server. But FindWinToRepaint was able to return a window handle other than the original message window handle. 1. So what about the IsIconic line following it? Now it's testing the wrong handle. 2. (The real problem)PeekMessageW returns the message. Now the handle it returns is the unadulterated one, not the potential child. So what do we do about that? Get the server to return it? Bill > -----Original Message----- > From: Alexandre Julliard [mailto:julliard@winehq.com] > Sent: Wednesday, November 14, 2001 1:29 PM > To: wine-cvs(a)winehq.com > Subject: wine/ dlls/user/message.c include/win.h server ... > > > ChangeSet ID: 1005773317852080273907632 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/11/14 16:28:37 > > Modified files: > dlls/user : message.c > include : win.h > server : queue.c user.h window.c > windows : win.c > > Log message: > Moved WIN_FindWinToRepaint functionality to the server. > > Patch: http://cvs.winehq.com/patch.py?id=1005773317852080273907632 > > Revision Changes Path > 1.12 +0 -6 wine/dlls/user/message.c > 1.64 +0 -1 wine/include/win.h > 1.19 +3 -3 wine/server/queue.c > 1.5 +1 -0 wine/server/user.h > 1.10 +46 -1 wine/server/window.c > 1.169 +0 -104 wine/windows/win.c > > >

2 1

Re: [RFC]: Overlapped I/O implementation
by Alexandre Julliard 16 Nov '01

16 Nov '01

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > B) The check_async() function in synchro.c operates on file descriptors > rather than async requests. Once an overlapped I/O request is > issued by the application, it is queued either in the readers or > writers list of the async object (which is obtained from the server). > If both the readers and writers lists were NULL beforehand, the fd > is inserted into the list for check_async to work on. But the list has to be stored in the server, otherwise you cannot guarantee the request order across processes. I think you need to put just about everything except the actual read/write call in the server. > check_async() activates the first element(s) of both the readers and > writers lists (where activate means that the actual read/write call > is triggered). For FIFOS, only one element would be activated; for > regular files several requests up to a given limit (e.g. 4). > > If the file is on a device where normal I/O would be blocking, a > new thread is created for each activated request to satisfy it. I don't think we want to use threads at all. This has major overhead and compatibility problems. IMO normal file I/O should always be done synchronously; it may impact performance a bit when reading from floppy, but this is better than slowing down all async operations with the need to manage threads and locks. -- Alexandre Julliard julliard(a)winehq.com

3 5

MIDL and COM
by Ove Kaaven 16 Nov '01

16 Nov '01

OK, since list traffic is low at the moment (which might be because /var on WineHQ got full again, and as usual the secondary MX provided by Corel seems to have the functionality of a black hole, so I've now moved the apache logs off /var), I thought I'd try to liven it up a bit with a couple of things I'm wondering about... Problem 1: MIDL-generated code. midl.exe is Microsoft's IDL compiler, it reads .idl files which describe RPC and COM interface, from which it generates .c files, .h files, and typelibs. (It is possible to find copies of midl.exe floating on the net, as some people have put together "COM kits" for Borland C++ that contains midl.exe and some standard .idl files and put them on the web) But can the machine-generated sources that MIDL outputs be put into the official Wine source? And how about source IDL files? Can we put into Wine IDL extracted from real Windoze .tlb files with a tool like oleview.exe, or IDL parsed from MIDL-generated Windows SDK .h files, like objidl.h, with a script? Problem 2: RPCSS rpcss.exe is the place that keeps track of which process owns which RPC endpoints, exported COM objects, and object activation tables. The IRunningObjectTable interface, for example, is managed by rpcss.exe, and keeps track of certain kinds of COM objects on the computer, so that other processes can connect to running COM objects. We probably don't want Wine to have to run a separate process for this? If not, can we put this kind of COM stuff into the wineserver?

1 0

RE: wine/ dlls/user/message.c include/win.h server ...
by Medland, Bill 15 Nov '01

15 Nov '01

This patch causes the listview class to enter some sort of infinite repaint loop on our application. Is someone else already tackling it? Bill > -----Original Message----- > From: Alexandre Julliard [mailto:julliard@winehq.com] > Sent: Wednesday, November 14, 2001 1:29 PM > To: wine-cvs(a)winehq.com > Subject: wine/ dlls/user/message.c include/win.h server ... > > > ChangeSet ID: 1005773317852080273907632 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/11/14 16:28:37 > > Modified files: > dlls/user : message.c > include : win.h > server : queue.c user.h window.c > windows : win.c > > Log message: > Moved WIN_FindWinToRepaint functionality to the server. > > Patch: http://cvs.winehq.com/patch.py?id=1005773317852080273907632 > > Revision Changes Path > 1.12 +0 -6 wine/dlls/user/message.c > 1.64 +0 -1 wine/include/win.h > 1.19 +3 -3 wine/server/queue.c > 1.5 +1 -0 wine/server/user.h > 1.10 +46 -1 wine/server/window.c > 1.169 +0 -104 wine/windows/win.c > > >

1 0

Re: Need to increase REQUEST_MAX_VAR_SIZE
by Andreas Mohr 15 Nov '01

15 Nov '01

On Thu, Nov 15, 2001 at 01:54:29PM +0100, Uwe Bonnes wrote: > Hallo, > > some aplication tries to set a reather longish windows text with over 512 > characters > > 0970c7a0:Call kernel32.lstrlenA(41b6bd8c "License for required features not available\n\n\nSorry, no Synplicity license is av"...) ret=006f06c2 > 0970c7a0:Ret kernel32.lstrlenA() retval=0000026b > ... > 0970c7a0:Call user32.SetWindowTextA(0001002e,41b6bb0c "License for required features not available\n\n\nSorry, no Synplicity license is av"...) ret=00 > 6fce93 > ... > wine: client.c:136: wine_server_alloc_req: Assertion `size <= 1024' failed. > > For the serrver call this is translated into Unicode and so 1024 byte is not > enough for the string. Argh, why is stupid license speak always so darned long ??? This is the second time that I've seen problems caused by license stuff. (I had a similar problem with dbgstring_a() output). We should really tell lawyers to behave themselves a lot better :-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re: 3D Studio 4 notes
by Gerard Patel 15 Nov '01

15 Nov '01

At 04:58 AM 15/11/2001 +0100, you wrote: <snip> >091d38d8:Call ws2_32.getsockopt(ffffffff,0000ffff,00007008,00f1ca84,45e96d54) ret=00de3f47 >fixme:winsock:_get_sock_fd handle -1 is not a socket (GLE 6) >trace:winsock:WSOCK32_getsockopt socket: ffffffff, opt 0xffff, ptr f1ca84, len 4 >091d38d8:Ret ws2_32.getsockopt() retval=ffffffff ret=00de3f47 Yes, this is not the old bug - the same call would fail under Windows. Even if the option is not supported by Wine, using a socket of -1 is probably incorrect. So either the app has a bug that occurs also under Windows, or the invalid value comes from a previous problem (maybe because of an invalid installation) Also, this app is using msvcrt. Make sure that you use 'native' msvcrt if you have it (-debugmsg +loaddll). Maybe the problem has nothing to do with sockets. Gerard

1 0

Re: wine_anon_mmap MAP_FIXED patch
by Ove Kaaven 15 Nov '01

15 Nov '01

On Thu, 15 Nov 2001, Bang Jun-Young wrote: > on MAP_FIXED flag. On Linux, it shouldn't do any harm. Yes, it would do harm. See http://www.winehq.com/hypermail/wine-devel/2000/11/0167.html

1 0

Re: 3D Studio 4 notes
by Gerard Patel 15 Nov '01

15 Nov '01

At 04:43 PM 14/11/2001 +0100, you wrote: <snip> >fixme:winsock:_get_sock_fd handle -1 is not a socket (GLE 6) >MSG .0 fatal: getsockopt(SO_OPENTYPE) failed - Invalid handle This error message has already been posted several times on the news group. It was linked to the previous Wine version (october) Do you use last version (1108) or current Cvs ? Gerard

2 2

Re: patch.py?id=1005690229526658676564693 (fwd)
by Alexandre Julliard 15 Nov '01

15 Nov '01

lawson_whitney(a)juno.com writes: > Hmmm, I put the patch back, and took desktop= out of the config. The > problem only happens in desktop mode. That is not so bad, I don't have > to spend 45 minutes reverting the patch just to get mail. Still, I > guess I should try to debug it. It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine_anon_mmap MAP_FIXED patch
by Ulrich Weigand 15 Nov '01

15 Nov '01

Bang Jun-Young <junyoung(a)mogua.com> wrote: > Why this is necessary is because most Win32 binaries expect itself > to be loaded at fixed address (0x400000). GCC and M$ compilers seem > to strip relocation info on .exe by default, so we need to ensure > that on some OS, i.e. NetBSD. Refer to NetBSD/FreeBSD mmap(2) manpage > on MAP_FIXED flag. On Linux, it shouldn't do any harm. On Linux and Solaris, MAP_FIXED has a different meaning: it will *replace* any pre-existing mapping at the given address, typically causing corruption. I'm not sure what the BSD behaviour is; are you sure they handle MAP_FIXED differently? On Linux, this is not a problem because *without* MAP_FIXED, it will always use the specified address unless there is a conflict with existing mappings. On Solaris, we've implemented a hack that emulates the Linux behaviour in this respect (look at the routine solaris_try_mmap, which is called from wine_anon_mmap). I guess the proper fix would be to implement a similiar BSD specific workaround inside wine_anon_mmap. The Solaris version will probably not work unchanged on BSD, however. If you are correct in your interpretation of the semantics of MAP_FIXED on BSD, a workaround could look like this: first, try mapping with MAP_FIXED; if this fails, repeat without. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

1 0

Re: patch.py?id=1005690229526658676564693 (fwd)
by Gerard Patel 14 Nov '01

14 Nov '01

At 10:10 PM 13/11/2001 -0500, you wrote: >Good day! > >regapi still works. My little winelib program exits with no error, but >leaves a stale socket and does nothing. juno.exe, progman, >I_view32.exe, and Dmitry's little About.exe leave a stuck wine process >and a stale wineserver socket. I expect there is general consternation, >or else it has been fixed already, but I guess I will have to reverse >the patch to see. > general consternation ? Well, I have about 20 test apps and 2 don't start anymore, the rest working as well as before. That's pretty ordinary ;-) I'm not completely sure if the patch is the culprit (I use Cvs and I get several patches at the same time). I don't have the time to investigate further right now. More later. Gerard

2 3

patch.py?id=1005690229526658676564693 (fwd)
by lawson_whitney＠juno.com 14 Nov '01

14 Nov '01

Good day! regapi still works. My little winelib program exits with no error, but leaves a stale socket and does nothing. juno.exe, progman, I_view32.exe, and Dmitry's little About.exe leave a stuck wine process and a stale wineserver socket. I expect there is general consternation, or else it has been fixed already, but I guess I will have to reverse the patch to see. Regards, Lawson ---oof--- ________________________________________________________________ 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/.

2 1

Re: [RFC]: Overlapped I/O implementation
by Mike McCormack 14 Nov '01

14 Nov '01

Hi Martin, >However, I assume you have had good reasons to abaondon the old >server-centric implementation, so I'm reluctant to go that way. Not really. The main reason i did it was because the server is slow and clunky and i thought i'd be able to squeeze a bit of extra performance out of the code by putting it in the client. The best starting point for solving the problems you describe is to revert my patch that put async I/O in the client. i'll even do it if you like... Now who said that premature optimization is the root of all evil? :-) Mike ------------------------------------------ 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

Yet another async I/O issue: block devices
by Martin Wilck 14 Nov '01

14 Nov '01

Hi, I just discovered yet another problem that arises for overlapped I/O on normal disk files, more correctly, for any file on a block device. Obviously IO requests on block devices on Linux are _always blocking_. I wrote a very simple test program for reading from a floppy disk and found exactly this behaviour, no matter if O_NONBLOCK was set or not. "man 2 open" also says that O_NONBLOCK may or may not have any effect on non-socket fd's and for block devices it clearly has none. I don't know the reason for this, but it may have to do with Linux' caching algorithms. This means that - with ReadFile() etc. on regular files, the asynch code will never be executed. Instead, the call will block when trying to read immediately, and then return success. - I am not 100% sure in what context the asynchronous handlers are executed, but the read() write() calls there will be blocking as well. I assume this is not what we want. - I guess that for programs that "know" some IO is going to take a lot of time (read()s on floppies, network file systems, ...) will potentially be broken if they try to do overlapped IO and "do something else" while the IO is executing. I do see the need, therefore, to have an approach that mimics Windows' behaviour here. - The only simple approach that I can see for making this happen is creating a separate thread for reading/writing asynchronous IO. The simplest approach would actually be to do a clone() for each async request with CLONE_FILES | CLONE_VM | CLONE_PARENT. I don't know how this would fit into Wine's general synchronization approach - please give me hints. - The separate thread itself would be very simple for files on block devices, because it can simply execute the blocking read and finish when the read finishes, leaving some status information somewhere. - For other devices that _do_ support O_NONBLOCK, it may be cool to mimic this simple behaviour by clone()ing too, dup() ing the fd, resetting the O_NONBLOCK flag, and doing a blocking IO request just the same. That means to basically leave it up to the kernel to handle synchronization. This would also mean that we wouldn't have to worry about differences between files and sockets/pipes, because I'm 99% sure the kernel would do it right. I don't understand the concept of the wine service thread well enough yet to judge if that could be used for doing what I just suggested. Perhaps someone can help me out with that, I'll be studying the sources in the meantime. Cheers, Martin PS. I guess another possible approach would be using raw I/O, but I am very certain this is not what we want. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

Local USER classes act as global
by Joshua Thielen 14 Nov '01

14 Nov '01

Hello, When I checked out the latest CVS, all the dialog boxes in Finale stopped working (again) . This happened since Alexandre fixed a function call from GetModuleHandleA("USER") to GetModuleHandle16("USER") in my previous GetClassInfo16 patch (thanks Alexnadre!). My patch had worked because GetModuleHandleA returned hInstance 0 for USER and Finale would proceed to register a window class with hInstance 0. Since classes with hInst=0 are treated sort of like global classes in wine, the window class was found. After more investigating, I discovered that in Win16, any window class that is registered with a USER instance handle will be found even if the hInstance passed to the function (GetClassInfo, CreateWindow etv c.) is completely different. This happens even for classes without the CS_GLOBALCLASS style. I have some small test apps if anyone is intrigued by this. Anyway, this patch implements this undocumented bug, uh.. er.. feature in wine and gets Finale working again . Changelog: Local classes registered with USER instance handle now are now found in CLASS_FindClassByAtom. Modified Files: wine/windows/wnd16.c Josh Thielen Index: wine/windows/class.c =================================================================== RCS file: /home/wine/wine/windows/class.c,v retrieving revision 1.42 diff -u -r1.42 class.c --- wine/windows/class.c 2001/11/06 20:57:27 1.42 +++ wine/windows/class.c 2001/11/13 23:23:39 @@ -279,10 +279,14 @@ * NOTES * 980805 a local class will be found now if registred with hInst=0 * and looed up with a hInst!=0. msmoney does it (jsch) + * + * Local class registered with a USER instance handle are found as if + * they were global classes. */ static CLASS *CLASS_FindClassByAtom( ATOM atom, HINSTANCE hinstance ) { - CLASS * class, *tclass=0; + CLASS * class, *tclass = 0, *user_class = 0; + HINSTANCE hUser = GetModuleHandle16("USER"); TRACE("0x%08x 0x%08x\n", atom, hinstance); @@ -293,16 +297,20 @@ if (class->style & CS_GLOBALCLASS) continue; if (class->atomName == atom) { - if (hinstance==class->hInstance || hinstance==0xffff ) + if (hinstance==class->hInstance || hinstance==0xffff) { TRACE("-- found local %p\n", class); return class; } - if (class->hInstance==0) tclass = class; + if (class->hInstance == 0) tclass = class; + else if(class->hInstance == hUser) + { + user_class = class; + } } } - /* Then search global classes */ + /* Then search global classes */ for (class = firstClass; (class); class = class->next) { @@ -312,6 +320,13 @@ TRACE("-- found global %p\n", class); return class; } + } + + /* Check if there was a local class registered with USER */ + if( user_class ) + { + TRACE("--found local USER class %p\n", user_class); + return user_class; } /* Then check if there was a local class with hInst=0*/

1 0

weird linux/solaris problem.
by Roger Fujii 13 Nov '01

13 Nov '01

Well, I finally figured out the major problem I've been having with wine and virtualdub under solaris, but I'm not sure what to do about it. In memory/virtual.c, there are 2 problems: 1) in function anon_mmap_aligned, there is a section that tries to release extra memory. The problem is that under solaris, munmap length parameter is defined as: The munmap() function removes the mappings for pages in the range [addr, addr + len), rounding the len argument up to the next multiple of the page size as returned by sysconf(3C). It's not exactly clear what the linux munmap does, but I think that the linux one does what you think it SHOULD do, and the solaris one does what is documented (i.e. will unmap more pages than what the linux one thinks it would since it rounds UP the len). Now, I can see 2 fixes: 1 is to #ifdef __svr4 and compute the compensated len before unmapping. The other is to just not do this release (or at least not do it for __svr4). Any comments? 2) For some reason I don't quite understand, a call is made to VirtualProtect with a READONLY protection, and soon after, something tries to memcpy into that block. I'm not sure if this is a thread sync issue, or maybe this is supposed to work like c's const (ie, it's readonly AFTER the first write). Kind of puzzling, since it does work under linux. Any suggestions? (my current fix is to treat READONLY as RW, which works, but I know is wrong). Thanks. -r Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

1 0

Re: [RFC]: Overlapped I/O implementation
by Martin Wilck 13 Nov '01

13 Nov '01

Hi Mike, all, I have thought some more. Having understood the problem with the possibly duplicate process fds, it is clear that in order to treat multiple simultaneous requests correctly, there must be some server-side support on a per-IO-object basis. With the current implementation as a guideline, I see only one possibility to do this: The server maintains two semaphores for async reading and writing for each I/O object (file, socket, comm port...) that has the OVERLAPPED flag set. The semaphores have a max count of 1 for FIFOS and some larger number for random-access files (this will be set by object-type-dependent functions). The async_private struct has a Semaphore field. When the client schedules an async request, it gets the suitable semaphore handler (read/write) of the I/O object from the server and stores it in the async_private struct. The async_handler function does not start actual I/O before acquiring the semaphore, and releases it when finished. The handler is in IO_PENDING state until it gets the semaphore and remains in that state after obtining access until it releases the semaphore. This provides a rather elegant framework for limiting the number of concurrent readers and writers. I am not sure, though, if the async_handler functions are allowed to wait for semaphores ??? Perhaps we'd need to use Unix semaphores ? Any other approach I've thought of so far seems to imply a lot of client-server interaction and mangling in the NtCurrentTeb()->pending_list. Please notify me if you have better ideas. The other possible solution would be to go back to the server-centric implementation of 8 months ago, or something similar. Most likely the NtCureentTeb()->pending_list would have to be dropped in that case, and server-side communications used instead. However, I assume you have had good reasons to abaondon the old server-centric implementation, so I'm reluctant to go that way. There is another concern, though. You wrote: > When the thread waits upon any server object, all (unix) fds with > pending overlapped operations are polled on. This is a minor problem > in the design; if the thread never waits upon an object the overlapped > can never complete, however the thread must wait upon the overlapped's > hEvent to check whether it has completed... AFAICS, there will not even be an I/O request unless the client waits on something (at least in ReadFileEx()). I wonder if this can cause the advantages of async IO to be lost if a a long time elapses before the client waits on anything. Definitely, if the first wait the client issues is on the async request itself, the handler will have done nothing in the meantime and there is no real asynchronicity any more. Meanwhile all arriving data must be buffered by the kernel. This is probably no problem on a serial port, but what if you're dealing with a fully loaded ethernet connection or a local socket with a lot of traffic? Anyway, That's probably a minor issue. Please tell me if you think the semaphore idea is feasible. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Pajama Sam audio problems mysteriously gone; Film at eleven
by Ori Pessach 13 Nov '01

13 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In my attempts to figure out which change caused some games not to detect the sound card on my machine, I started checking out historic versions from CVS, building them, and testing whether they work or not. They all worked. All in all, I tested versions from 10/07/2001, the last version I knew worked, to the current CVS version, in a binary search pattern. The games still exhibit the problems I reported earlier - the sound is breaking up, and the colorful cursors don't show up, but at least I have something to debug now. If anybody has any ideas about the sound (waveOut*) that weren't discussed yet, I'd love to hear about them. I'd like to thank everyone for their time, especially Eric, who waded through megabytes of relay messages on what turned out to be a wild goose chase. Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE78JUUzA/uWWyw6uQRAutEAKCs/nb8dqkcoqOxKfonO8B5d5HyUgCgwImR rwT2dIFiZ5Yo7MzODLio2hw= =9RtW -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Regression errors
by Gerard Patel 13 Nov '01

13 Nov '01

At 11:06 AM 10/11/2001 -0500, you wrote: > >Thanks Gerard. I will try it Tuesday. Going out of town till then. Well, I have advanced a bit this weekend. I noticed that one of my test app does indeed show this regression after the patch we are talking about. As the case is a lot more simple than the one I was trying to debug before for this problem, I have been able to understand better what is happening. The problem shows itself in the following case : - invalidating a window - hiding it - deleting it and after that the paint count is > 0. I can make the paint count change correctly with the following change : --- winpos.c.orig Thu Nov 8 01:57:34 2001 +++ winpos.c Mon Nov 12 09:47:08 2001 @@ -883,10 +883,10 @@ if (!(winpos->flags & SWP_SHOWWINDOW) && (winpos->flags & SWP_HIDEWINDOW)) { - WIN_SetStyle( winpos->hwnd, wndPtr->dwStyle & ~WS_VISIBLE ); /* clear the update region */ -// RedrawWindow( winpos->hwnd, NULL, 0, RDW_VALIDATE | RDW_NOFRAME | -// RDW_NOERASE | RDW_NOINTERNALPAINT | RDW_ALLCHILDREN ); + RedrawWindow( winpos->hwnd, NULL, 0, RDW_VALIDATE | RDW_NOFRAME | + RDW_NOERASE | RDW_NOINTERNALPAINT | RDW_ALLCHILDREN ); + WIN_SetStyle( winpos->hwnd, wndPtr->dwStyle & ~WS_VISIBLE ); } else if ((wndPtr->dwStyle & WS_VISIBLE) && !IsRectEmpty( &oldWindowRect ) && IsRectEmpty( &newWindowRect )) Now, I don't know why this RedrawWindow call was commented out :-/ Gerard

2 1

Re: Yet another async I/O issue: block devices
by Mike McCormack 13 Nov '01

13 Nov '01

Hi Martin, Probably better to get the ordered overlappeds working on sockets and serial ports first before trying to perfect block devices. That will bring Wine's feature set inline with Win9x overlapped I/O. I've never had anybody complain that overlapped I/O on block devices doesn't work for any program. Most programs avoid using features that only work on NT... you're likely to find that only NT services use those API calls.... and they won't work on Wine anyhow, seeing we don't support services properly yet. It seems like a good idea to try to make everything perfect from the start, but an incremental approach is usually better. Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi, > >I just discovered yet another problem that arises for overlapped >I/O on normal disk files, more correctly, for any file on a block device. > >Obviously IO requests on block devices on Linux are _always blocking_. >I wrote a very simple test program for reading from a floppy disk and >found exactly this behaviour, no matter if O_NONBLOCK was set or not. >"man 2 open" also says that O_NONBLOCK may or may not have any effect on >non-socket fd's and for block devices it clearly has none. > ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: x11ddraw fix
by Alexandre Julliard 12 Nov '01

12 Nov '01

geschrader <geschrader(a)mediaone.net> writes: > When X11DRV_XF86DGA2_CreatePalette( ) creates the palette > used by X11DRV_DDHAL_DestroyPalette( ) and > X11DRV_DDHAL_SetPalEntries( ), the display which is used is > returned by thread_display( ). This patch makes these two functions > also use thread_display( ) ( rather than gdi_display ). This bug was > causing a BadColor (i.e. invalid colormap) error in the X server > when X11DRV_DDHAL_SetPalEntries( ) was called, followed by > an application crash. I think it would be better to create the palette on the gdi_display, this way it can be manipulated by other threads too. Could you try if this works for you? Index: dlls/x11drv/dga2.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/x11drv/dga2.c,v retrieving revision 1.5 diff -u -r1.5 dga2.c --- dlls/x11drv/dga2.c 2001/09/11 00:32:33 1.5 +++ dlls/x11drv/dga2.c 2001/11/07 20:28:34 @@ -174,8 +174,8 @@ static DWORD PASCAL X11DRV_XF86DGA2_CreatePalette(LPDDHAL_CREATEPALETTEDATA data) { - Display *display = thread_display(); - data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(display, DefaultScreen(display), dga_dev, AllocAll); + data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(gdi_display, DefaultScreen(gdi_display), + dga_dev, AllocAll); if (data->lpColorTable) X11DRV_DDHAL_SetPalEntries(data->lpDDPalette->u1.dwReserved1, 0, 256, data->lpColorTable); @@ -199,10 +199,9 @@ static DWORD PASCAL X11DRV_XF86DGA2_SetPalette(LPDDHAL_SETPALETTEDATA data) { - Display *display = thread_display(); if ((data->lpDDSurface == X11DRV_DD_Primary) && data->lpDDPalette && data->lpDDPalette->u1.dwReserved1) { - TSXDGAInstallColormap(display, DefaultScreen(display), data->lpDDPalette->u1.dwReserved1); + TSXDGAInstallColormap(gdi_display, DefaultScreen(gdi_display), data->lpDDPalette->u1.dwReserved1); } data->ddRVal = DD_OK; return DDHAL_DRIVER_HANDLED; -- Alexandre Julliard julliard(a)winehq.com

3 2

[RFC]: Overlapped I/O implementation
by Martin Wilck 12 Nov '01

12 Nov '01

Hi, I'd like to summarize my thoughts about an implementation of overlapped I/O in Wine that will offer full Windows functionality. I havent't thought it through in all detail, but I have a clear enough picture to write an RFC. I regard the following points as crucial: 1 "Generic" routines like ReadFileEx() need to work with files of almost arbitrary type, i.e. normal files, pipes, sockets, comm ports, ... 2 Different file types imply different semantics for overlapped I/O. In particular: a Files that don't support positioning (i.e. FIFOs, or basically everything except regular files) need to be accessed sequentially, i.e. there may only be one reader and one writer at a time, and these must be scheduled in the same order in which they were submitted by the application. Otherwise, the data read or written will be potentially scrambled. For regular files, on the other hand, spawning several I/O requests in parallel may be beneficial. b Files on some devices (in particular, block devices on Linux) need to spawn a separate thread for the async I/O operation, because I/O on such devices is always blocking, which is undesirable. Neither the process itself nor the service thread should be blocked by a time-consuming floppy I/O operation, for example. 3 The semantics of individual asynchronous I/O requests depend on the function that was called by the application, e.g. ReadFile() or WSARecv(), which take different arguments. Such calls may be mixed by the application, although it's certainly not good programming practice to do so. Based on these arguments, I'd suggest the following: A) The generic functions need to find out what the properties of a file descriptor wrt asynch I/O are. The most general way to implement this is to have an element int (*get_async) (struct object*, struct file_async*) in the obj_ops array. For non-file objects, this element would be NULL or no_get_async(). For non-overlapped file descriptors, the function would assign NULL to the file_async* argument, and return an error, a valid pointer would be assigned to file_async* otherwise. struct file_async would contain per-file information about asynch I/O, e.g. struct file_async { struct async_private *readers; /* list of async read requests */ struct async_private *writers; /* list of async write requests */ int flags /* supports positioning? Is I/O blocking on host OS ? etc. */ int (*get_timeout) (struct object *obj, int type, int count); /* function that returns timeout for device, needed e.g. for serial comm */ } I currently see no need for other file-type dependedent functions; It should be possible to write generic routines that handle the requests correctly according to the flags variable. The Wine server API would containe a file_get_async() request that returns the file_async structure associated with the file by calling the get_async() element of obj_ops. The async_private struct would look pretty similar as it looks now, with a generic part and a part that depends on the function invoked for doing async I/O (e.g. for sockets, whether ReadFile() or WSARecv() was called on the socket fd). IMO the async_private should not contain file type-dependent information which is per-file. It should rather contain a pointer to the respective file_async struct. Most importantly, the async_private struct it carries a pointer to a function that does the actual I/O, and another function pointer that handles the termination of the request (invocation of user completion routine etc.) B) The check_async() function in synchro.c operates on file descriptors rather than async requests. Once an overlapped I/O request is issued by the application, it is queued either in the readers or writers list of the async object (which is obtained from the server). If both the readers and writers lists were NULL beforehand, the fd is inserted into the list for check_async to work on. check_async() activates the first element(s) of both the readers and writers lists (where activate means that the actual read/write call is triggered). For FIFOS, only one element would be activated; for regular files several requests up to a given limit (e.g. 4). If the file is on a device where normal I/O would be blocking, a new thread is created for each activated request to satisfy it. When the requests' I/O routine (separate thread or not) is completed, it activates an event that triggers the generic "finish" routine. The finish routine calls the finish routine of the request, cleans up, and activates a new request if there is one that was queued but not activated. If both the readers and writers queue are empty after finishing the request, the file descriptor is removed from the list of handles to check in check_async(). C) If CancelIo() is called or a file is closed, all pending IO requests are removed from the file's async readers and writers lists; potential subthreads are terminated. With this approach, the wineserver would only be needed for retreiving the file's async I/O properties. The biggest change to the wine core would be the addition of a new function to obj_ops. I am looking forward to comments. Regards, Martin PS. A minor remark: The above approach would make it unnecessary to check for the return value of xyz_get_info() to be FD_TYPE_OVERLAPPED when initiating overlapped I/O. Instead, one could simply check if the async object returned by get_async() is non-NULL. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: GetDlgItem16 - is id signed or not?
by Gerard Patel 12 Nov '01

12 Nov '01

At 07:07 PM 11/11/2001 -0500, you wrote: > >It hasn't gotten itself fixed in the ordinary way of progress, so I have >finally gotten around to a regression in juno-1.49. It crashes just >after getting back 0 from GetDlgItem16, so I added a little trace inside >GetDlgItem. Now I know why it crashes, but I don't know - is id really >unsigned, or is GetControl16 incorrectly failing to extend the sign? >I guess I could try it each way and see which one does least damage, but >probably several of you know which way it is meant to go. I'd cast id to unsigned in GetDlgItem16. Gerard

2 1

Re: Regression errors
by Eric Pouech 12 Nov '01

12 Nov '01

> At 11:06 AM 10/11/2001 -0500, you wrote: > > > >Thanks Gerard. I will try it Tuesday. Going out of town till then. > > Well, I have advanced a bit this weekend. I noticed that one of my > test app does indeed show this regression after the patch we are talking > about. > > As the case is a lot more simple than the one I was trying to debug > before for this problem, I have been able to understand better what > is happening. The problem shows itself in the following case : > > - invalidating a window > - hiding it > - deleting it IIRC, before the big window overhaul (when paint count was attached to each window), when a window was hidden, its paint count wasn't set to 0 (or when the window was actually shown, its paint count wasn't set to 1). This lead to some painting errors... I don't know if this is fully related (and I didn't follow closely the new window stuff), but it may be related... in case this helps... 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.

1 0

Re: More overlapped I/O issues (important)
by Mike McCormack 12 Nov '01

12 Nov '01

Hi Martin, You're right, i never considered multiple overlapped requests at the same time... To fix the problem correctly, you will need to move (some of) the overlapped code back to the wineserver, so that requests from different processes can be handled correctly. (i moved it out of the wineserver about a year ago for efficiency reasons.) Have a look at rev 1.7 of server/async.c to see how this worked. http://cvs.winehq.com/cvsweb/wine/server/async.c?rev=1.7&content-type= text/x-cvsweb-markup The current overlapped code (with the above exception) is similar to what win 9x supports, so it does not support overlapped on normal files, and file offsets in OVERLAPPED structures. If that could be implemented too, it would be good. i guess there is choice now... implement overlapped sockets with the existing structure, or make a rather large change to the wine architecture, which might take a while. Maybe a good first step is to back out my change which put overlapped operations into the client side code... Alexandre thought this could be done using POLLIO instead... Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi Mike, all, > >I see a severe problem with the current overlapped I/O implementation, >especially wrt extending it to Winsock2 overlapped I/O. > >The problem I see is with buffer ordering. > >For normal files, the file position from which to read is on the >OVERLAPPED struct. This was not in the Wine implementation, the patch in >my last email fixes it. > >For sockets and other FIFOs, this makes no sense. In this case Windows >specifies that buffers are read / written **in the same order they were >submitted**. This matters only if users spawn several asynchronous I/O >requests at the same time, but this is allowed and actually beneficial >for application performance (at least on Windows). > >Unless I oversee something essential, the current wine implementation >does not guarantee such behaviour. Actually, since new requests are >inserted at the head of the NtCurrentTeb() list, they will be considered >first in subsequent asynchronous reads - i.e. the order will be reversed. >If I/O requests don't complete in a single read() or write() call, the >ordering will be basically random. > >IMO this implies that for sockets, asynchronous reads and writes must >be scheduled such that only one request for a given socket is actually >reading at a time, and all others are blocked until this request is >finished. Again, this holds only for FIFO-type files. > >With the current structure, it seems to be very complex to sort this out. >One could recheck the fd list in check_async and remove duplicate fds. >One could also try to "lock" the fd somehow. Still it would be necessary >to ascertain that the correct request gets the lock first. > >With this min mind, it seems more natural for me to organize the >asynchronous requests in the "file" data structure itself. One would >have a reader's and a writers's list there, and make sure that for FIFOS >only the first list element can actually issue a read(), write(), send(), >or recv() system call. For normal files all elements in the lists could be >doing IO at the same time, question is if that makes sense or not. > >As I see it, this would mean both the readers and writers lists must >be stored in the file data structure in the wine server. >This would of course strongly affect the current implementation. > >Note that with Winsock2 overlapped I/O in place, it must >be possible to use also ReadFile(), ReadFileEx() etc. on >overlapped sockets, and get correct behaviour. >Thus the ReadFile() etc. code must be able to deal with both sockets >and ordinary files, and it makes no sense to intriduce a different >approach for sockets only. > >Please give me your opinion on these issues ASAP. > >Regards >Martin > >-- >Martin Wilck Phone: +49 5251 8 15113 >Fujitsu Siemens Computers Fax: +49 5251 8 20409 >Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com >D-33106 Paderborn http://www.fujitsu-siemens.com/primergy ------------------------------------------ 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

Loop (and other) problem in audio.c 1.45 located
by Simon Britnell 12 Nov '01

12 Nov '01

The problem is that I advance to the next wavehdr automatically in FeedDSP, which skips the first wavehdr sent to the wodPlayer. Doh! A patch will follow to fix this (which will be built on top of the race condition fix patch). __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

1 0

Re: Winsock2 & overlapped IO
by Mike McCormack 12 Nov '01

12 Nov '01

Hi Martin, Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> >I have taken a closer look at this code. I believe a very similar approach >is possible for Winsock. However, there are a few problems: Good to see you are a man of action, not just words! >typedef struct async_private .. >What do you think about this? > >It would be cleaner to define a "general" async structure >containing either a type-specific union or a pointer to >type-specific data, and using void* for pointers. However, that would >require even more changes in the async file I/O code, which I'd like to >avoid at the moment. i agree with you it would be better to use a union... i'll have a go at making a patch to do this. i'll probably understand the mess i've created in files/file.c more easily ;-) >Another difference is that the overlapped Winsock routines cause >asynchronous success notification (i.e. calling the completion routine or >signalling the lpOverlapped->hEvent) even if they are immediately >successful, which seems not to be the case for asynchronous file I/O. > >That would require a minor change in the check_async_list() routine. Cool, go for it. >Please tell me your opinion! > >Regards, >Martin i wrote a longer reply with a union definition in it, but accidently resized my Netscape window an lost it when the page reloaded :-( Could be about time to give up on this web-based email thing. Mike btw. in the patch in your other mail, you have: -typedef struct _OVERLAPPED * LPWSAOVERLAPPED; typedef HANDLE WSAEVENT; + +typedef struct _WSAOVERLAPPED { + DWORD Internal; + DWORD InternalHigh; + DWORD Offset; + DWORD OffsetHigh; + WSAEVENT hEvent; +} WSAOVERLAPPED, *LPWSAOVERLAPPED; + can you just use the following? typedef OVERLAPPED WSAOVERLAPPED; typedef LPOVERLAPPED LPWSAOVERLAPPED; typedef HANDLE WSAEVENT; or even #define... ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

3 3

GetDlgItem16 - is id signed or not?
by lawson_whitney＠juno.com 12 Nov '01

12 Nov '01

Good day! It hasn't gotten itself fixed in the ordinary way of progress, so I have finally gotten around to a regression in juno-1.49. It crashes just after getting back 0 from GetDlgItem16, so I added a little trace inside GetDlgItem. Now I know why it crashes, but I don't know - is id really unsigned, or is GetControl16 incorrectly failing to extend the sign? I guess I could try it each way and see which one does least damage, but probably several of you know which way it is meant to go. trace:dialog:DIALOG_CreateControls BEGIN trace:dialog:DIALOG_GetControl16 STATIC '' 1164, 12, 4, 232, 45, 50020000, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Get and Send Mail' 1162, 10, 55, 56, 28, 5003000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Just Get Mail' 1163, 70, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON 'Cancel' 1161, 130, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Help' 57669, 190, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_CreateControls END trace:dialog:GetDlgItem GWL_ID 48c id 48a trace:dialog:GetDlgItem GWL_ID 48a id 48a trace:dialog:GetDlgItem GWL_ID 48c id 48b trace:dialog:GetDlgItem GWL_ID 48a id 48b trace:dialog:GetDlgItem GWL_ID 48b id 48b trace:dialog:GetDlgItem GWL_ID 48c id 489 trace:dialog:GetDlgItem GWL_ID 48a id 489 trace:dialog:GetDlgItem GWL_ID 48b id 489 trace:dialog:GetDlgItem GWL_ID 489 id 489 trace:dialog:GetDlgItem GWL_ID 48c id ffffe145 trace:dialog:GetDlgItem GWL_ID 48a id ffffe145 trace:dialog:GetDlgItem GWL_ID 48b id ffffe145 trace:dialog:GetDlgItem GWL_ID 489 id ffffe145 trace:dialog:GetDlgItem GWL_ID e145 id ffffe145 wine: Unhandled exception, starting debugger... Regards, Lawson The Devil finds work for idle minds.

1 0

Latest CVS Wine winmm
by Ori Pessach 10 Nov '01

10 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I tried running Pajama Sam today (a Humongous Entertainment game), which used to run, with some sound problems, a while ago. Now, I get a dialog box on startup, saying that "No sound card was detected". 'wine -debugmsg +wave,+msys' shows multiple instances of the message: trace:mmsys:DriverCallback Null ! - From a quick look at mmsystem.c, it's not immediately clear whether this is a problem or not. At some point later on, I get: err:msacm:wodCallback Bad data But, this only happens after I close the dialog box, so that can't be the cause of the failure. Again, this used to work before. I first tried it with Simon's recent patch, and then checked out current the CVS version of mmsystem.c, and I don't see a difference. Any ideas? I have a complete dump the trace messages, but I'd rather not post it here, since it's fairly big. Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE77KsXzA/uWWyw6uQRApmPAKDOJ5LmmUzwWczXJ/So263BrFR26ACfeLkr SbhwMyhft7A5pmgIO1azzfA= =VyBD -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

3 2

Re: Regression errors
by Gerard Patel 10 Nov '01

10 Nov '01

At 12:38 AM 10/11/2001 -0500, you wrote: >1. SetTimer call is not always generating WM_TIMER messages as it should. I >see: > >0806bb20:Call user32.SetTimer(00020057,00001003,00000000,6003a04c) >ret=6001e9e4 >0806bb20:Ret user32.SetTimer() retval=00001003 ret=6001e9e4 > >in the trace, but never is the callback routine invoked. Without the above >patch, the callback is invoked and does the painting. I am not sure if it's related, but I have seen something like that. I have seen it since much longer than this patch, though. It's about the paint count in the server. When there is a paint count > 0 in the server and the number of windows found to need a repaint (at the client level) is less than the paint count, the client can never get a timer event again. Try this patch to dlls/user/message.c to see if your problem is related : --- message.c.orig Sat Nov 10 07:03:29 2001 +++ message.c Sat Nov 10 07:08:27 2001 @@ -1861,6 +1861,7 @@ USER_Driver.pMsgWaitForMultipleObjectsEx( 0, NULL, 0, 0, 0 ); hwnd = WIN_GetFullHandle( hwnd ); +yetanothergoto: locks = WIN_SuspendWndsLock(); if (!MSG_peek_message( &msg, hwnd, first, last, @@ -1884,8 +1885,19 @@ /* need to fill the window handle for WM_PAINT message */ if (msg.message == WM_PAINT) { - if (!(msg.hwnd = WIN_FindWinToRepaint( hwnd ))) return FALSE; - + if (!(msg.hwnd = WIN_FindWinToRepaint( hwnd ))) + { + TRACE("FIXME : server paint count > 0 but no window needs painting\n"); + SERVER_START_REQ( inc_queue_paint_count ) + { + req->id = (void *)GetWindowThreadProcessId( hwnd, NULL ); + if (!req->id) req->id = (void *)GetCurrentThreadId(); + req->incr = -100000; /* reset paint count */ + SERVER_CALL(); + } + SERVER_END_REQ; + goto yetanothergoto; + } if (IsIconic( msg.hwnd ) && GetClassLongA( msg.hwnd, GCL_HICON )) { msg.message = WM_PAINTICON; I have no idea about your second problem. Gerard

2 1

Help with Revelant demo
by Paul Millar 10 Nov '01

10 Nov '01

Hi, [I'm prefacing this by saying know next to nothing about Windows] I've had a quick go at getting the (newer) demo of Eidos' Revenant game to run. The install works ok, but when I try to run the demo, I get a msgbox saying: "FATAL ERROR", "Unable to initialize Network" and the following appearing on stderr: > fixme:ole:CoCreateInstance no classfactory created for > {2fe8f810-b2a5-11d0-a787-0000f803abfc}, hres is 0x80040154 Rerunning with the "-debugmsg +ole" option, I get some (not terribly useful) extra info: > trace:ole:OLE32_DllEntryPoint 0x4087b000 0x1 0x1 > trace:ole:CoInitializeEx ((nil), 2) > trace:ole:CoInitializeEx () - Initializing the COM libraries > trace:ole:RunningObjectTableImpl_Initialize () > trace:ole:WINE_StringFromCLSID > 0x5a27f8->{2FE8F810-B2A5-11D0-A787-0000F803ABFC} > trace:ole:CoGetClassObject > CLSID: {2fe8f810-b2a5-11d0-a787-0000f803abfc}, > IID: {00000001-0000-0000-c000-000000000046} > fixme:ole:CoCreateInstance no classfactory created for > {2fe8f810-b2a5-11d0-a787-0000f803abfc}, hres is 0x80040154 > trace:ole:OLE32_DllEntryPoint 0x4087b000 0x0 0x1 I did a Google search and "2fe8f810-b2a5-11d0-a787-0000f803abfc" seems to be the CLSID of DirectPlayLobby. On a seperate note, I can't figure out which bit (or lack) of WINE is causing the "network error". From what I can see, there doesn't seem to be any network activity as rerunning with "-debugmsg +wnet,+winsock" doesn't produce any extra output. FWIW, there is an .INI file with the following: > [Network] > ConnectType=none > SessionName=none > Provider=IPX > ConnectTime=5 So my questions are: 1. How easy would it be to fix/add CLSID_DirectPlayLobby? (where do I start)? 2. Any suggestions how to go about debugging the apparently fatal "No Network" msgbox? Cheers, Paul. ------------------------------------------------------------------------------ Paul Millar yo-yo, n. : Particle Physics Theory Group Something that is occasionally Department of Physics and Astronomy up but normally down. University of Glasgow, (see also Computer) Glasgow G12 8QQ, paulm(a)physics.gla.ac.uk Scotland +44 (0)141 330 4717 ------------------------------------------------------------------------------

1 0

Regression errors
by Guy L. Albertelli 10 Nov '01

10 Nov '01

I have noticed two other regression issues with the patch to "Store in the server all the window info... " (01/10/22 15:08:34). Both of these occur in Outlook Express 4. 1. SetTimer call is not always generating WM_TIMER messages as it should. I see: 0806bb20:Call user32.SetTimer(00020057,00001003,00000000,6003a04c) ret=6001e9e4 0806bb20:Ret user32.SetTimer() retval=00001003 ret=6001e9e4 in the trace, but never is the callback routine invoked. Without the above patch, the callback is invoked and does the painting. 2. A WM_KEYUP (wparam is VK_CNTL) message is generated and processed even though no key is touched on the keyboard. If "-debugmsg +key" is specified the message never appears, nor does any trace:key: entry. Has anybody else seen or trapped these bugs? Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Re: fix for ugly things...
by Francois Gouget 09 Nov '01

09 Nov '01

On Fri, 9 Nov 2001, Andreas Mohr wrote: > [ok, mailed for the *3rd* time now, since WineHQ has been out of space *again*] > > Hi all, > > - fix potentially problematic stuff (see Apple installer desaster, e.g. on /.) [...] That's good but while you're at it I think you should fix the other things like: Index: documentation/db2html-winehq [...] cat $TMPDIR/* Index: documentation/make_winehq [...] mv $WWWDIR $WWWDIR.old [...] mkdir $WWWDIR Otherwise the scripts will still not work and make a mess (even if data loss is less likely, unless we also have 'cmd... >$xxx'). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

1 0

Re: OSS audio race fix
by eric pouech 09 Nov '01

09 Nov '01

eric pouech wrote: > > as reported by Simon Brunnel oops... I meant Britnell (sorry for the misspell Simon) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

More overlapped I/O issues (important)
by Martin Wilck 09 Nov '01

09 Nov '01

Hi Mike, all, I see a severe problem with the current overlapped I/O implementation, especially wrt extending it to Winsock2 overlapped I/O. The problem I see is with buffer ordering. For normal files, the file position from which to read is on the OVERLAPPED struct. This was not in the Wine implementation, the patch in my last email fixes it. For sockets and other FIFOs, this makes no sense. In this case Windows specifies that buffers are read / written **in the same order they were submitted**. This matters only if users spawn several asynchronous I/O requests at the same time, but this is allowed and actually beneficial for application performance (at least on Windows). Unless I oversee something essential, the current wine implementation does not guarantee such behaviour. Actually, since new requests are inserted at the head of the NtCurrentTeb() list, they will be considered first in subsequent asynchronous reads - i.e. the order will be reversed. If I/O requests don't complete in a single read() or write() call, the ordering will be basically random. IMO this implies that for sockets, asynchronous reads and writes must be scheduled such that only one request for a given socket is actually reading at a time, and all others are blocked until this request is finished. Again, this holds only for FIFO-type files. With the current structure, it seems to be very complex to sort this out. One could recheck the fd list in check_async and remove duplicate fds. One could also try to "lock" the fd somehow. Still it would be necessary to ascertain that the correct request gets the lock first. With this min mind, it seems more natural for me to organize the asynchronous requests in the "file" data structure itself. One would have a reader's and a writers's list there, and make sure that for FIFOS only the first list element can actually issue a read(), write(), send(), or recv() system call. For normal files all elements in the lists could be doing IO at the same time, question is if that makes sense or not. As I see it, this would mean both the readers and writers lists must be stored in the file data structure in the wine server. This would of course strongly affect the current implementation. Note that with Winsock2 overlapped I/O in place, it must be possible to use also ReadFile(), ReadFileEx() etc. on overlapped sockets, and get correct behaviour. Thus the ReadFile() etc. code must be able to deal with both sockets and ordinary files, and it makes no sense to intriduce a different approach for sockets only. Please give me your opinion on these issues ASAP. Regards Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

[PATCH:] fix overlapped I/O problems
by Martin Wilck 09 Nov '01

09 Nov '01

Hi, The included patch (against CVS 2001-11-08) fixes two problems with overlapped I/O: 1) Overlapped ReadFile() didn't work on normal files because file_get_info() never returned FD_TYPE_OVERLAPPED. 2) According to the MS docs, the lpOverlapped argument's Offset and OffsetHigh fields contain the offset from which to read. This was not honoured by the current implementation which only did sequential reads. Regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy Index: files/file.c =================================================================== RCS file: /home/wine/wine/files/file.c,v retrieving revision 1.119 diff -u -r1.119 file.c --- files/file.c 2001/10/24 00:23:25 1.119 +++ files/file.c 2001/11/09 17:35:29 @@ -1275,6 +1275,7 @@ { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; + off_t ofs; TRACE("%p %p %08x\n", lpOverlapped, ovp->buffer, events ); @@ -1294,9 +1295,18 @@ goto async_end; } + ofs = lpOverlapped->Offset + ((off_t)lpOverlapped->OffsetHigh << 32) + + lpOverlapped->InternalHigh; + /* check to see if the data is ready (non-blocking) */ - result = read(ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], - ovp->count - lpOverlapped->InternalHigh); + /* Use the offset as given in the Overlapped structure */ + result = pread (ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], + ovp->count - lpOverlapped->InternalHigh, ofs); + + /* If pread fails, try a normal read */ + if (result == -1 && errno == ESPIPE) + result = read (ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], + ovp->count - lpOverlapped->InternalHigh); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1444,6 +1454,7 @@ { int unix_handle, result; DWORD type; + off_t ofs; TRACE("%d %p %ld %p %p\n", hFile, buffer, bytesToRead, bytesRead, overlapped ); @@ -1466,7 +1477,11 @@ } /* see if we can read some data already (this shouldn't block) */ - result = read( unix_handle, buffer, bytesToRead ); + ofs = overlapped->Offset + ((off_t)overlapped->OffsetHigh << 32); + /* Try using the user-given offset first, fall back to read otherwise */ + result = pread( unix_handle, buffer, bytesToRead, ofs); + if (result == -1 && errno == ESPIPE) + result = read( unix_handle, buffer, bytesToRead ); close(unix_handle); if(result<0) Index: server/file.c =================================================================== RCS file: /home/wine/wine/server/file.c,v retrieving revision 1.48 diff -u -r1.48 file.c --- server/file.c 2001/10/24 00:23:26 1.48 +++ server/file.c 2001/11/09 17:35:29 @@ -307,6 +307,10 @@ req->index_low = st.st_ino; req->serial = 0; /* FIXME */ } + + if (file->flags & FILE_FLAG_OVERLAPPED) + return FD_TYPE_OVERLAPPED; + return FD_TYPE_DEFAULT; }

1 0

queries on internals...
by Roger Fujii 09 Nov '01

09 Nov '01

ok... getting reasonable output, but now I have some questions. First, it seems like wine can't find the audio codecs, though it seems to find the video ones. Is this a to-be-implemented or a bug and any clues on where to look? The next are portability / solaris questions... 1) For some unknown reason, the solaris version segfaults when it tries to load win87em.dll, but the linux one doesn't. I presume that this is trying to load the fpu emulator, but I'm not certain. In any case, what controls the loading of this in the first place? 2) regapi uses strsep, which solaris doesn't have. Is its usage in wine compatible with strtok, or should I cut/paste strsep into library/ports.c? 3) In win32/console.c, it seems that master/slave is reversed through the fork. This is only going off the docs, but if it is, how is this working under linux? That's all for now.... -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

4 8

Need suggestions for audio patch testing.
by Simon Britnell 09 Nov '01

09 Nov '01

I've posted my patch against wine cvs audio.c 1.44 to wine patches, but I've not yet been able to give it a thorough test. Anyone using freeware/shareware/opensource programs with sound under wine (not winex) please send me URLs for the programs you use (specially if they break) so I can use them for testing my patch. Thanks. __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

1 0

Re: Two answers/questions from yesterdays and todays digests
by Roger Fujii 08 Nov '01

08 Nov '01

Robert Lunnon <bob(a)yarrabee.net.au> wrote: > >First, it seems like wine can't find the audio codecs, > >though it seems to find the video ones. Is this a > >to-be-implemented or a bug and any clues on where to look? > > Is this in Solaris ?, yes. > if so you wiould have to have OSS installed and even > then I am not sure it would work properly. I do have OSS installed (like Sun gives you a choice as far as audio drivers go), and it doesn't. > Investigating audio on Solaris I found that ACM was not happy unless > the audio driver was available and installed properly otherwise it > returns Device Busy. I know there is a problem with 4front's devaudio emulation such that it will return an EBUSY if you open the device for READ and then WRITE (but it doesn't fail for WRITE, then READ) - they're too busy to fix the problem. > I do have a working > Waveout Solution for native Solaris based on my libaudioio project. I've not > tackled Direct Sound or Wavein yet. As yet this solution is not integrated > with Wines Build environment so you can't set it up with configure. If you > are prepared to grub through the relevant mods I can send you a patch kit. > actually, my main interest is to get the compressor(s) to work - don't care too much currently to get the audio working (mainly due to the fact that the audio drivers in solx86 is in such a sorry state). I'll be interested once I get the current CVS to work again. -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

1 0

Re: Winsock2 & overlapped IO
by Mike McCormack 08 Nov '01

08 Nov '01

Hi Martin, i don't know much about Winsock, but i can tell you how overlapped I/O is supposed to work in Wine. The bulk of the implementation is in files/file.c and scheduler/synchro.c. When ReadFile is called on a handle, the following happens: 1. check that the handle is valid and was opened with FILE_FLAG_OVERLAPPED. 2. attempt to read any data that is available immediately, and perhaps return if we read enough already. 3. queue the operation onto CurrentTeb()->pending_list When the thread waits upon any server object, all (unix) fds with pending overlapped operations are polled on. This is a minor problem in the design; if the thread never waits upon an object the overlapped can never complete, however the thread must wait upon the overlapped's hEvent to check whether it has completed... The only part of the serial comms overlapped implementation the lives in the wineserver is the calculation of overlapped timeouts. So to get winsock to do overlapped, you may have to modify the winsock code to work like that... but the winsock code uses the service thread to wait upon sockets. The task is definitely not impossible, but it might take a bit of work :-) Maybe Ove K. can give you some advice? Mike > In particular, it uses the Winsock 2 feature of "Overlapped IO" > on sockets, with user-supplied callbacks that are called when > data is received on a socket etc. > > Browsing through the Wine Winsock code, I saw that this part of > Winsock2 is obviously unimplemented. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

3 2

Re: audio.c cleanup
by Alexandre Julliard 08 Nov '01

08 Nov '01

Simon Britnell <ughbash(a)yahoo.com> writes: > This patch is based on winex cvs 1.14 and tidys up the > wodPlayer functionality to make it easier to follow. The WineX tree is not under the Wine license, so you cannot grab stuff from there. While I guess the Transgaming folks wouldn't object in this case, I'd prefer that you leave it to them to submit their patches back to the main tree, so that the license situation is clear. -- Alexandre Julliard julliard(a)winehq.com

2 1

wineshelllink
by Johan Gill 08 Nov '01

08 Nov '01

Are there any known issues with wineshelllink and KDE1 at the moment? It seems quite a few of my install programs hang when the shortcuts are about to be put in place. /Johan Gill, johane(a)lysator.liu.se

1 0

Re: Extra info in scrollbar can be an handle.
by Alexandre Julliard 08 Nov '01

08 Nov '01

Marco Bizzarri <m.bizzarri(a)icube.it> writes: > The included patch solves the problem by making an explicit GlobalLock, > and returning that value. I'm not sure this is the correct solution, so > comments are welcome. If you want to GlobalLock it, it should be allocated by GlobalAlloc. Plus the block layout will have to be compatible with what the app expects. Could you check what the app does with the memory block? Also what kind of brain-damaged app is this? -- Alexandre Julliard julliard(a)winehq.com

2 1

Two answers/questions from yesterdays and todays digests
by Robert Lunnon 08 Nov '01

08 Nov '01

Answers Now... >Message: 1 >Date: Tue, 06 Nov 2001 12:53:56 -0500 >From: Roger Fujii <rmf(a)lookhere.com> >To: wine-devel(a)winehq.com >Subject: queries on internals.... > >ok... getting reasonable output, but now I have some >questions. > >First, it seems like wine can't find the audio codecs, >though it seems to find the video ones. Is this a >to-be-implemented or a bug and any clues on where to look? Is this in Solaris ?, if so you wiould have to have OSS installed and even then I am not sure it would work properly. Investigating audio on Solaris I found that ACM was not happy unless the audio driver was available and installed properly otherwise it returns Device Busy. I do have a working Waveout Solution for native Solaris based on my libaudioio project. I've not tackled Direct Sound or Wavein yet. As yet this solution is not integrated with Wines Build environment so you can't set it up with configure. If you are prepared to grub through the relevant mods I can send you a patch kit. > Message: 1 > Date: Wed, 7 Nov 2001 20:50:11 +0100 > From: Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> > To: Francois Gouget <fgouget(a)free.fr> > Cc: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com>, > wine-devel mailing list <wine-devel(a)winehq.com> > Subject: Re: [EXPERIMENTAL PATCH]: Winsock2 > Reply-To: andi(a)rhlx01.fht-esslingen.de > > On Wed, Nov 07, 2001 at 10:54:02AM -0800, Francois Gouget wrote: > > * To answer your question: > > /* Code copied largely from WSOCK32_accept() */ > > /* FIXME: Can we simply call WSOCK32_accept() instead ? */ > > /* I wasn't sure because of the AsyncSelect stuff at the end, > > which presumably should only be called if the connection is > > accepted */ > > > > Winsock2 should not call the wsock32 library. It should be the > > opposite. One of the things on my todo list (but whether I will have > > time to actually do it is another matter) is to reorganize the winsock > > libraries so that wsock32 and winsock are together in dlls/wsock32. The > > reason is that they both implement the winsock1 API except one is 16bit > > and the other 32bits. Then in dlls/winsock we would be left with just > > ws2_32 which implements the winsock2 API. So having ws2_32 call to > > wsock32 is not going in the right direction :-) > > Hmm ? > Sorry, but this directory stuff sounds rather dainbread to me. > IMHO winsock/wsock32 should be in winsock/, and ws2_32 should be in > winsock2/ Or, maybe even better, use winsock1/ instead of winsock/. > > WTH would you want to do it in a different way ? Whoever is playing with Winsock can you please ensure that the solutions you come up with are not linux centric. There is a lot of code in there that does not run on solaris because it grubs around in PROC getting TCP structures. I have made a bit of a start in cleaning this up, Here it is, absolutely untested non working code, but a start nevertheless, I put this into a separate file and link it with winsock and wsock32 from a common source, these functions replace the helper functions of similar name in the two dll subdirectories.

1 0

Re: File record locking (exclusive, nowait)
by eric pouech 08 Nov '01

08 Nov '01

"Medland, Bill" wrote: > > <<diff29.txt>> didn't you forget to add the server/fd.c file ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

linking in .lib files
by Chris Dawson 08 Nov '01

08 Nov '01

Is it possible to link in .lib files using winelib and winemaker? If possible, what switch do I give winemaker? My application when compiled under Windows linked in a .lib file and I would rather not modify the source code. I've tried using the -l switch, but this is obviously only for *nix libraries even when compiling with winelib. Or, other suggestions to resolve all the undefined reference errors? Thanks in advance, Chris

3 4

[PROBLEM REPORT] Focus problem for mdi children
by Gerard Patel 08 Nov '01

08 Nov '01

Mdi child window activation is broken since ChangeSet ID: 10050857000162942344322801 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard@wine2. 01/11/06 17:28:20 Modified files: dlls/ttydrv : wnd.c dlls/x11drv : winpos.c include : winpos.h windows : message.c winpos.c Log message: Window activation cleanups. The change that broke it is : --- /opt/cvs-commit/wine/dlls/x11drv/winpos.c 2001/10/22 19:08:34 1.31 +++ /opt/cvs-commit/wine/dlls/x11drv/winpos.c 2001/11/06 22:28:19 1.32 @@ -955,8 +955,7 @@ ShowCaret(winpos->hwnd); } - if (!(winpos->flags & SWP_NOACTIVATE)) - WINPOS_ChangeActiveWindow( winpos->hwnd, FALSE ); + if (!(winpos->flags & SWP_NOACTIVATE)) SetActiveWindow( winpos->hwnd ); /* And last, send the WM_WINDOWPOSCHANGED message */ Cause of the problem : the WM_CHILDACTIVATE message is not sent anymore, so the mdi children are not activated (caption does not change color, more annoyingly the active child is not set). The problem can be seen with Eudora or ForteFreeAgent. Using this patch : --- winpos.c.orig Wed Nov 7 10:41:32 2001 +++ winpos.c Thu Nov 8 00:44:29 2001 @@ -955,7 +955,20 @@ ShowCaret(winpos->hwnd); } - if (!(winpos->flags & SWP_NOACTIVATE)) SetActiveWindow( winpos->hwnd ); + if (!(winpos->flags & SWP_NOACTIVATE)) + { + SetActiveWindow( winpos->hwnd ); + if (!(wndPtr = WIN_FindWndPtr(winpos->hwnd))) return FALSE; + + /* child windows get WM_CHILDACTIVATE message */ + if( (wndPtr->dwStyle & (WS_CHILD | WS_POPUP)) == WS_CHILD ) + { + WIN_ReleaseWndPtr(wndPtr); + SendMessageA(winpos->hwnd, WM_CHILDACTIVATE, 0, 0L); + } + else + WIN_ReleaseWndPtr(wndPtr); + } /* And last, send the WM_WINDOWPOSCHANGED message */ seems to fix the problem. It may be too simple though :-) Gerard

1 0

Re: [PROBLEM REPORT] Focus problem for mdi children
by Alexandre Julliard 08 Nov '01

08 Nov '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > Using this patch : > --- winpos.c.orig Wed Nov 7 10:41:32 2001 > +++ winpos.c Thu Nov 8 00:44:29 2001 > @@ -955,7 +955,20 @@ > ShowCaret(winpos->hwnd); > } > > - if (!(winpos->flags & SWP_NOACTIVATE)) SetActiveWindow( winpos->hwnd ); > + if (!(winpos->flags & SWP_NOACTIVATE)) > + { > + SetActiveWindow( winpos->hwnd ); > + if (!(wndPtr = WIN_FindWndPtr(winpos->hwnd))) return FALSE; > + > + /* child windows get WM_CHILDACTIVATE message */ > + if( (wndPtr->dwStyle & (WS_CHILD | WS_POPUP)) == WS_CHILD ) > + { > + WIN_ReleaseWndPtr(wndPtr); > + SendMessageA(winpos->hwnd, WM_CHILDACTIVATE, 0, 0L); > + } > + else > + WIN_ReleaseWndPtr(wndPtr); > + } > > /* And last, send the WM_WINDOWPOSCHANGED message */ > > > seems to fix the problem. It may be too simple though :-) No actually it's pretty much the right thing. I have applied a slightly simplified version of your patch, thanks for the report. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: RtlNtStatusToDosError issue
by Alexandre Julliard 07 Nov '01

07 Nov '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > What is the correct solution? To choose a status at random that translates > to ERROR_LOCK_VIOLATION? Yes. (but it's OK to pick one that makes some sense ;-) -- Alexandre Julliard julliard(a)winehq.com

1 0

RtlNtStatusToDosError issue
by Bill Medland 07 Nov '01

07 Nov '01

Can I solve this through documentation or do I have to use debug? I am implementing the LockFile stuff based on what Alexandre did to the CorelWine last year. Currently I have it returning error codes such as ERROR_LOCK_VIOLATION. However that causes RtlNtStatusToDosError to complain about not recognising it (no big surprise) during the server call. What is the correct solution? To choose a status at random that translates to ERROR_LOCK_VIOLATION? Bill

1 0

What's happened to www.winehq.com/ident
by Bill Medland 07 Nov '01

07 Nov '01

Anyone know what has happened to the LXR stuff? I used to use it to find where files are implemented but now the symbols don't seem to be indexed any longer. Bill

1 0

[EXPERIMENTAL PATCH]: Winsock2
by Martin Wilck 07 Nov '01

07 Nov '01

Hi, this patch tries to implement a small part of the extended Winsock 2 functionality in Wine. It is very experimental, I have only made sure everything compiles. It is _NOT_ intended for people to try and run. I am submitting this patch because I am pretty new to Wine hacking and I'd appreciate some Wine gurus to audit this for obvious stupidity, style incompatiblities, etc. Features implemented: - WSAAccept(), including callback functionality. - WSASocket(): support for dwFlags parameter. The real difficult stuff will follow when I start looking into WSARecv(), WSASend(), and WSAGetOverlappedResults(). Thus it'd be nice if someone pointed out my misconceptions before I put real work into the latter. Thanks & regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy Index: dlls/winsock/socket.c =================================================================== RCS file: /home/wine/wine/dlls/winsock/socket.c,v retrieving revision 1.65 diff -u -r1.65 socket.c --- dlls/winsock/socket.c 2001/10/14 16:25:47 1.65 +++ dlls/winsock/socket.c 2001/11/07 16:36:53 @@ -154,6 +154,7 @@ int WS_dup_pe(struct protoent* p_pe, int flag); int WS_dup_se(struct servent* p_se, int flag); int WINAPI WSOCK32_getpeername(SOCKET s, ws_sockaddr *name, int *namelen); +int WINAPI WSOCK32_getsockname(SOCKET s, ws_sockaddr *name, int *namelen); typedef void WIN_hostent; typedef void WIN_protoent; @@ -938,6 +939,131 @@ } /*********************************************************************** + * WSAAccept (WS2_32.26) + */ +SOCKET WINAPI WSAAccept(SOCKET s, + ws_sockaddr* addr, + LPINT addrlen32, + LPCONDITIONPROC cond_cb, + DWORD cb_data ) +{ + + /* Code copied largely from WSOCK32_accept() */ + /* FIXME: Can we simply call WSOCK32_accept() instead ? */ + /* I wasn't sure because of the AsyncSelect stuff at the end, + which presumably should only be called if the connection is accepted */ + + SOCKET as; + int fd = _get_sock_fd(s); + unsigned omask; + + TRACE("%04x cond=%08x data=%08x\n", (UINT16) s, (UINT) cond_cb, (UINT) cb_data); + + if (fd == -1) + { + SetLastError(WSAENOTSOCK); + return INVALID_SOCKET; + } + + if (_is_blocking(s)) + { + /* block here */ + do_block(fd, 5); + _sync_sock_state(s); /* let wineserver notice connection */ + /* retrieve any error codes from it */ + SetLastError(_get_sock_error(s, FD_ACCEPT_BIT)); + /* FIXME: care about the error? */ + } + + close(fd); + + SERVER_START_REQ( accept_socket ) + { + req->lhandle = s; + req->access = GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE; + req->inherit = TRUE; + set_error( SERVER_CALL() ); + as = (SOCKET)req->handle; + } + SERVER_END_REQ; + + if (!as) + { + SetLastError(WSAENOTSOCK); + return INVALID_SOCKET; + } + + if (cond_cb) + { + /* We need our own buffers for Caller and Callee addresses. */ + /* FIXME: large enough / too large ? */ + const int SOCKADDR_LEN=128; + INT caller_len = SOCKADDR_LEN, callee_len = SOCKADDR_LEN; + char _caller_addr[SOCKADDR_LEN], _callee_addr[SOCKADDR_LEN]; + ws_sockaddr *caller_addr = (ws_sockaddr*) _caller_addr; + ws_sockaddr *callee_addr = (ws_sockaddr*) _callee_addr; + WSABUF caller_buf = { 0, _caller_addr }; + WSABUF callee_buf = { 0, _callee_addr }; + WSABUF callee_data_buf = { 0, NULL }; + GROUP group = 0; + int cb_result; + + WSOCK32_getpeername (as, caller_addr, &caller_len); + WSOCK32_getsockname (as, callee_addr, &callee_len); + caller_buf.len = caller_len; + callee_buf.len = callee_len; + + TRACE ("Calling callback\n"); + cb_result = cond_cb (&caller_buf, /* Caller ID */ + NULL, /* Caller data unsupported */ + NULL, NULL, /* QOS unsupported */ + &callee_buf, /* Callee id */ + &callee_data_buf, /* Callee data unsupported */ + &group, /* Group unsupported */ + cb_data); + + switch (cb_result) + { + case CF_ACCEPT: + TRACE ("Connection accepted\n"); + break; + case CF_REJECT: + closesocket (as); + TRACE ("Connection refused\n"); + SetLastError (WSAECONNREFUSED); + return INVALID_SOCKET; + case CF_DEFER: + TRACE ("Connection deferred\n"); + SERVER_START_REQ (set_socket_deferred) + { + req->handle = s; + req->deferred = as; + SERVER_CALL (); + } + SERVER_END_REQ; + SetLastError (WSATRY_AGAIN); + return INVALID_SOCKET; + default: + WARN ("Invalid return value\n"); + SetLastError (WSAEINVAL); + return INVALID_SOCKET; + } + + if (addrlen32 && addr && *addrlen32 >= caller_len) + memcpy (addr, caller_addr, caller_len); + + } else + WSOCK32_getpeername (as, addr, addrlen32); + + omask = _get_sock_mask( s ); + if (omask & FD_WINE_SERVEVENT) + ws2_async_accept(s, as); + + return as; +} + + +/*********************************************************************** * bind (WS2_32.2) */ int WINAPI WSOCK32_bind(SOCKET s, const ws_sockaddr* name, int namelen) @@ -1016,7 +1142,21 @@ */ INT WINAPI WSOCK32_closesocket(SOCKET s) { + SOCKET deferred; TRACE("socket %08x\n", s); + + /* Close a deferred socket if present */ + SERVER_START_REQ ( get_socket_deferred ) + { + req->handle = s; + SERVER_CALL (); + deferred = req->deferred; + } + SERVER_END_REQ; + + if (deferred) + WSOCK32_closesocket (deferred); + if (CloseHandle(s)) return 0; return SOCKET_ERROR; } @@ -2898,10 +3038,24 @@ g, dwFlags) are ignored. */ - TRACE("af=%d type=%d protocol=%d protocol_info=%p group=%d flags=0x%lx\n", + SOCKET s; + + TRACE("af=%d type=%d protocol=%d protocol_info=%p group=%d flags=0x%lx\n", af, type, protocol, lpProtocolInfo, g, dwFlags ); - return ( WSOCK32_socket (af, type, protocol) ); + s = WSOCK32_socket (af, type, protocol); + + if (dwFlags && s != INVALID_SOCKET) + { + SERVER_START_REQ ( set_socket_flags ) + { + req->handle = s; + req->flags = dwFlags; + SERVER_CALL(); + } + SERVER_END_REQ; + } + return s; } Index: dlls/winsock/ws2_32.spec =================================================================== RCS file: /home/wine/wine/dlls/winsock/ws2_32.spec,v retrieving revision 1.13 diff -u -r1.13 ws2_32.spec --- dlls/winsock/ws2_32.spec 2001/10/02 17:46:59 1.13 +++ dlls/winsock/ws2_32.spec 2001/11/07 16:36:53 @@ -38,7 +38,7 @@ 23 stdcall socket(long long long) WSOCK32_socket 24 stdcall WSApSetPostRoutine(ptr) WSApSetPostRoutine 25 stub WPUCompleteOverlappedRequest -26 stub WSAAccept +26 stdcall WSAAccept(long ptr ptr ptr long) WSAAccept 27 stub WSAAddressToStringA 28 stub WSAAddressToStringW 29 stdcall WSACloseEvent(long) WSACloseEvent Index: include/winsock2.h =================================================================== RCS file: /home/wine/wine/include/winsock2.h,v retrieving revision 1.10 diff -u -r1.10 winsock2.h --- include/winsock2.h 2001/10/02 17:46:59 1.10 +++ include/winsock2.h 2001/11/07 16:36:54 @@ -225,10 +225,44 @@ CHAR* buf; } WSABUF, *LPWSABUF; -typedef struct _OVERLAPPED * LPWSAOVERLAPPED; typedef HANDLE WSAEVENT; + +typedef struct _WSAOVERLAPPED { + DWORD Internal; + DWORD InternalHigh; + DWORD Offset; + DWORD OffsetHigh; + WSAEVENT hEvent; +} WSAOVERLAPPED, *LPWSAOVERLAPPED; + +#define WSA_IO_PENDING (WSAEWOULDBLOCK) +#define WSA_IO_INCOMPLETE (WSAEWOULDBLOCK) +#define WSA_INVALID_HANDLE (WSAENOTSOCK) +#define WSA_INVALID_PARAMETER (WSAEINVAL) +#define WSA_NOT_ENOUGH_MEMORY (WSAENOBUFS) +#define WSA_OPERATION_ABORTED (WSAEINTR) + +#define WSA_INVALID_EVENT ((WSAEVENT)NULL) +#define WSA_MAXIMUM_WAIT_EVENTS (MAXIMUM_WAIT_OBJECTS) +#define WSA_WAIT_FAILED ((DWORD)-1L) +#define WSA_WAIT_EVENT_0 ((DWORD)0) +#define WSA_WAIT_TIMEOUT ((DWORD)0x102L) +#define WSA_INFINITE ((DWORD)-1L) + +/* + * WinSock 2 extension -- manifest constants for WSASocket() + */ +#define WSA_FLAG_OVERLAPPED 0x01 +#define WSA_FLAG_MULTIPOINT_C_ROOT 0x02 +#define WSA_FLAG_MULTIPOINT_C_LEAF 0x04 +#define WSA_FLAG_MULTIPOINT_D_ROOT 0x08 +#define WSA_FLAG_MULTIPOINT_D_LEAF 0x10 + typedef unsigned int GROUP; +/* FIXME: We don't support QOS */ +typedef DWORD QOS, *LPQOS; + typedef void CALLBACK (*LPWSAOVERLAPPED_COMPLETION_ROUTINE) ( DWORD dwError, @@ -237,7 +271,27 @@ DWORD dwFlags ); +/* + * WinSock 2 extension -- manifest constants for return values of the condition function + */ +#define CF_ACCEPT 0x0000 +#define CF_REJECT 0x0001 +#define CF_DEFER 0x0002 +/* FIXME: The lpCallerData / lpCalleeData arguments are unsupported */ +typedef int CALLBACK (*LPCONDITIONPROC) +( + LPWSABUF lpCallerId, + LPWSABUF lpCallerData, + LPQOS lpSQOS, + LPQOS lpGQOS, + LPWSABUF lpCalleeId, + LPWSABUF lpCalleeData, + GROUP *g, + DWORD dwCallbackData +); + + /* Function declarations */ int WINAPI WSAEnumNetworkEvents(SOCKET s, WSAEVENT hEventObject, LPWSANETWORKEVENTS lpNetworkEvents); int WINAPI WSAEventSelect(SOCKET s, WSAEVENT hEventObject, long lNetworkEvents); @@ -251,6 +305,9 @@ LPWSAPROTOCOL_INFOA lpProtocolInfo, GROUP g, DWORD dwFlags); INT WINAPI ioctlsocket(SOCKET s, LONG cmd, ULONG *argp); + +/* FIXME: omitted the deviating WIN64 declaration */ +SOCKET WINAPI WSAAccept(SOCKET,ws_sockaddr*,LPINT,LPCONDITIONPROC,DWORD); #include "poppack.h" Index: server/protocol.def =================================================================== RCS file: /home/wine/wine/server/protocol.def,v retrieving revision 1.16 diff -u -r1.16 protocol.def --- server/protocol.def 2001/10/24 00:23:26 1.16 +++ server/protocol.def 2001/11/07 16:36:55 @@ -661,6 +661,31 @@ handle_t event; /* event object */ @END +/* Set Winsock2 flags */ +@REQ(set_socket_flags) + handle_t handle; /* handle to the socket */ + unsigned int flags; /* Winsock2 flags */ +@END + +/* Get Winsock2 flags */ +@REQ(get_socket_flags) + handle_t handle; /* handle to the socket */ +@REPLY + unsigned int flags; /* Winsock2 flags */ +@END + +/* Get deferred socket to be accept()ed later, for WSAAccept() */ +@REQ(get_socket_deferred) + handle_t handle; /* handle to the socket */ +@REPLY + handle_t deferred; /* deferred socket */ +@END + +/* Set deferred socket to be accept()ed later, for WSAAccept() */ +@REQ(set_socket_deferred) + handle_t handle; /* handle to the socket */ + handle_t deferred; /* deferred socket */ +@END /* Get socket event parameters */ @REQ(get_socket_event) Index: server/sock.c =================================================================== RCS file: /home/wine/wine/server/sock.c,v retrieving revision 1.21 diff -u -r1.21 sock.c --- server/sock.c 2001/10/05 19:45:45 1.21 +++ server/sock.c 2001/11/07 16:36:55 @@ -47,6 +47,8 @@ unsigned int pmask; /* pending events */ struct event *event; /* event object */ int errors[FD_MAX_EVENTS]; /* event errors */ + unsigned int flags; /* Winsock 2 socket flags */ + handle_t deferred; /* deferred socket to be accept()ed later */ }; static void sock_dump( struct object *obj, int verbose ); @@ -324,6 +326,8 @@ sock->hmask = 0; sock->pmask = 0; sock->event = NULL; + sock->flags = 0; + sock->deferred = 0; sock_reselect( sock ); clear_error(); return &sock->obj; @@ -342,36 +346,51 @@ GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops); if (!sock) return NULL; - /* Try to accept(2). We can't be safe that this an already connected socket - * or that accept() is allowed on it. In those cases we will get -1/errno - * return. - */ - slen = sizeof(saddr); - acceptfd = accept(sock->obj.fd,&saddr,&slen); - if (acceptfd==-1) { - sock_set_error(); - release_object( sock ); - return NULL; - } - if (!(acceptsock = alloc_object( &sock_ops, -1 ))) - { - release_object( sock ); - return NULL; + + if (sock->deferred) { + + /* If a previous WSAAccept() deferred accepting this request, try it again. */ + /* We do this no matter if called through accept() or WSAAccept(), */ + /* because this is the way Windows does it, too. */ + + acceptsock = (struct sock*)get_handle_obj(current->process,sock->deferred, + GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops); + sock->deferred = 0; + } else { + /* Try to accept(2). We can't be safe that this an already connected socket + * or that accept() is allowed on it. In those cases we will get -1/errno + * return. + */ + slen = sizeof(saddr); + acceptfd = accept(sock->obj.fd,&saddr,&slen); + if (acceptfd==-1) { + sock_set_error(); + release_object( sock ); + return NULL; + } + if (!(acceptsock = alloc_object( &sock_ops, -1 ))) + { + release_object( sock ); + return NULL; + } + + /* newly created socket gets the same properties of the listening socket */ + fcntl(acceptfd, F_SETFL, O_NONBLOCK); /* make socket nonblocking */ + acceptsock->obj.fd = acceptfd; + acceptsock->state = FD_WINE_CONNECTED|FD_READ|FD_WRITE; + if (sock->state & FD_WINE_NONBLOCKING) + acceptsock->state |= FD_WINE_NONBLOCKING; + acceptsock->mask = sock->mask; + acceptsock->hmask = 0; + acceptsock->pmask = 0; + acceptsock->event = NULL; + acceptsock->flags = sock->flags; + acceptsock->deferred = 0; } - /* newly created socket gets the same properties of the listening socket */ - fcntl(acceptfd, F_SETFL, O_NONBLOCK); /* make socket nonblocking */ - acceptsock->obj.fd = acceptfd; - acceptsock->state = FD_WINE_CONNECTED|FD_READ|FD_WRITE; - if (sock->state & FD_WINE_NONBLOCKING) - acceptsock->state |= FD_WINE_NONBLOCKING; - acceptsock->mask = sock->mask; - acceptsock->hmask = 0; - acceptsock->pmask = 0; - acceptsock->event = NULL; if (sock->event && !(sock->mask & FD_WINE_SERVEVENT)) - acceptsock->event = (struct event *)grab_object( sock->event ); - + acceptsock->event = (struct event *)grab_object( sock->event ); + sock_reselect( acceptsock ); clear_error(); sock->pmask &= ~FD_ACCEPT; @@ -589,3 +608,37 @@ release_object( &sock->obj ); } +DECL_HANDLER(get_socket_deferred) +{ + struct sock *sock; + + sock=(struct sock*)get_handle_obj(current->process,req->handle,GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops); + req->deferred = sock->deferred; +} + +DECL_HANDLER(set_socket_deferred) +{ + struct sock *sock; + + sock=(struct sock*)get_handle_obj(current->process,req->handle,GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops); + + sock->deferred = req->deferred; + release_object (&sock->obj); +} + +DECL_HANDLER(get_socket_flags) +{ + struct sock *sock; + + sock=(struct sock*)get_handle_obj(current->process,req->handle,GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops); + req->flags = sock->flags; +} + +DECL_HANDLER(set_socket_flags) +{ + struct sock *sock; + + sock=(struct sock*)get_handle_obj(current->process,req->handle,GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops); + sock->flags = req->flags; +} +

3 3

Re: SystemParametersInfo
by Alexandre Julliard 07 Nov '01

07 Nov '01

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Changed system parameters won't be reset back to X > settings? Not if they are changed permanently; if we want them to be reset then we simply should not set them and always query X. Basically there are many possibilities: 1) get and set in registry, ignore X 2) get and set in registry, if nothing in registry get default value from X 3) always get from X, ignore registry, do nothing on set 4) always get from X, ignore registry, set X value on set (not recommended) and there are even more combinations if you differentiate setting permanently/temporarily. There is no single right answer, it all depends on what the parameter does. IMO most cases should do 1), but there can be exceptions. > One case which comes to mind when such integration > would be useful is system parameter which shows > whether mouse buttons are swapped. Left-handed person > can configure mouse after he ran Wine the first time, > or the settings can be changed temporarily. We need a > way to find out the system setting was changed and > don't rely on saved value. In this case I don't think we should query X at all, since if the buttons are swapped at the X level this is transparent for us. Otherwise the buttons will get swapped twice... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: SystemParametersInfo
by Alexandre Julliard 07 Nov '01

07 Nov '01

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > I'm going to initialize system parameters from X > settings only on the first wine process startup, so > all other wine processes for the same wine server can > see the changes made by the first process. The X settings should probably be loaded lazily just like the rest. Just check if the registry key exists already to find out if you need to get the value from X. Another possibility is to have the X driver set the registry values on startup; this may actually be cleaner since then you don't need to add new calls to the USER driver. Also I'm not convinced there are many cases where we actually need to get proper values from X; what cases do you have in mind? > Other issue is fixed with this approach - the values > in registry are not changed back to X settings on > startup of new Wine process. > > Alexandre, the submitted patch is not affected by this > issue because none of the system parameters there is > initialized from X settings. > > Do you have any other concerns about the patch? Not really; a few minor issues but I'll fix them when committing the patch. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: SystemParametersInfo
by Alexandre Julliard 07 Nov '01

07 Nov '01

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > On Mon, Nov 05, 2001 at 06:20:24AM -0800, Andriy Palamarchuk wrote: > > Is there any way to check: > > 1) whether Wine process is the first process started > > for current Wine server? > Heh, I should really know ;-) > CLIENT_IsBootThread(). No, this shouldn't be used from user32 (besides it won't really do what you want). Why do you need this at all? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: What does user mean?
by Alexandre Julliard 06 Nov '01

06 Nov '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > I am working on the server code (adding the byte locking stuff) and down in > the select/thread/object stuff I keep coming across the term "user" which > seems to be synonymous with object. What is it supposed to mean? Why is an > object a user? How does it relate to a physical person or a windows process > or whatever? In that context "user" means an object that is a user of the select facilities. It has nothing to do with Unix users or anything else, it's purely internal to the select routines. -- Alexandre Julliard julliard(a)winehq.com

1 0

What does user mean?
by Bill Medland 06 Nov '01

06 Nov '01

I am working on the server code (adding the byte locking stuff) and down in the select/thread/object stuff I keep coming across the term "user" which seems to be synonymous with object. What is it supposed to mean? Why is an object a user? How does it relate to a physical person or a windows process or whatever? Bill

1 0

Re: queries on internals...
by Alexandre Julliard 06 Nov '01

06 Nov '01

Francois Gouget <fgouget(a)free.fr> writes: > only returns one. I was also wondering how to best fix that. Since it is > a Winelib application and not a part of Wine I don't know if > implementing strsep in library/port.c is the best solution: shouldn't we > be able to compile regapi on Windows? In addition to that Wine itself > does not use strsep. I would like Alexandre's opinion on that :-) Just fix regapi so that it doesn't require strsep. There is no good reason to require it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Extra info in scrollbar can be an handle.
by Marco Bizzarri 06 Nov '01

06 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. We have an application which crashes when trying to access the Window Long info in a scrollbar. After some tracking, it looked like the issue was that in some cases the wExtra data can contain an handle rather than a pointer. The included patch solves the problem by making an explicit GlobalLock, and returning that value. I'm not sure this is the correct solution, so comments are welcome. wine is from the latest cvs - -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE759zoXhfyAQQVoaIRApoGAJwOhVqzWtvYCz1oHZTcYSCYeCDQ6wCePBE3 DJ/zoeclED29BCnaC+9Ya8E= =rU+H -----END PGP SIGNATURE-----

1 0

Re: RTS/CTS
by lawson_whitney＠juno.com 06 Nov '01

06 Nov '01

On Tue, 6 Nov 2001, Mike McCormack wrote: > > Hi Lawson, > > good detective work! > > i don't think DSR/DTR flow control is supported by termios at all (at > least not in Linux), so here's a patch to ignore it. > > Mike > Okay, that passes the smoke test, and also looks right to me. Thanks. Did you forget a ChangeLog? Lawson Big fleas have little fleas upon their backs to bite 'em. And little fleas have smaller fleas and so on, infinitem.

1 0

Re: Winsock2 & overlapped IO
by Mike McCormack 06 Nov '01

06 Nov '01

Hi Ove, >Hm, by the way, when are you going to implemented overlapped >ConnectNamedPipe? That might make my rpcrt4 wait-for-connection code a bit >cleaner, so I don't have to spawn a separate thread per named pipe, and >worse, use TerminateThread to cancel the wait... OK. i'll have a look at it. Having a full time job, a part time job and a girlfriend to take care of kind of eats into my time though :-) >The challenges for winsock2 should be pretty much the same as those for >implementing something like ReadFileEx (which you've probably already >done) and the above-mentioned overlapped ConnectNamedPipe. Yeah, ReadFileEx is pretty much complete. Perhaps i'll have a look into overlapped sockets too... don't hold your breath though ;-) Mike btw. nice work on OLE/InstallShield stuff ------------------------------------------ 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

RTS/CTS
by lawson_whitney＠juno.com 06 Nov '01

06 Nov '01

Good day! A couple of wine-users have said Wine doesn't work RTS/CTS right any more, so I did a +comm,+file trace of juno, and was rewarded with this: trace:comm:SetCommState handle 224, ptr 0x403f0578 trace:comm:SetCommState bytesize 8 baudrate 115200 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS trace:comm:SetCommState ~CRTSCTS Does something look wrong about that, or am I just seeing it crosseyed? In GetCommState we have this: if (port.c_cflag & CRTSCTS) { lpdcb->fDtrControl = DTR_CONTROL_ENABLE; lpdcb->fRtsControl = RTS_CONTROL_ENABLE; lpdcb->fOutxCtsFlow = 1; lpdcb->fOutxDsrFlow = 1; } else And in SetCommState this: if ( lpdcb->fOutxCtsFlow || lpdcb->fRtsControl == RTS_CONTROL_ENABLE ) { port.c_cflag |= CRTSCTS; TRACE("CRTSCTS\n"); } if (lpdcb->fDtrControl == DTR_CONTROL_ENABLE) { port.c_cflag &= ~CRTSCTS; TRACE("~CRTSCTS\n"); } So I guess if you want to turn off CRTSCTS, GetCommState(handle, lpdcb); SetCommState(handle, lpdcb); would about do it. I don't know what fDtrControl is 'spoze to do, but shutting off flow control entirely seems a bit extreme. Juno apparently asks for it by name, CRTSCTS was not on when it did GetCommState, but it asked for flow control, too. Lawson panic: detected rogue system administrator!! ---cut here

1 0

Re: SystemParametersInfo
by Andreas Mohr 05 Nov '01

05 Nov '01

On Mon, Nov 05, 2001 at 06:20:24AM -0800, Andriy Palamarchuk wrote: > Please, review the new version of SystemParametersInfo > implementation. > > Is there any way to check: > 1) whether Wine process is the first process started > for current Wine server? Heh, I should really know ;-) CLIENT_IsBootThread(). > 2) whether Windows application runs under Wine or > Windows? Eh ? I don't quite understand the logic behind this. Could you elaborate ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 2

Re: Duplicated StrRetToStr functions in shell32
by Guy L. Albertelli 05 Nov '01

05 Nov '01

Francois, The reason that these routines were duplicated is that the builtin shell32 cannot find StrRetToBuf{A|W} in some of the native versions of shlwapi.dll. This dependency prohibited testing with builtin vs. native shlwapi. The change was submitted to winehq about 8/28 and committed soon thereafter. Guy ----- Original Message ----- From: "Francois Gouget" <fgouget(a)free.fr> To: <wine-patches(a)winehq.com> Sent: Wednesday, October 31, 2001 11:46 PM Subject: Duplicated StrRetToStr functions in shell32 > > Shell32 contains StrRetToStrNA and StrRetToStrNW which are almost > identical to StrRetToBufA and StrRetToBufW. Since shell32 already > imports shlwapi it seems like we should just call the latter functions! > That way I won't have to fix the "0x%p" thing twice. > > > Changelog: > > * dlls/shell32/shellstring.c > > Implement StrRetToStrN{A,W} by calling shlwapi.StrRetToBuf{A,W} > instead of duplicating the code > > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > I haven't lost my mind, it's backed up on tape around here somewhere... >

3 2

Winsock2 & overlapped IO
by Martin Wilck 05 Nov '01

05 Nov '01

Hello, I have started porting a software product of our company from NT to Linux using Wine. Part of this software is an agent which implements a proprietary protocol implemented with Winsock 2. In particular, it uses the Winsock 2 feature of "Overlapped IO" on sockets, with user-supplied callbacks that are called when data is received on a socket etc. Browsing through the Wine Winsock code, I saw that this part of Winsock2 is obviously unimplemented. Q: Has anybody worked on this already? Is there existing code somewhere? Q: Can you give an estimate if implementation of these features would require substantial changes in core wine code (something I'd like to avoid)? Q: Can you give me guidance on what part of the functionality would live in the wine server and what in the client? Regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

The Corel Wine LockFile code
by Medland, Bill 04 Nov '01

04 Nov '01

Just enquiring. Why isn't the CorelWine locking code in the Wine tree? Is it merely because no-one has had the time, need or desire or is there something unacceptable about the way that they did it? (Also as a side issue it appears to me that it isn't going to work if the file is on a Windows machine because it looks to me like the fcntl stuff doesn't get handled by smbfs; any comments?) Bill

2 1

ImageList_Write stub
by j.m.maurer 04 Nov '01

04 Nov '01

Hello Wine Developers! For a while now I want to use Delphi under Wine, which works for 99%. The one thing that is missing seems to be the implementation of ImageList::Write which prevents opening of Forms which contain an ImageList control. The output Wine gives is: -- fixme:imagelist:ImageList_Write empty stub! While searching through winehq.com I came across the URL http://www.winehq.com/WineAPI/ImageList_Write.html which describes that ImageList::Write is indeed not implemented due to the fact that IStream32::Write is not implemented.... Is implementing these functions a particular difficult task or has nobody had any spare time to do it yet? I have no knowlegde whatsoever of the structure of Wine or the Windows API, but I have some spare time and some code skills... Does anyone have any hints on this issue? Bye! Marc Maurer Please CC a reply to me, since I can't subscribe to this mailinglist, due to an unknown low level error reported by mailman :-)

2 1

minimise/maximise causes crash in 20011004
by mdew 02 Nov '01

02 Nov '01

warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d08e7 warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d021b warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d0d97 warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d0d97 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3a7 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3c0 is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d0d97 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d04eb warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3a7 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3c0 is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d0d97 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40729933 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4072994c is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d08e7 warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d04eb warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3a7 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3c0 is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d0d97 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40710e43 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40710e5c is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40710e43 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40710e5c is not inside heap warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40729933 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4072994c is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d08e7 warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d00b3 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3a7 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3c0 is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d0d97 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f123f is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f1258 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f123f is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f1258 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f123f is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f1258 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f123f is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f1258 is not inside heapwarn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40729933 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4072994c is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d08e7 warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d00b3 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3a7 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4071d3c0 is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d0d97 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f123f is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f1258 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f123f is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f1258 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f123f is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f1258 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f123f is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x406f1258 is not inside heap warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40729933 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4072994c is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d08e7 warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x40729933 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4072994c is not inside heap warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d08e7 warn:heap:HEAP_ValidateInUseArena Heap 411d0000: invalid in-use arena magic for 411d030b warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b48 is not inside heap warn:heap:HEAP_IsRealArena Heap 0x411d0000: block 0x4c0b61 is not inside heap warn:gdi:GDI_GetObjPtr Invalid handle 20003e warn:gdi:GDI_GetObjPtr Invalid handle 20003e warn:gdi:GDI_GetObjPtr Invalid handle 20003e warn:gdi:GDI_GetObjPtr Invalid handle 20003e warn:gdi:GDI_GetObjPtr Invalid handle 20003e warn:gdi:GDI_GetObjPtr Invalid handle 20003e <wine crash> causing this crash was just the act of minimising/maximising channel windows in mirc.

1 0

Yet again: audio.c stuff
by Simon Britnell 02 Nov '01

02 Nov '01

I've posted a substantial patch to audio.c which reorganises the code to make it a little easier to follow. It's been tested against HomeWorld and HalfLife. It works against homeworld with MIN_SLEEP_TIME 100, but not with MIN_SLEEP_TIME <=50. Feel free to set MIN_SLEEP_TIME to 0 to remove the minimum sleep time. The other thing the patch does is makes notifications dependant on bytes played rather than time elapsed. Should be a win overall. I'm still having no luck with tracking the actual race condition which causes HomeWorld to fail. I've not tried the patch you sent to fix the callback notification problem yet. I'll let you know when I do. __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

1 0

RE: LockFile - any words of warning?
by Medland, Bill 01 Nov '01

01 Nov '01

Thanks, but > -----Original Message----- > From: Rein Klazes [mailto:rklazes@xs4all.invalid] > Sent: Wednesday, October 31, 2001 9:32 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: LockFile - any words of warning? > > > On Wed, 31 Oct 2001 08:31:11 -0800, you wrote: > > > I am going to have to implement the LockFile/UnlockFile > functions. Does > > anyone have any words of warning? (Like it ain't as easy > as calling fcntl) > > Have a look at Corel's wine tree, where it is implemented. Please excuse my ignorance; how do I get at the Corel tree?

3 3

change cdrom?
by Per Wigren 01 Nov '01

01 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I have an annoying problem installing Grim Fandango. It comes on 2 cds. If I mount the cd and run "wine setup.exe" it starts to install until it asks for cd #2. But I can't unmount the CD to put in cd2 because it's busy... If I run "eject", it ejects but it still seems to be cached so it doesn't recognize that I've changed cd! Also: # wine D:\\setup.exe with the cdrom unmounted doesn't work either... :( Any solution to this problem? Regards Per Wigren -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74YVNyjnjcyLO8HkRAuJmAKCbfxoGueuTnzVO4PZ2W1MQB7hIrgCgmhQt MembJfuT4wVuZyERmHMd+VM= =npbq -----END PGP SIGNATURE-----

2 2

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