December 2001 - Wine-Devel - list.winehq.org

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

Dec. 17, 2001

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

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel Dec. 17, 2001

Dec. 17, 2001

At 02:20 PM 16/12/2001 -0800, you wrote: >Well, this sounds like an argument for the LGPL. There is absolutely >no guarantee of stability with the X11 license; anybody can start a >Wine tree under another license, and if developers think this is a >good idea there is nothing I or anybody else can do to prevent it. Theoretically yes. The project leader has a much higher chance to do it successfully in fact. Since he is fixing the rules in the first place he has to be more responsible IMO. >It's simply part of the existing rules that the rules can change. trusting people is always a problem, yes. >You know, that's exactly why we are having this discussion. If I was >as selfish as you seem to think, I could change the license today >without asking anybody. > I'm not doing it precisely because I *do* care >what people think, and I won't make the change unless it is acceptable >to at least a large majority of the people affected by the change (and >yes that includes Transgaming). it's for them (and possibly others professionals) to say then. Gerard

3 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 17, 2001

Dec. 17, 2001

> It would help us in several ways. First, since we've > always effectively > treated the Wine code base as though it were LGPL, we would gain > the protection that the LGPL offers. If someone else takes > the code we've > worked on, and competes with us, we would gain back > any improvements that they make. For example, if Wine had been LGPL, > then Transgaming would have been oblidged to release > Installshield fixes > back > (after all, they do follow on work that we did). Not according to the David Elliot and I agree. Even according to a strict interpretation of the LGPL they would just have to provide their code in seperate files so everything could be relinked when new versions of Wine was released. > With better > InstallShield > support, for example, our CrossOver customers might have a > wider range > of plugins > that would successfully install. This is a pretty minor problem; I > can't think of a > significant plugin affected by this. :-) Of course you claim that. Even if it was a problem you probably wouldn't admit it since it might raise to price in any possible negotions with Transgaming. :-) > Further, I think I > understand why > Gav has > has hesitated on this issue, and I firmly believe that Transgamings > intentions > with regards to the Wine project are honorable and good. As said above the only thing it would enforce would be file seperation so you more easily could integrate the part from Transgaming in your CrossOver product. Of course distributing it after that would violate Transgamings copyright, so you really need their permission after all. The point is LGPL wouldn't help you here. > However, I can imagine alternate scenarios where we could > have all of > our hard work > used against us by others who are more ruthless than Gav, and so the > LGPL would at least offer us some protection from that threat. Does it? It seems you overestime any advantages of LGPL. > A second benefit is simplicity. I spend a lot of time discussing > license > issues with my customers, and fighting very difficult battles to > preserve the integrity of the Wine code base (and while that sounds > noble and all bear in mind that a single, coherent source > code base that > I can fully > use is a key part of my business strategy). So, if the > license were LGPL, > my negotiating requirements would be simplified. In fact, I > would feel > free to > encourage my clients (and my company) to ruthlessly take > advantage of every > possible opportunity to create competitive advantages, because I feel > that the LGPL would protect the integrity of Wine. The same question here: Are you sure you are not overestimating the protection LGPL provides? > Of course, there are a number of downsides. First of all, it is > possible that > I would have fewer clients; the LGPL is complex license, > and it's core premise can deter many people. That is one of my objections as well. > It is widely > believed in the > Wine community that Corel would have never touched Wine if it had > been LGPL, and Corel's contributions to Wine were very significant > (the irony of course, is that AFAIK, Corel treated Wine as though > it were LGPL). Side note: I am one of them. > Second of all, the LGPL does, oddly enough, take away some freedom > on my part. Today, I have a full range of choices available > to me with > every product I release or help a client to build. After a > switch to LGPL > (and after enough time had passed for the LGPL'd pieces to be > significant), I'd have to be very cirumspect every time a > public release > of a product was made to be certain that I had all of my licensing > ducks in a row. Exactly, it increases your cost of doing business. > For example, right now, we don't provide a copy of the > source code contained within our CrossOver Plugin Wine tree. The only > changes we have not published back into the main WineHQ tree are > ones specifically required to interoperate with a > Linux/Netscape plugin. > The changes we made to Wine would never have been accepted by > Alexandre as being good or generally useful patches, and yet > they could > conceivably give someone who wished to replicate our proprietary > Linux plugin code a good insight into how to go about doing > so. To be > honest, > we sweat a lot of blood and tears to learn how to do that > right, and it > would > hurt if someone were able quickly knock off CrossOver Plugin > because we were > forced to show that code. To be honest and actually say something in support of LGPL: This wouldn't be required even with a strict LGPL interpretation. You would have to provide object files for relinking but that would not be much worse than providing the binary. Reverse enginerring it will be almost as hard. > On the other hand, we also had a > heck of a lot > of work on the Plugin code that has nothing to do with Wine, and I'd > like to see someone knock that off quickly <grin>. :-) > With all that, speaking on behalf of CodeWeavers, I would neither > call for > nor oppose a switch to the LGPL. Since that change would > impact me and my > customers somewhat slowly, I think I could make the necessary > adjustments in time. Perhaps the clarifications above might make you change your mind? > The most important thing is for us to continue to have a vital and > thriving Wine community. Agreed. > Finally, speaking strictly on a personal basis, and with > no corporate > considerations whatsoever, I would welcome a change to the LGPL; > I have always preferred it to BSD style licenses (and to the GPL, > for that matter); with LGPL projects, I feel more certain that I know > exactly > where I stand and how my code will be used. Well, perhaps it is because you misunderstood what the LGPL means?

6 7

Wine and Baldur's Gate
by Ian D . Stewart Dec. 17, 2001

Dec. 17, 2001

Well, Now that I've made it through the actual install, I figured I'ld take Baldur's Gate for a spin. The main screeen, where you select to play the game, change the configuration, etc, comes up fine. There's a slight pause after clicking 'Play' while BGMain.exe starts and X is set yo 640x480 (I'm guessing this has something to do with DETACH_PROCESS?), but that's no biggy. The opening credits and movie play just fine. I'm able to create the main character without any noticeable problems. The first 'problem' I ran into was at the opening of the 'Prologue' chapter. Under windows, a narrator's voice reads the opening text as it scrolls across the screen. Under wine, the text is scrolling, but sans naration. A bit annoying, but no biggy. The real fun starts when the game actually begins. First off, the sound, when there is any, cuts out quite a bit, with no apparent rhyme nor reason. Secondly, the left and bottom panels are covered by the main section. You have to click on the various buttons to make them display. The third 'error' appears to be related to X's virtual desktop. Moving the cursor to the left or bottom side of the screen moves the 'viewport' away from the window, instead of scrolling the view in the Baldur's Gate window. After shutting down Baldur's Gate, I noticed a whole slew of error messages in the xterm window I launched it from. Here are a few examples: fixme:module:CreateProcessA (BGMain.exe,...): DETACHED_PROCESS ignored fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403f8034,00020021,3):stub fixme:dsound:IDirectSoundBufferImpl_QueryInterface Unknown GUID {31efac30-515c-11d0-a9aa-00aa0061be93} fixme:ddraw:Main_DirectDraw_CreateSurface App didn't request a valid surface type - assuming offscreenplain err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX Any help in getting any of these issues resolved would be greatly appreciated! Thanx, Ian

2 3

Big Bummer for running Shrinkered files!
by Robert Baruch Dec. 17, 2001

Dec. 17, 2001

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

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel Dec. 16, 2001

Dec. 16, 2001

At 02:09 PM 16/12/2001 -0800, you wrote: >Gerard Patel wrote: >> I'd have no objection to Gpl *if* people having invested >> money in Wine success accept the move without problem.... > >I believe Gerard meant to write LGPL, not GPL. >There hasn't been any proposal to the the GPL on >wine, as far as I know. (The GPL might be too restrictive >IMHO.) Yes, correct. I said in my first post that from my (particular) point of view the licenses were similar. Gerard

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel Dec. 16, 2001

Dec. 16, 2001

At 11:35 AM 15/12/2001 -0800, you wrote: >I think that's quite unfair. I have stated that I personally don't >care about games, I don't have a single application that even uses >DirectX. The only reason I think DirectX is an issue is because I see >users complaining that Wine doesn't run their favorite game, and I >want Wine to be useful for as many people as possible. This has nothing to do with license, Transgaming or anything. All that is needed is a developer writing code. If there is none, nothing is written. Before Lionel Ulmer, there was no big DirectX game that could be played under Wine I think. Now Lionel is not contributing anymore - did he say to you privately that this was because of Transgaming ? There are many other top developers who have faded away like he did since I began on Wine, so it could be for many other reasons. Now, game users can as well subscribe to Transgaming as far as I am concerned. The vast majority of them seem to need professionnal - paid - support anyway. <snip> >> 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. > >I must say I'm quite offended by your comments. The only reason I >raise the issue is because I want Wine to remain as useful as possible >for everybody. <snip> you are the leader of this project since 8 years : the Gpl already existed when you began to work on Wine. You could have switched the license at any time. I don't remember you ever expressing any interest in Gpl for Wine since 3 years I am following - and I have read also quite a few of your interviews. Looking from the outside, this has more the appearances of a knee-jerk reaction, not the result of a long reflection. > 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. > >Absolutely not, and I don't know how you got this impression. I'd love >for copyright law to get back to sanity, but I don't see this >happening in the near future. Yes, there are a lot of abuses done in >the name of intellectual property these days. Does this mean we have >to let people hurt us and do nothing? You seem to think that users >rights are important, but how are you going to defend their rights if >not by using the only tool that we have, namely copyright law? No, that not what I was saying. If I am here, that's because I think that having Win32 Api outside of Windows is important. User rights have never got in the figure, since it was always acknowledged that people could take the stuff and turn it proprietary. Now that someone seems to succeed, you want to change the rules. Transgaming is playing by the existing rules, the rules you have enforced for a long time. If they are hurting you, that's surprising. They are not hurting me, since I have accepted your rules. What you are planning will hurt Transgaming business plan, by spreading Fear, Uncertainty and Doubt in their business discussions with potential customers. Business plan that they did and implemented in good faith, perfectly conforming to your rules and expecting their stability. I'd have no objection to Gpl *if* people having invested money in Wine success accept the move without problem. I think you should feel more responsibility towards people investing in Wine, not only responsibility towards the project - in other words you, because you are the Wine project. <snip> >I'm not planning to send anybody to jail, and I find that suggestion >insulting. What you are planning I don't know but in this context Gpl seems more a weapon than anything else. What happens when weapons are drawn can be anything. <snip> > I do think that given the lack >of developers, discouraging even a few of the existing ones can cause >a lot of harm to the project. I think that you will discourage one. Gerard

3 2

Re: create more window data structures before calling WH_CBT hooks.
by Uwe Bonnes Dec. 16, 2001

Dec. 16, 2001

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> The right patch attached this time. Rein. -- Rein Klazes This patch superceded my patch "Check WND structures before accessing", as it solved the problem with encarta99 startup 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: wine-devel digest, Vol 1 #584 - 10 msgs
by Roger Fujii Dec. 16, 2001

Dec. 16, 2001

I tried to resist.... really..... "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> wrote: > Possibly, however remember that license may not always be for the > application - it is for the product, including any proprietary works not > GPL'ed, or support rights. It is also however true that the GPL'ed > portion of the code may have no other restrictions placed on it's use. other than the restrictions that the GPL imposes... > Going back to the user, how could a user who brought this infringing > product be benefited from the developer suing? Mostly, they may not. In > other cases, they benefit from the fact the code is again public, and they > have a far easier way to see about getting bugs fixed, etc.. the usual > benefits a good open-source project has. Here is a good counter-example. Sun Microsystems developed a toolkit that would convert linux network drivers source to function with Solaris (their proprietary OS). It was just a toolkit. They weren't distributing driver binaries. AFAIK, this use is perfectly legal to do with the GPL. What happens? The GPL GNUts get all bent out of shape because it allowed use of their drivers under a proprietary OS, so Sun yanked it, even though they were not in violation. As a *USER*, this is a negative impact placed on me by the linux developers to exercise my rights, since it impedes my ability to USE GPLed software. > > 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. > That's a load of bull, of course. A copyright has been violated.. it's > like with a trademark - if someone violates a trademark, the owner comes > very likely to forgoing his rights on that mark for not enforcing it. You are confusing copyrights and trademarks. A copyright is not invalidated due to lack of an active defense. A trademark would. > All I wanted was installshield support! :p All I want is for VirtualDub to work! :) "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > > I feel rather dismayed by the whole discussion. > Maybe this is so because the way you approached the issue. > See, you are concerned with the semantics of things, the 'why', I think the better question is "what" as in what is trying to be accomplished? > centuries. Second, even suggesting that a LGPL Wine will the an evil > 'intelectual property' monster is ridiculous. Just a reminder, most open > source projects are (L)GPL and _that_ community is the only significant > force in today's society fighting against such things as software patents, > DCMA, SSSCA, etc. I would not equate the LPF with the FSF. They have very different agendas. > If we agree up to this point, what is the 'syntax' I was referring to? > Well, IMO this is a stronger Wine that keeps evolving and that has a life > of its own. Wether this is good or not for users it's irrelevant. You probably meant something other than what you wrote here. Existence for the sake of existence is useless. I would presume the point of wine is to provide a WINXX environment on top of x86 platforms. If M$ was sued into oblivion tomorrow, and Wine was a *perfect* 95/98/ME/XP emulator, there would be no need for future development (other than to port to new platforms). The point is that the end goal is to attempt to be the perfect emulator for the USER - not to keep wine going indefinitely. > Some may say yes, others (e.g. Microsoft) may say no. I submit that we that this > goal as axiomatic and we go from there. > > Now, I can argue that this very axiom eliminates any sort of proprietary > licence, but I will not do it since it's understood by everybody here. I > will just look at the two possible options: BSD vs. LGPL. There are two > points in my axiom: > 1. we should try to make Wine stronger (e.g. evolve faster) > 2. Wine should have a life of it's own > > Let's look at the first part: make Wine evolve faster. > LGPL > pros: > -- _far_ bigger code base for sharing/reuse and how to do arrive at this? the modified BSD license is professed by FSF to be compatible with the GPL. > -- _far_ bigger developer base Can you actually say for certain that the gain of developers by using LGPL is less than the loss of developers by using BSD? > -cons: > -- we may lose developers that are opposed philosophically to the > GPL ideals > -- less commercial freedom when using the code base Setting philosophy aside, there are many companies that will not touch *anything* with the letters GPL in it, due to what is perceived (rightly or wrongly) to be its consequences. It is not an overstatement to say that *GPL is a net discouragement to commercial development - the GPL and FSF are openly hostile to proprietary software - PERIOD. Anyone who claims otherwise must also believe that M$ is "encouraging innovation". I can also add a few more cons: -- FSF discourages use of LGPL -- Discourages commercial companies for its use/development. -- Adds more confusion to the mix - LGPL ramifications is less understood than the GPL. > BSD > (just negate the above) > > And now for the second part: Wine should have a life of its own. This is, > to my mind, the crucial part. The problem with a BSD licence is that it > does not ensure that. and how do you arrive at this conclusion? I would say that apache, X11, BSD would disprove what you are saying. > The cool and amazing thing about the (L)GPL is that > it puts in place the right feedback loop (or vicious circle if you > will) that ensures a project a life of its own independent of who's > developing and maintaining it: the bigger the project becomes, the more > people will use it, (up to now BSD and GPL are the same), the more people > will contribute to it, the bigger the project becomes!!! It's the > equivalent for the 'rich get richer', but the currency is not money but > usefulness/code. It is simple, yet brilliant. This is an artifact of "open software". GPL is a *part* of open software - it is not the definition of open software. I don't believe anyone here is advocating making wine non-open. The problem wine has is that it is not a small endeavor like most GPLed software. If you look at the larger projects (gcc, gdb, openoffice, apache, x11, mozilla..), you will find the ones that are most successful long term are the ones with active corporate involvement. With this in mind, I think wine is better served by having its use proliferate and being more complete (even at the expense of having propriatary extensions), than having something that is incomplete but "free". As a side question, what IS the difference between what's available on winehq vs codeweavers? -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

4 4

Re: create more window data structures before calling WH_CBT hooks.
by Uwe Bonnes Dec. 16, 2001

Dec. 16, 2001

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> hi, My application, girotel v 2.1, crashes during the creating of Rein> its first windows when calling the CBT hooks in Rein> --- ./wine/windows/win.c Wed Sep 29 17:14:39 1999 Rein> +++ ./mywine/windows/win.c Tue Oct 12 20:24:27 1999 Rein, are you sure this is the right patch? It seems from 1999... I want it test the patch if it supercedes my recent get_whole_window patch... 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 Dec. 16, 2001

Dec. 16, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Even according to a strict interpretation of the LGPL > > they would just have to provide their code in seperate > > files so everything could be relinked when new versions > > of Wine was released. > > It seems you really don't understand the LGPL. Modifications made to a > library released under the LGPL are a derivative work of this library, > and have to be LGPL no matter if they are in separate files or > not. Saying the ALL modifications gives rise to a derived works even if distributed seperately is a ridiculous proposition that is the main problem with (L)GPL. As I have been trying to explain is that the courts are unlikely to support this, at least not 100%. The question is where is borderline is. At the extreme end the courts might totaly reject the doctrine of derived work in favour of the doctrine of combined work what I have been talking about in previous mails. If somebody (A) only provide drop in files that replaces some functions say the Crypto API in ADVAPI32, they are not any combined work since they are 100% written by A. Sure the application/library as a whole is of course a combined work, but that doesn't matter if you do not distribute it as a whole. > This is the standard interpretation that just about anybody > except you agrees with. If you think everybody agrees what a derived work is you are badly mistaken. Even Richard Stallman himself admit that the power of (L)GPL is dependent on how far the courts will allow the doctrine of derived work. Note that I do not pretend to know how the courts will rule. But I do know that sticking the head in the sand and pretending that (L)GPL doesn't have large potential holes in it is quite naive and potentially dangerous.

3 2

Decision process on possible switch to LGPL
by Roger Fujii Dec. 16, 2001

Dec. 16, 2001

Dan Kegel <dank(a)kegel.com> wrote: > > Who has to decide what in order for the Wine project > to switch to the LGPL? I believe the process involves all prior contributors allowing this, or have the non-LGPL code rewritten and that work be LGPLed. Pending on the number of authors, the effort can be non-trivial. Look at the license change discussions for mozilla and kde if you want to get the grasp of what is required. > Could it be as simple as the wine cvs tree accepting LGPL'd contributions > along with old-license contributions? Not if you want a "pure" LGPL distribution. > Or need one go so far as requiring all new contributions to the cvs > tree be under the LGPL? even further. > Would a valid way of voting be to open up a new cvs tree that > accepted only LGPL contributions, and giving maintainers the > choice of which tree (or both) to submit to? That would > within not too long show how contributors felt. This is going to encourage more development... NOT. What you definitely don't want is confusion over what license is being used. Unless you make a stipulation that the final license chosen will automatically convert the other license, it would just be a mess as you then will have 2 source trees which you have to go back and reconcile. -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

2 1

OSS stuff
by Duane Clark Dec. 16, 2001

Dec. 16, 2001

The recent OSS stuff is working pretty good. I have one area, where one sound clip stops and the next starts, that sometimes has problems. Sometimes the second clip runs normally, and sometimes there is just a brief bit of the very beginning of the second clip. I think this is where the problem is. The difference I see is that when it breaks, some wodNotifyClient msgs are received before the wodGetPosition messages are set to valid values for the new clip. When it works, those values get set before the wodNotifyClient msgs. Then again, I really don't understand what is going on. A trace from when it fails: trace:wave:wodRestart imhere[3-RESTARTING] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_RESTARTING 0 trace:wave:wodPlayer_FeedDSP fragments=16/16, fragsize=1024, bytes=16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290cdf4.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce14.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 12288 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce34.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 8192 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce54.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 4096 trace:wave:wodPlayer waiting 46ms (132,46) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=0/16, fragsize=1024, bytes=-1226 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CDF4 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE14 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE34 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE54 dwParam2 = 0000 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=4294966070 trace:wave:wodGetPosition TIME_SAMPLES=134217421 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=1/16, fragsize=1024, bytes=742 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=742 trace:wave:wodGetPosition TIME_SAMPLES=185 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=3/16, fragsize=1024, bytes=2694 trace:wave:wodPlayer waiting 110ms (110,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=2694 trace:wave:wodGetPosition TIME_SAMPLES=673 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=5/16, fragsize=1024, bytes=4648 trace:wave:wodPlayer waiting 88ms (88,4294967295) It continues this way until the DSP buffer is empty, and nothing further is written to it. Here is when it works: trace:wave:wodRestart imhere[3-RESTARTING] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_RESTARTING 0 trace:wave:wodPlayer_FeedDSP fragments=16/16, fragsize=1024, bytes=16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290cdf4.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce14.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 12288 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce34.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 8192 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce54.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 4096 trace:wave:wodPlayer waiting 46ms (132,46) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=78 trace:wave:wodGetPosition TIME_SAMPLES=19 trace:wave:OSS_wodMessage (0, 0009, 0000001C, 4290CE74, 00000020); trace:wave:wodWrite (0, 0x4290ce74, 00000020); trace:wave:wodWrite imhere[3-HEADER] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_HEADER 4290ce74 trace:wave:wodPlayer_FeedDSP fragments=1/16, fragsize=1024, bytes=108 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce74.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 108 dwLength 4096 available space was 108 trace:wave:wodPlayer waiting 45ms (132,45) trace:wave:wodPlayer_FeedDSP fragments=0/16, fragsize=1024, bytes=-990 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CDF4 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE14 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE34 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE54 dwParam2 = 0000 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=2/16, fragsize=1024, bytes=928 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce74.108[4096] trace:wave:wodPlayer_WriteMaxFrags Written 928 dwLength 3988 available space was 928 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200

1 0

Adding protections in map_image
by Robert Baruch Dec. 16, 2001

Dec. 16, 2001

Hi all, Uwe and I have been working on several executables which have been compressed by Shrinker. Basically, under win98 it tries to load a VXD which is disallowed. The prospects are better under nt40 mode, but it looks like Shrinker purposely causes read and write exceptions. After looking at this for a little over a week, I've found that there are two problems which need to be solved. The first is that the exception handler installed by Shrinker under Wine causes another fault and then a spin. Under WinDbg (in W2K/VMWare) the exception handler does not cause another fault, and execution continues nicely. The second is that WinDbg finds a write fault where Wine does not. To fix this, Wine must set protections on the executable's image map. I came up with a patch to do this, and it worked for my Shrinkered exe, but not for Uwe's. Uwe's exe loads MSVCRT20.DLL, and then Wine calls PE_fixup_imports, which attempts to write to that DLL's .idata section, which had been set read-only. Clearly Wine needs to write to that section to set up imports which haven't been implemented. Now, my patch put the protections on the mapped image right at the end of map_image. This works when map_image is called (eventually) from PROCESS_InitWine, so that the initial executable gets its protections set right. However, it doesn't work for PE_LoadLibraryExA (called by LoadLibraryExA) because it first checks to see if the library has already been loaded. If it has been loaded, it calls PE_fixup_imports. If it has not been loaded, it calls (eventually) map_image. So if the library has already been loaded, it has already had its protections set up by map_image at some point in the past. Then when PE_fixup_imports is called, a protection violation occurs. My current idea is to go into PE_fixup_imports, unprotect the .idata section, do the fixups, and reprotect the section. The bad thing is that if someone else in the future writes some code that does additional fixups to other sections, they are also going to have to unprotect and reprotect. This might turn out to be a good thing, though, if it forces you to do that. What does everyone think? Thanks, --Rob

2 6

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 16, 2001

Dec. 16, 2001

> > Note that I do not pretend to know how the courts will rule. > > But I do know that sticking the head in the sand and pretending > > that (L)GPL doesn't have large potential holes in it is quite > > naive and potentially dangerous. > > Then if the LGPL holes are dangerous, the X11 license should be even > more dangerous; after all it's a much larger hole than the LGPL will > ever have. I still don't understand where you are trying to go with > your argument. Sure it has a larger hole. But at least it is obvious that is does. It doesn't make you believe good things will happend. The point is that you seem to wish some things to happend and I point out that LGPL provides not guarentee that it will actually will happend despite that LGPL at a quick glance looks like it in some meaning forces what you wish to happend. One the other hand the LGPL might scare away potential companies wishing to extend Wine. See below. > No, of course the LGPL doesn't provide absolute protection; nothing > does, and I don't think absolute protection is desirable either. There > are some things that the LGPL clearly allows, some that it clearly > forbids, and a number of border cases, that frankly are only > interesting to people who want to try to get around the license > restrictions. And what would be the point of doing that? Making their business model work. Trying to ensure investment return. > If the > license is not acceptable to someone, they don't have to use the > code. Who would risk bad PR and potential lawsuits just to prove that > they can find a loophole in the LGPL? So we lose some possible companies willing to help in two step. 1. Because they do not dare 2. Because you (or somebody else) sue them Great idea. NOT. > You really make it sound like the LGPL is some kind of unexplored > wilderness that we shouldn't venture into. We are not a normal software project and thus what really is a derived work when faced with a lot unimplemented stuff are much more difficult to know. I have tried to show that LGPL in itself is pretty weak and are likely to be even weaker then faced with Wine's special circumstances. > The fact is that a large > majority of free software projects use either the GPL or the LGPL, and > in practice it works just fine for them, just as I'm confident it > would work just fine for us. Normal software project doesn't have any large design with a lot of not yet implemented functions, there it makes sense for some company to say: Hey I could provide an implementation of this special part under this special business model. Face it we are not a normal software project and the arguments they used for chosing (L)GPL are not really relevant here. Note that I'm not denying that convincing arguements for choosing LGPL might exists, but reference to earlier success is not one of them. Your argument that LGPL forces good things to happend is not entirely convincing either for reasons stated earlier. The current license is something that is easy to understand and are unlikely to scare companies like Transgaming away, but can you really say the say same about LGPL?

2 1

Decision process on possible switch to LGPL
by Dan Kegel Dec. 15, 2001

Dec. 15, 2001

Who has to decide what in order for the Wine project to switch to the LGPL? Could it be as simple as the wine cvs tree accepting LGPL'd contributions along with old-license contributions? Or need one go so far as requiring all new contributions to the cvs tree be under the LGPL? Would a valid way of voting be to open up a new cvs tree that accepted only LGPL contributions, and giving maintainers the choice of which tree (or both) to submit to? That would within not too long show how contributors felt. - Dan

1 0

configure broken?
by Oliver Sampson Dec. 15, 2001

Dec. 15, 2001

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 Dec. 15, 2001

Dec. 15, 2001

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 Dec. 15, 2001

Dec. 15, 2001

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 Dec. 15, 2001

Dec. 15, 2001

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 Dec. 15, 2001

Dec. 15, 2001

> > > (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 Dec. 15, 2001

Dec. 15, 2001

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(a)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(a)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 Dec. 15, 2001

Dec. 15, 2001

> 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 Dec. 15, 2001

Dec. 15, 2001

> 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 Dec. 15, 2001

Dec. 15, 2001

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 Dec. 15, 2001

Dec. 15, 2001

> 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 Dec. 15, 2001

Dec. 15, 2001

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(a)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 Dec. 15, 2001

Dec. 15, 2001

> 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 Dec. 14, 2001

Dec. 14, 2001

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(a)giftie wine]$ Probable user head space error. - Dennis A. Moore

1 0

Winelib source for IPropertySetStorage implementation
by Sanand Patel Dec. 14, 2001

Dec. 14, 2001

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 Dec. 13, 2001

Dec. 13, 2001

> 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 Dec. 13, 2001

Dec. 13, 2001

>>>>> "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 Dec. 13, 2001

Dec. 13, 2001

> 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 Dec. 13, 2001

Dec. 13, 2001

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 Dec. 13, 2001

Dec. 13, 2001

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 Dec. 13, 2001

Dec. 13, 2001

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 Dec. 13, 2001

Dec. 13, 2001

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 Dec. 13, 2001

Dec. 13, 2001

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 Dec. 13, 2001

Dec. 13, 2001

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 Dec. 12, 2001

Dec. 12, 2001

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 Dec. 12, 2001

Dec. 12, 2001

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 Dec. 12, 2001

Dec. 12, 2001

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 Dec. 12, 2001

Dec. 12, 2001

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 Dec. 12, 2001

Dec. 12, 2001

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 Dec. 11, 2001

Dec. 11, 2001

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 Dec. 11, 2001

Dec. 11, 2001

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 Dec. 11, 2001

Dec. 11, 2001

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 Dec. 11, 2001

Dec. 11, 2001

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 Dec. 10, 2001

Dec. 10, 2001

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 Dec. 10, 2001

Dec. 10, 2001

No. It IS down in the button.c; I'll do it in a second. > -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland(a)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 Dec. 10, 2001

Dec. 10, 2001

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 Dec. 10, 2001

Dec. 10, 2001

> 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 Dec. 9, 2001

Dec. 9, 2001

> 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 Dec. 8, 2001

Dec. 8, 2001

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 Dec. 7, 2001

Dec. 7, 2001

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 Dec. 7, 2001

Dec. 7, 2001

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 Dec. 7, 2001

Dec. 7, 2001

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 Dec. 6, 2001

Dec. 6, 2001

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 Dec. 6, 2001

Dec. 6, 2001

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 Dec. 6, 2001

Dec. 6, 2001

> 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 Dec. 6, 2001

Dec. 6, 2001

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 Dec. 5, 2001

Dec. 5, 2001

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 Dec. 5, 2001

Dec. 5, 2001

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 Dec. 5, 2001

Dec. 5, 2001

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(a)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 Dec. 4, 2001

Dec. 4, 2001

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 Dec. 4, 2001

Dec. 4, 2001

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 Dec. 4, 2001

Dec. 4, 2001

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(a)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 */ +(a)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 */ +(a)REPLY + handle_t handle; /* handle to request object for later use */ +(a)END + +/* Reschedule an unfinished async I/O request */ +(a)REQ(requeue_async_request) + handle_t handle; /* handle to the request object to be rescheduled */ +(a)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 Dec. 4, 2001

Dec. 4, 2001

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 Dec. 3, 2001

Dec. 3, 2001

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 Dec. 3, 2001

Dec. 3, 2001

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 Dec. 3, 2001

Dec. 3, 2001

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 Dec. 3, 2001

Dec. 3, 2001

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 Dec. 3, 2001

Dec. 3, 2001

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(a)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 Dec. 3, 2001

Dec. 3, 2001

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 Dec. 2, 2001

Dec. 2, 2001

[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 Dec. 2, 2001

Dec. 2, 2001

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 Dec. 1, 2001

Dec. 1, 2001

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 Dec. 1, 2001

Dec. 1, 2001

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(a)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 Dec. 1, 2001

Dec. 1, 2001

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