May 2007 - Wine-Devel - list.winehq.org

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > Bug triage is a good idea so that stuff like this gets cleaned up. I'm > not sure what everyone wants though. I guess you can figure that out > :P See, my opinion of what triage is isnt the same as everyone else's.. Either way, I'll just leave resolved bugs resolved, until they stop me from finding a specific bug I'm looking for. Allow me to get a consensus. Random Closing of Resolved bugs that have no activity is not deemed helpful by everyone, even if it does help me, so would it be acceptable for me to close a few (less than 20) a day? That way I'm not spamming the list for any more than 30 mins, and I can still kind of make it easier to find the bugs that need a followup. -- Thanks Tom

May 31, 2007

Re: Bug triage, or spam?

by Jesse Allen

On 5/31/07, Tom Spear <speeddymon(a)gmail.com> wrote: > On 5/31/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > > Remember that this is only my opinion. Other people handle things a > > little different. It is probably true that the two recent bugs you > > mentioned I would have closed, but it was only resolved. It's just how > > it was handled. If you want to close bugs that are clearly done with > > like that, it's fine by me. And I do close bug reports with other > > status too, if it's one I really don't want to see again. > > > > If it's clear why you are closing bugs, it's all fine by me, whatever it is. > Just to clarify my reasoning, because I just now thought about the > _real_ reasoning lol, I often look thru lists of bugs that are > resolved as fixed and (although i havent done it in a few years, i was > going to start again), post a message to ask if the reporter can > confirm if it is fixed. So I was closing bugs that were > invalid/abandoned/dupe/worksforme so that they wouldnt show in the > lists of resolved bugs, so its less I have to sort thru.... > Bug triage is a good idea so that stuff like this gets cleaned up. I'm not sure what everyone wants though. I guess you can figure that out :P

May 31, 2007

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > Remember that this is only my opinion. Other people handle things a > little different. It is probably true that the two recent bugs you > mentioned I would have closed, but it was only resolved. It's just how > it was handled. If you want to close bugs that are clearly done with > like that, it's fine by me. And I do close bug reports with other > status too, if it's one I really don't want to see again. > > If it's clear why you are closing bugs, it's all fine by me, whatever it is. Just to clarify my reasoning, because I just now thought about the _real_ reasoning lol, I often look thru lists of bugs that are resolved as fixed and (although i havent done it in a few years, i was going to start again), post a message to ask if the reporter can confirm if it is fixed. So I was closing bugs that were invalid/abandoned/dupe/worksforme so that they wouldnt show in the lists of resolved bugs, so its less I have to sort thru.... -- Thanks Tom

May 31, 2007

Re: Bug triage, or spam?

by Jesse Allen

On 5/31/07, Tom Spear <speeddymon(a)gmail.com> wrote: > On 5/31/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > > Tom, > > > > This is how I finalize bugs: > > > > * When a bugs has decisively been fixed, by a merged patch, with test > > cases, or reported by user been fixed, then I close it. If it's > > decisively "not a wine bug" close invalid. > > * When a bug is rumored to be fixed, forgotten, or simply doesn't > > appear on your end, then probably resolve fixed, abandoned, or > > worksforme appropriately. > > * When the bug has been only set to resolved, and continues to have > > erroneous activity (i.e. commenting from random visitors that don't > > understand the report), then close it to discourage use of the bug. > > * If it's a bug that I don't know anything about, I shouldn't touch it. > > > > So the reason is, only "resolved" could maybe get revisited, and > > "closed" I never want to see again. Other than that, it makes no sense > > to me to close bugs unless there is some activity related to it (i.e. > > it is proved that an uncertain fix has really been fixed and the issue > > is done). Simply closing bugs worries me as does James. It really does > > need to be case-by-case, so what we know you are doing is right. > > Thanks for the clarification. So if it is already resolved as > anything other than fixed, just leave it alone unless it continues to > get activity. I still don't like it, but as with anything, majority > rules, so I will stop. Sorry for the spam everyone. > > -- > Thanks > > Tom > > > Remember that this is only my opinion. Other people handle things a little different. It is probably true that the two recent bugs you mentioned I would have closed, but it was only resolved. It's just how it was handled. If you want to close bugs that are clearly done with like that, it's fine by me. And I do close bug reports with other status too, if it's one I really don't want to see again. If it's clear why you are closing bugs, it's all fine by me, whatever it is. Jesse

May 31, 2007

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > Tom, > > This is how I finalize bugs: > > * When a bugs has decisively been fixed, by a merged patch, with test > cases, or reported by user been fixed, then I close it. If it's > decisively "not a wine bug" close invalid. > * When a bug is rumored to be fixed, forgotten, or simply doesn't > appear on your end, then probably resolve fixed, abandoned, or > worksforme appropriately. > * When the bug has been only set to resolved, and continues to have > erroneous activity (i.e. commenting from random visitors that don't > understand the report), then close it to discourage use of the bug. > * If it's a bug that I don't know anything about, I shouldn't touch it. > > So the reason is, only "resolved" could maybe get revisited, and > "closed" I never want to see again. Other than that, it makes no sense > to me to close bugs unless there is some activity related to it (i.e. > it is proved that an uncertain fix has really been fixed and the issue > is done). Simply closing bugs worries me as does James. It really does > need to be case-by-case, so what we know you are doing is right. Thanks for the clarification. So if it is already resolved as anything other than fixed, just leave it alone unless it continues to get activity. I still don't like it, but as with anything, majority rules, so I will stop. Sorry for the spam everyone. -- Thanks Tom

May 31, 2007

Re: Bug triage, or spam?

by Jesse Allen

On 5/31/07, Tom Spear <speeddymon(a)gmail.com> wrote: > > It's a problem to me, it may not be a problem to you, but that doesn't > make it an invalid point. Marcus and Dan have both said to keep > going, I'm sure others here (I'm not trying to speak for anyone, so > someone else feel free to correct me if I am wrong) dont have any > problem with my doing that either. > > And you miss the point as well, most new bugs that are marked resolved > dont end up being closed on a case-by-case basis, which is why I am > going back and doing that! > > Case in point: http://bugs.winehq.org/show_bug.cgi?id=7885 has been > resolved for over a month, why was it not closed? > http://bugs.winehq.org/show_bug.cgi?id=8373 has been resolved for 2 > weeks, same question applies. > Tom, This is how I finalize bugs: * When a bugs has decisively been fixed, by a merged patch, with test cases, or reported by user been fixed, then I close it. If it's decisively "not a wine bug" close invalid. * When a bug is rumored to be fixed, forgotten, or simply doesn't appear on your end, then probably resolve fixed, abandoned, or worksforme appropriately. * When the bug has been only set to resolved, and continues to have erroneous activity (i.e. commenting from random visitors that don't understand the report), then close it to discourage use of the bug. * If it's a bug that I don't know anything about, I shouldn't touch it. So the reason is, only "resolved" could maybe get revisited, and "closed" I never want to see again. Other than that, it makes no sense to me to close bugs unless there is some activity related to it (i.e. it is proved that an uncertain fix has really been fixed and the issue is done). Simply closing bugs worries me as does James. It really does need to be case-by-case, so what we know you are doing is right. Jesse

May 31, 2007

Re: [d3drm/tests] d3drm is removed from Windows Vista

by Tom Wickline

On 5/11/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > > > I suppose that implies that any application using d3drm won't work on > > Vista? > Yes, I think ms stated that clearly somewhen. No idea why they removed it > since it just wraps to directdraw, and native d3drm works on wine(apart of a > whole lot of directdraw executebuffer bugs) Almost all of the small games here : http://roborangers.home.comcast.net/Archive.htm use d3drm they may be useful for testing as there free. Tom -- Only two defining forces have ever offered to die for you, Jesus Christ and the American G.I. One died for your soul, the other for your freedom.

May 31, 2007

Re: Whitespace changes in an indentation patch, is it acceptable?

by Dan Hipschman

On Thu, May 31, 2007 at 02:23:59PM -0500, Tom Spear wrote: > I recall a few years back (2003?) There was a discussion about > removing extra whitespace at the end of lines, and someone came up > with a bash/sed script to look thru the entire wine tree, strip > trailing whitespace, and then somehow commit it (either with a really > large diff, or by it being run on the machine that the upstream tree > is on, I cant remember which). Once that was done, the tarballs > shrank by at least 1-2 megs in download size, and even more > uncompressed. I was curious, and got a really rough estimate of the number of files with trailing whitespace: $ find /var/work/wine/ -name '*.[chly]' | fgrep -v .tab | fgrep -v .yy \ | xargs grep -c '[[:space:]]\+$' | fgrep -v :0 | wc -l reported 1081 files. Checking for trailing whitespace after a backslash didn't turn up anything (which is good). I hardly think getting rid of trailing whitespace will shrink the tarballs by any significant amount, though.

May 31, 2007

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, James Hawkins <truiken(a)gmail.com> wrote: > > Obviously someone that commits patches to the upstream bugzilla tree > > agrees with me, because otherwise, there either wouldnt be a resolved > > option, OR there would be a close option on the bugs that are in any > > state of open, which is something I have suggested before, to cut down > > on list traffic. > > > > We are our own project, and we use bugzilla differently, just like > every other project out there has their own practices. Ok. > > I honestly dont see why it is such an inconvenience to you for me to > > close the bugs that are marked resolved. You read thru every one of > > my emails because you dont trust my decisions, understandable, but if > > you are so worried about my marking a bug wrongly, then maybe you > > should stop developing, and strictly focus on helping clean up > > bugzilla, > > huh? That doesn't make any sense. You're saying I should take even > more time away from development to check your changes. No, I'm saying that if someone higher up in the heirarchy were to do this as well, then I wouldnt have as many bugs to mess with, and therefore I wouldnt be able to make as many bad changes. > I'm not the only one that reads each change, and even if I were, and > someone else took over, it's still wasted time on their part. I know you arent the only one who reads each change. What I'm saying is that someone who has more free time (someone who's time it wouldnt be wasting, because they can't do anything atm) should join the fun. > You continue to miss the point from the very beginning: you're trying > to fix a problem that doesn't exist. There's nothing wrong with old > bugs being left as resolved and marking new bugs closed on a case by > case basis. It's a problem to me, it may not be a problem to you, but that doesn't make it an invalid point. Marcus and Dan have both said to keep going, I'm sure others here (I'm not trying to speak for anyone, so someone else feel free to correct me if I am wrong) dont have any problem with my doing that either. And you miss the point as well, most new bugs that are marked resolved dont end up being closed on a case-by-case basis, which is why I am going back and doing that! Case in point: http://bugs.winehq.org/show_bug.cgi?id=7885 has been resolved for over a month, why was it not closed? http://bugs.winehq.org/show_bug.cgi?id=8373 has been resolved for 2 weeks, same question applies. -- Thanks Tom

May 31, 2007

Re: Bug triage, or spam?

by James Hawkins

On 5/31/07, Tom Spear <speeddymon(a)gmail.com> wrote: > On 5/31/07, James Hawkins <truiken(a)gmail.com> wrote: > > I do read through all of your bug emails, which is exactly the > > problem, because I don't trust that you make the right decision on > > every bug, and in some cases I've had to go back and correct it. That > > is the issue. > > It has been a small number of cases.. > That small number forces me to read the rest. > > The statement still stands. Resolved isn't resolved enough for you, > > but closed is...If a bug is marked resolved, I'm pretty sure it's > > resolved. > > Obviously someone that commits patches to the upstream bugzilla tree > agrees with me, because otherwise, there either wouldnt be a resolved > option, OR there would be a close option on the bugs that are in any > state of open, which is something I have suggested before, to cut down > on list traffic. > We are our own project, and we use bugzilla differently, just like every other project out there has their own practices. > > No one has problems with people correcting bugs that are marked > > incorrectly, but of the 30 or so bugs a day that you change, this case > > is a small amount. If you *only* changed this class of bugs, then > > that would be fine. > > I honestly dont see why it is such an inconvenience to you for me to > close the bugs that are marked resolved. You read thru every one of > my emails because you dont trust my decisions, understandable, but if > you are so worried about my marking a bug wrongly, then maybe you > should stop developing, and strictly focus on helping clean up > bugzilla, huh? That doesn't make any sense. You're saying I should take even more time away from development to check your changes. > or the inverse could be true, maybe you could just trust > that if I make a status change, it is the correct thing to do, and if > not, then let someone else, who does have more time on their hands, > catch it. I'm not the only one that reads each change, and even if I were, and someone else took over, it's still wasted time on their part. >Like you said, it's a small amount of bugs that are marked > incorrectly. Of that percentage, I represent an even smaller amount, > and like I said, I dont blindly close bugs, I read the majority of the > comments, especially the ones toward the end, and the initial report, > and then make a change only when I am confident that it is the right > change to make.. > You continue to miss the point from the very beginning: you're trying to fix a problem that doesn't exist. There's nothing wrong with old bugs being left as resolved and marking new bugs closed on a case by case basis. -- James Hawkins

May 31, 2007

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, James Hawkins <truiken(a)gmail.com> wrote: > I do read through all of your bug emails, which is exactly the > problem, because I don't trust that you make the right decision on > every bug, and in some cases I've had to go back and correct it. That > is the issue. It has been a small number of cases.. > The statement still stands. Resolved isn't resolved enough for you, > but closed is...If a bug is marked resolved, I'm pretty sure it's > resolved. Obviously someone that commits patches to the upstream bugzilla tree agrees with me, because otherwise, there either wouldnt be a resolved option, OR there would be a close option on the bugs that are in any state of open, which is something I have suggested before, to cut down on list traffic. > No one has problems with people correcting bugs that are marked > incorrectly, but of the 30 or so bugs a day that you change, this case > is a small amount. If you *only* changed this class of bugs, then > that would be fine. I honestly dont see why it is such an inconvenience to you for me to close the bugs that are marked resolved. You read thru every one of my emails because you dont trust my decisions, understandable, but if you are so worried about my marking a bug wrongly, then maybe you should stop developing, and strictly focus on helping clean up bugzilla, or the inverse could be true, maybe you could just trust that if I make a status change, it is the correct thing to do, and if not, then let someone else, who does have more time on their hands, catch it. Like you said, it's a small amount of bugs that are marked incorrectly. Of that percentage, I represent an even smaller amount, and like I said, I dont blindly close bugs, I read the majority of the comments, especially the ones toward the end, and the initial report, and then make a change only when I am confident that it is the right change to make.. -- Thanks Tom

May 31, 2007

Re: Whitespace changes in an indentation patch, is it acceptable?

by Tom Spear

On 5/31/07, Dan Kegel <dank(a)kegel.com> wrote: > Now that you've fixed a couple bugs in your uninstall patch, > I think you should post the very simplest form of it possible, > without any other change mixed in. In this case, I think that > means you should do the whitespace changes in a second patch. Right, which is the way the patch is already done, I just wanted to see if making changes to the whitespace in other parts of the file (via the 2nd patch, which changes the indentation of my additions) would be considered random whitespace changes, or if it would be helpful, because it reduces filesize.. I recall a few years back (2003?) There was a discussion about removing extra whitespace at the end of lines, and someone came up with a bash/sed script to look thru the entire wine tree, strip trailing whitespace, and then somehow commit it (either with a really large diff, or by it being run on the machine that the upstream tree is on, I cant remember which). Once that was done, the tarballs shrank by at least 1-2 megs in download size, and even more uncompressed. IMHO it may be time to do that again... -- Thanks Tom

May 31, 2007

Re: Bug triage, or spam?

by James Hawkins

On 5/31/07, Tom Spear <speeddymon(a)gmail.com> wrote: > On 5/31/07, James Hawkins <truiken(a)gmail.com> wrote: > > Marking bugs as closed has nothing to do with bug triage. Triaging > > bugs would be a really helpful thing, but mass-closing bugs does > > nothing but give subscribers a whole lot of emails to delete. We > > don't keep track of stats like other projects, so there's really no > > point to blindly close all bugs that are resolved, instead of closing > > bugs on a case by case basis. > > I'm not blindly closing all bugs marked resolved.. It seems to me > that you didnt real thru all of the emails, but I have been posting > comments, etc before closing, and there are some that are marked > resolved that I did not close, or that I even reopened based on the > most recent commentS that indicate the bug might not be fixed, or > might actully be a real wine bug.. > I do read through all of your bug emails, which is exactly the problem, because I don't trust that you make the right decision on every bug, and in some cases I've had to go back and correct it. That is the issue. > > > since invalid isnt really "resolved", and neither is works for me > > > > But closing these bugs somehow makes them "resolved" for you? > > It's an organizational thing, if they are closed, then we know for > sure that they are resolved. The statement still stands. Resolved isn't resolved enough for you, but closed is...If a bug is marked resolved, I'm pretty sure it's resolved. > Since everyone is prone to marking a bug > as invalid when it is really a bug, or works for me when it really > should be open because some users are experiencing it but not others, > leaving it as resolved just says that the person who resolved it was > too lazy to close it, and that they didn't check back to make sure > that some other users didnt have the same problem.. Case in point: > bug 3889, has been resolved as worksforme (i did it over a year ago), > when it is really a bug, and has never truely been resolved in wine. > I just looked back thru the conversation that took place on wine-devel > and saw no definitive response saying that the bug was fixed by an > alexandre patch, and saw nothing that says the bug is not a bug, so I > am about to reopen it and ask if the issue is fixed in current wine. > No one has problems with people correcting bugs that are marked incorrectly, but of the 30 or so bugs a day that you change, this case is a small amount. If you *only* changed this class of bugs, then that would be fine. -- James Hawkins

May 31, 2007

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, James Hawkins <truiken(a)gmail.com> wrote: > Marking bugs as closed has nothing to do with bug triage. Triaging > bugs would be a really helpful thing, but mass-closing bugs does > nothing but give subscribers a whole lot of emails to delete. We > don't keep track of stats like other projects, so there's really no > point to blindly close all bugs that are resolved, instead of closing > bugs on a case by case basis. I'm not blindly closing all bugs marked resolved.. It seems to me that you didnt real thru all of the emails, but I have been posting comments, etc before closing, and there are some that are marked resolved that I did not close, or that I even reopened based on the most recent commentS that indicate the bug might not be fixed, or might actully be a real wine bug.. > > since invalid isnt really "resolved", and neither is works for me > > But closing these bugs somehow makes them "resolved" for you? It's an organizational thing, if they are closed, then we know for sure that they are resolved. Since everyone is prone to marking a bug as invalid when it is really a bug, or works for me when it really should be open because some users are experiencing it but not others, leaving it as resolved just says that the person who resolved it was too lazy to close it, and that they didn't check back to make sure that some other users didnt have the same problem.. Case in point: bug 3889, has been resolved as worksforme (i did it over a year ago), when it is really a bug, and has never truely been resolved in wine. I just looked back thru the conversation that took place on wine-devel and saw no definitive response saying that the bug was fixed by an alexandre patch, and saw nothing that says the bug is not a bug, so I am about to reopen it and ask if the issue is fixed in current wine. -- Thanks Tom

May 31, 2007

Re: GDI+: headers and one test

by Chris Robinson

On Thursday 31 May 2007 06:59:09 am Francois Gouget wrote: > --- /dev/null > +++ b/include/GdiplusTypes.h > [...] > +typedef enum { > [...] > +} Status; > > Hmm, this is not the same as the PSDK. The PSDK only defines 'enum > Status { ... }' which, in theory, should only allow one to use 'enum > Status' and not 'Status'. Yet the PSDK headers seem to make use of > 'Status'. This might be different in C++ though... > So on the whole it's probably ok to use a typedef. I just prefer to > bring this up so others can chime in. C++ auto-typedefs structs/classes, enums, and the like. enum Status { }; in C++ would be equivilant to: typedef enum Status { } Status; in C. And yes, both the enum and typedef can have the same name.. the compiler is smart enough to tell the difference between 'enum Status' and 'Status' being used as types. Both can be used interchangeabley, too.

May 31, 2007

re: Whitespace changes in an indentation patch, is it acceptable?

by Dan Kegel

Tom wrote: >Hi all, just curious, in my work on uninstaller, I am writing my >patches to where when indentation is changed, due to adding a for >loop, it is done in a separate patch file. I was wondering if it is >acceptable to make whitespace changes to other parts of the file in >that same patch. In general, mixing large whitespace changes with small functional changes make it hard to code review the functional change. But either way can be fine, it just depends on the situation. Now that you've fixed a couple bugs in your uninstall patch, I think you should post the very simplest form of it possible, without any other change mixed in. In this case, I think that means you should do the whitespace changes in a second patch. - Dan

May 31, 2007

Re: Bug triage, or spam?

by James Hawkins

On 5/31/07, Tom Spear <speeddymon(a)gmail.com> wrote: > Hi all, I just have a quick question.. > > I got a message from someone last night asking me to stop closing bugs > because I'm spamming the list, however I also received a message from > someone a couple of nights ago thanking me for doing bug triage.. > Which is it, and if it is both, then what draws the line between > triage and spam, and how do I close stale bugs without it being > considered spam? > Marking bugs as closed has nothing to do with bug triage. Triaging bugs would be a really helpful thing, but mass-closing bugs does nothing but give subscribers a whole lot of emails to delete. We don't keep track of stats like other projects, so there's really no point to blindly close all bugs that are resolved, instead of closing bugs on a case by case basis. > since invalid isnt really "resolved", and neither is works for me But closing these bugs somehow makes them "resolved" for you? -- James Hawkins

May 31, 2007

Re: Bug triage, or spam?

by Marcus Meissner

On Thu, May 31, 2007 at 10:04:00AM -0500, Tom Spear wrote: > On 5/31/07, Ben Hodgetts <ben(a)atomnet.co.uk> wrote: > >Can someone explain to me the point of closing bugs please? If it's > >resolved one way or another then surely that's enough? Just seems like a > >waste of effort to be honest. > > Well, I can tell you this about it, it's supposed to work like this: > > - User reports bug > - Developer looks into bug, and eventually fixes it, at which point he > marks it resolved, and asks user to verify > - User says yes it is resolved and marks it verified, or says no it is > not, at which point developer reopens bug, and the process repeats > - Once marked verified, developer then goes back and closes bug. > > It hardly ever works that way, unfortunately, but I prefer to see a > bunch of closed bugs than ones that are sitting marked resolved as > invalid, or resolved as works for me, etc, since invalid isnt really > "resolved", and neither is works for me.. Thats why I go thru and > close the bugs that are just left resolved for more than a month or 2. Well, but in theory they could sit at resolved until the end of time ;) But keep it up, people can just delete those RESOLVED->CLOSED transition mails. Ciao, Marcus

May 31, 2007

Re: mshtml #2: Added warning if a wrong Wine Gecko package version was found.

by Jacek Caban

Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > > >> Yes, that's my plan, but I'm not sure why it's important for this patch. >> Currently Wine downloads always the same Gecko version that was never >> updated, so this check should work with current Wine. It will change >> once we will switch to the new version. I have patches that will use >> query encoded in URL to specify the package version and it will use the >> same defined version string as version check in this patch, so switching >> to the new Gecko won't be much more than one line patch.. It requires >> changes both in Wine and redirecting php script. I have patches for both >> and this was the first patch in this direction. I only have to test the >> rest of patches and send them (hopefully I will find the time to do it >> tonight). >> > > My concern is that this sort of thing needs to be planned correctly to > work in the long run, and it's not clear what the purpose of that > version check is. Is there a dependency that would make Wine require a > specific version? What happens if you use a new Gecko with an old > Wine? Can you make different versions coexist? > The plan is to pass the version in URL query. Then the redirecting script will take care on choosing the correct file from SourceForge. It's backward compatible as older Wine won't pass the version so script will assume that an old Gecko is requested. The new Gecko doesn't work with old Wine (that's why we have to guaranty that it will download an old Gecko). It's because we depend on some Gecko behaviors that have changed. It's both due to Wine (we have to do some not nice tricks, to not say ugly hacks, to make loading document work correctly) and not perfect backward compatibility of Gecko. Also it's not guarantied that newer Wine will work with older Gecko. Currently it will work, that's why I think simple message is enough for now to not force people to download over 5MB if their apps work without it. But we have to use some unfrozen interfaces and they may change in the future preventing backward compatibility. Although we probably could add some workarounds when it will happen, I would be painful to support few Gecko version. So if it will happen in the future, then we can change this check to never use older Gecko (and perhaps add a nice updater). By coexisting different versions you mean in one Wine prefix? Yes, it would be possible, but I don't see much point of it. If you think it should be done this way, I may implement so (it prevents current patches, these changes would be in another peace of code). >> We are very far from being able to support other archs, so I thought >> it's not worth to care about it ATM. >> > > But then there's no sense in adding #ifdefs for it. Putting the > architecture in the request wouldn't be much harder, and would avoid > hardcoding in the client knowledge about what files are available on > the server. > I've sent patches that replace previous ones. There are removed #ifdefs. We may back to arch problem later, just like we do now with different versions. Thanks, Jacek

May 31, 2007

Re: Bug triage, or spam?

by Tom Spear

On 5/31/07, Ben Hodgetts <ben(a)atomnet.co.uk> wrote: > Can someone explain to me the point of closing bugs please? If it's > resolved one way or another then surely that's enough? Just seems like a > waste of effort to be honest. Well, I can tell you this about it, it's supposed to work like this: - User reports bug - Developer looks into bug, and eventually fixes it, at which point he marks it resolved, and asks user to verify - User says yes it is resolved and marks it verified, or says no it is not, at which point developer reopens bug, and the process repeats - Once marked verified, developer then goes back and closes bug. It hardly ever works that way, unfortunately, but I prefer to see a bunch of closed bugs than ones that are sitting marked resolved as invalid, or resolved as works for me, etc, since invalid isnt really "resolved", and neither is works for me.. Thats why I go thru and close the bugs that are just left resolved for more than a month or 2. -- Thanks Tom

May 31, 2007

Re:wine.inf: Create fake dll for iexplore.exe.

by Louis. Lenders

>wine.inf: Create fake dll for >iexplore.exe. >Vitaliy Margolen wine-patches at kievinfo.com >Thu May 24 08:50:10 CDT 2007 >Some older programs check if IE is installed looking for c:\Program >Files\Internet Explorer\iexplore.exe --- tools/wine.inf | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)

May 31, 2007

Re: Bug triage, or spam?

by Ben Hodgetts

Can someone explain to me the point of closing bugs please? If it's resolved one way or another then surely that's enough? Just seems like a waste of effort to be honest. Ben H. Tom Spear wrote: > Hi all, I just have a quick question.. > > I got a message from someone last night asking me to stop closing bugs > because I'm spamming the list, however I also received a message from > someone a couple of nights ago thanking me for doing bug triage.. > Which is it, and if it is both, then what draws the line between > triage and spam, and how do I close stale bugs without it being > considered spam? >

May 31, 2007

Whitespace changes in an indentation patch, is it acceptable?

by Tom Spear

Hi all, just curious, in my work on uninstaller, I am writing my patches to where when indentation is changed, due to adding a for loop, it is done in a separate patch file. I was wondering if it is acceptable to make whitespace changes to other parts of the file in that same patch.. For example, there is: int somevariable; do something; (there are 2 spaces in the blank line). Would it be acceptable to remove those spaces in a patch that changes the following code (which is introduced by the first patch in the series): for blah { do something; for something else { do another thing; } } to: for blah { do something; for something else { do another thing; } } or should I just leave those extra whitespaces in the blank line alone? -- Thanks Tom

May 31, 2007

Re: GDI+: headers and one test

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Hmm, this is not the same as the PSDK. The PSDK only defines 'enum > Status { ... }' which, in theory, should only allow one to use 'enum > Status' and not 'Status'. Yet the PSDK headers seem to make use of > 'Status'. This might be different in C++ though... > So on the whole it's probably ok to use a typedef. I just prefer to > bring this up so others can chime in. I think it's better without the typedef, in C we can simply use 'enum Status'. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2007

Re: GDI+: headers and one test

by Francois Gouget

On Tue, 29 May 2007, Evan Stade wrote: [...] > include/Gdiplus.h | 10 +++++ > include/GdiplusEnums.h | 39 ++++++++++++++++++ > include/GdiplusFlat.h | 23 ++++++++++ > include/GdiplusGpStubs.h | 10 +++++ > include/GdiplusInit.h | 26 ++++++++++++ > include/GdiplusTypes.h | 7 +++ All filenames in Wine should be lowercase. --- /dev/null +++ b/include/Gdiplus.h [...] + +#ifndef __cplusplus Why check for __cplusplus here? The PSDK contains no such check, at least in this file. --- /dev/null +++ b/include/GdiplusEnums.h [...] +#ifndef _GP_ENUMERATIONS_H_ +#define _GP_ENUMERATIONS_H_ The standard format for Wine headers is __WINE_HEADERNAME_H, unless we need to keep the original macro name for compatibility with the PSDK. But here you're following neither conventions (the other headers would need to be rechecked but they seem to keep the PSDK names). --- /dev/null +++ b/include/GdiplusFlat.h [...] +GpStatus WINGDIPAPI GdipCreateFromHDC(HDC hdc, GpGraphics **graphics); +GpStatus WINGDIPAPI GdipDeleteGraphics(GpGraphics *graphics); Wine headers generally don't keep the parameter names in the headers as they are not needed. --- /dev/null +++ b/include/GdiplusTypes.h [...] +typedef enum { [...] +} Status; Hmm, this is not the same as the PSDK. The PSDK only defines 'enum Status { ... }' which, in theory, should only allow one to use 'enum Status' and not 'Status'. Yet the PSDK headers seem to make use of 'Status'. This might be different in C++ though... So on the whole it's probably ok to use a typedef. I just prefer to bring this up so others can chime in. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

May 31, 2007

Bug triage, or spam?

by Tom Spear

Hi all, I just have a quick question.. I got a message from someone last night asking me to stop closing bugs because I'm spamming the list, however I also received a message from someone a couple of nights ago thanking me for doing bug triage.. Which is it, and if it is both, then what draws the line between triage and spam, and how do I close stale bugs without it being considered spam? -- Thanks Tom

May 31, 2007

Re: mshtml #2: Added warning if a wrong Wine Gecko package version was found.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > Yes, that's my plan, but I'm not sure why it's important for this patch. > Currently Wine downloads always the same Gecko version that was never > updated, so this check should work with current Wine. It will change > once we will switch to the new version. I have patches that will use > query encoded in URL to specify the package version and it will use the > same defined version string as version check in this patch, so switching > to the new Gecko won't be much more than one line patch.. It requires > changes both in Wine and redirecting php script. I have patches for both > and this was the first patch in this direction. I only have to test the > rest of patches and send them (hopefully I will find the time to do it > tonight). My concern is that this sort of thing needs to be planned correctly to work in the long run, and it's not clear what the purpose of that version check is. Is there a dependency that would make Wine require a specific version? What happens if you use a new Gecko with an old Wine? Can you make different versions coexist? > We are very far from being able to support other archs, so I thought > it's not worth to care about it ATM. But then there's no sense in adding #ifdefs for it. Putting the architecture in the request wouldn't be much harder, and would avoid hardcoding in the client knowledge about what files are available on the server. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2007

Re: winefile/explorer hardcoded? HKEY_CLASSES_ROOT\Folder\shell\open\command ignored

by Jan Zerebecki

On Mon, Apr 09, 2007 at 05:26:22AM +0200, RusH wrote: > Winefile seems to be hardcoded when it comes to opening folders. No > matter what I do it always pops up. I tried deleting > HKEY_CLASSES_ROOT\Folder and nothing changed. How do you test this? For me using start on directories gives access denied ( e.g. in cwd: start c:\windows ). So I guess what you see is something calling explorer on a directory. It then calls winefile, which is hard-coded. > Should I made a bug report? Yes. Jan

May 30, 2007

Re: (try 2) ws2_32: getsockname should fail for unbound sockets

by Dmitry Timoshkov

"Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > + case AF_INET6: > + { > + static const struct sockaddr_in6 emptyAddr; > + const struct sockaddr_in6 *in6 = (struct sockaddr_in6*) uaddr; > + return in6->sin6_port || memcmp(&in6->sin6_addr, &emptyAddr.sin6_addr, sizeof(struct in6_addr)); > + } > + case AF_INET: > + { > + static const struct sockaddr_in emptyAddr; > + const struct sockaddr_in *in = (struct sockaddr_in*) uaddr; > + return in->sin_port || memcmp(&in->sin_addr, &emptyAddr.sin_addr, sizeof(struct in_addr)); > + } You should add 'const' to the casting if the target you create is 'const'. -- Dmitry.

May 30, 2007

Re: headers, two tests

by Dmitry Timoshkov

This time it's just the nit picks, I see no serious problems. "Evan Stade" <estade(a)gmail.com> wrote: > +void WINGDIPAPI GdipFree(void* ptr) > +{ > + if(ptr) > + HeapFree(GetProcessHeap(), 0, ptr); > +} There is no need to check a pointer for NULL before HeapFree call, there is even a janitorial project in Wine to remove such checks. > +static void test_constructor_destructor(void) > +{ > + GpStatus status; > + GpGraphics *pen; > + > + status = GdipCreatePen1((ARGB)0xffff00ff, 10.0f, UnitPixel, &pen); GdipCreatePen1 takes a pointer to GpPen in the last parameter, not GpGraphics. > + expect(Ok, status); > + ok(pen, "Expected pen to be initialized"); If you are testing returned pen pointer for NULL, you need to initialize it to NULL before the call. -- Dmitry.

May 30, 2007

Re: mshtml #2: Added warning if a wrong Wine Gecko package version was found.

by Jacek Caban

Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > > >> @@ -212,8 +213,10 @@ static BOOL load_wine_gecko(PRUnichar *gre_path) >> if(res != ERROR_SUCCESS || type != REG_SZ) >> return FALSE; >> >> - if(TRACE_ON(mshtml)) >> - check_version(gre_path); >> + /* We may consider message box here */ >> + if(ERR_ON(mshtml) && !check_version(gre_path)) >> + MESSAGE("Found a version of Wine Gecko package that is not dedicated " >> + "to your Wine version. Reinstalation is recommended.\n"); >> > > If you want to check versions, there needs to be a way to specify in > the URL which version you want to download, and old versions need to > be kept available. Yes, that's my plan, but I'm not sure why it's important for this patch. Currently Wine downloads always the same Gecko version that was never updated, so this check should work with current Wine. It will change once we will switch to the new version. I have patches that will use query encoded in URL to specify the package version and it will use the same defined version string as version check in this patch, so switching to the new Gecko won't be much more than one line patch.. It requires changes both in Wine and redirecting php script. I have patches for both and this was the first patch in this direction. I only have to test the rest of patches and send them (hopefully I will find the time to do it tonight). > The target CPU should also be part of the URL so we > can support multiple platforms. > We are very far from being able to support other archs, so I thought it's not worth to care about it ATM. Thanks, Jacek

May 30, 2007

Re: crypt32: implement CryptSIPLoad (resend)

by Paul Vriens

On 5/30/07, Juan Lang <juan_lang(a)yahoo.com> wrote: > Hi Paul, > > > Please correct me if I'm wrong but aren't you filling pSipDispatch > > with the function pointers of the given dll (as indicated by the GUID) > > instead of the function pointers of crypt32 (as the tests show it > > should)? > > I am. I couldn't find any reason that the behavior needs to be that way, > so I do this until such time as a reason can be found. The tests don't > fail, as you check the function pointers from msisip.dll, which isn't > present on wine. > > If you know a good reason native does it that way (or an app that depends > on it,) by all means enlighten me. The implementation I sent allows > native wintrust to get a bit further. > > --Juan > Hi Juan, The tests check the returned functions pointers against the ones retrieved from a LoadLibrary/GetProcAddress of the crypt32.dll. These specific tests for the function pointers don't fail because they are inside a todo_wine :-). I must say I don't see a good reason why native does it like this but the tests show it does. Cheers, Paul.

May 30, 2007

Re: Pretty Build System (Take 3)

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> Attached is a patch that reduces the verbosity of the build system by >> printing the build commands in one of two formats: >> COMMAND output_file >> or >> COMMAND input_file -> output_file >> >> I hope it meets Alexandre's requirements of not reducing portability >> of Wine to other platforms (including Windows). >> > > The MAKEFLAGS stuff is still not portable, and I still think this > belongs in make itself. > > Here's a quick proof of concept patch against GNU make. It needs a > better algorithm for extracting the command name, and some sort of > command-line option; this is left as an exercise for the reader. > Thanks, I'll take a look at this when I get a spare moment. -- Rob Shearman

May 30, 2007

Re: Pretty Build System (Take 3)

by Robert Shearman

Tom Spear wrote: > On 5/29/07, Robert Shearman <rob(a)codeweavers.com> wrote: >> Hi, >> >> Attached is a patch that reduces the verbosity of the build system by >> printing the build commands in one of two formats: >> COMMAND output_file >> or >> COMMAND input_file -> output_file >> >> I hope it meets Alexandre's requirements of not reducing portability of >> Wine to other platforms (including Windows). > Well, after applying the patch and doing like Kirill instructed me, it > looks pretty good. I just have a couple of nits, and they really can > be worked out later on. > > 1) make depend/make install/make uninstall/make test, etc does not > appear "pretty" make depend and make test should appear "pretty", but I haven't worked on make install/uninstall yet. > 2) is there any way to "prettify" the entering/leaving directory > messages, I think the 2.6 kernel has it that way, but I'm not 100% > sure You can use "make --no-print-directory". -- Rob Shearman

May 30, 2007

Looking for Dev to help with BSD Port

by Kris Moore

Hey all! We're looking for a Wine dev to assist us with some porting issues over to PC-BSD / FreeBSD. We've recently begun to embrace making packages with wine embedded, making the process of loading windows programs a snap. The end user only needs to double-click, insert their CD, and click next a few times. This allowed us to make some packages for programs such as PhotoShop & Dreamweaver which even a non-linux/BSD user could install. We really want to expand these packages, to include things such as games, and others, but there are a few problems with running Wine on BSD at the moment. If anybody is willing to help us out with this, please let me know! Here's a list of some of the porting issues were aware of: http://wiki.freebsd.org/Wine Thanks! -- Kris Moore PC-BSD Software http://www.pcbsd.com

May 30, 2007

Re: Ownerdraw listview font patch...

by Dimi Paun

On Wed, May 30, 2007 08:47, Markus Gömmel wrote: > Before sending this to wine.patches, I wanted to ask if anyone here can tell > me if the above is ok or total bullshit. Looks good to me. I wonder if we shouldn't set other things as well, but this would require testing to figure out. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

May 30, 2007

Re: Implement the WriteEnvironmentStrings standard action

by James Hawkins

On 5/29/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "James Hawkins" <truiken(a)gmail.com> wrote: > > > + HKEY env, root = HKEY_CURRENT_USER; > ... > > + if (flags & ENV_MOD_MACHINE) > > + root = HKEY_LOCAL_MACHINE; > > It looks like root is not used. > Oops. Thanks for catching that, I'll resend. -- James Hawkins

May 30, 2007

Re: Pretty Build System (Take 3)

by Tom Spear

On 5/29/07, Robert Shearman <rob(a)codeweavers.com> wrote: > Hi, > > Attached is a patch that reduces the verbosity of the build system by > printing the build commands in one of two formats: > COMMAND output_file > or > COMMAND input_file -> output_file > > I hope it meets Alexandre's requirements of not reducing portability of > Wine to other platforms (including Windows). Well, after applying the patch and doing like Kirill instructed me, it looks pretty good. I just have a couple of nits, and they really can be worked out later on. 1) make depend/make install/make uninstall/make test, etc does not appear "pretty" 2) is there any way to "prettify" the entering/leaving directory messages, I think the 2.6 kernel has it that way, but I'm not 100% sure -- Thanks Tom

May 30, 2007

Re: crypt32: implement CryptSIPLoad (resend)

by Juan Lang

Hi Paul, > Please correct me if I'm wrong but aren't you filling pSipDispatch > with the function pointers of the given dll (as indicated by the GUID) > instead of the function pointers of crypt32 (as the tests show it > should)? I am. I couldn't find any reason that the behavior needs to be that way, so I do this until such time as a reason can be found. The tests don't fail, as you check the function pointers from msisip.dll, which isn't present on wine. If you know a good reason native does it that way (or an app that depends on it,) by all means enlighten me. The implementation I sent allows native wintrust to get a bit further. --Juan ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

May 30, 2007

Ownerdraw listview font patch...

by Markus Gömmel

Hi, one of our windows application is using an OWNERDRAW_FIXED listview. With the current version of Wine I mentioned that when the listview is loosing its focus, the selected item will be repainted in a wrong front (System 12 instead of my MS Shell Dlg 11)... after the focus comes back, the item is redrawn again, now with correct font settings again. After searching for a while my idea is that the LISTVIEW_ShowFocusRect function is missing a SelectObject call to the font stored in the item-structure for this particular listview item. So the hdc transfered over WM_DRAWITEM to the application contains the wrong font. I created the attached patch, which looks like this: --- snipp --- diff -u -u -r1.485 listview.c --- dlls/comctl32/listview.c 25 May 2007 19:46:02 -0000 1.485 +++ dlls/comctl32/listview.c 30 May 2007 12:28:44 -0000 @@ -1770,6 +1770,9 @@ { DRAWITEMSTRUCT dis; LVITEMW item; + + HFONT hFont = infoPtr->hFont ? infoPtr->hFont : infoPtr->hDefaultFont; + HFONT hOldFont = SelectObject(hdc, hFont); item.iItem = infoPtr->nFocusedItem; item.iSubItem = 0; @@ -1788,6 +1791,8 @@ dis.itemData = item.lParam; SendMessageW(infoPtr->hwndNotify, WM_DRAWITEM, dis.CtlID, (LPARAM)&dis); + + SelectObject(hdc, hOldFont); } else { --- snipp --- Before sending this to wine.patches, I wanted to ask if anyone here can tell me if the above is ok or total bullshit. Thanks and regards Markus

May 30, 2007

Re: crypt32: implement CryptSIPLoad (resend)

by Paul Vriens

On 5/30/07, Juan Lang <juan_lang(a)yahoo.com> wrote: > Hi, I fixed the test failures - anything wrong with it this time? > > ChangeLog: implement CryptSIPLoad > > Thanks, > --Juan > Hi Juan, Please correct me if I'm wrong but aren't you filling pSipDispatch with the function pointers of the given dll (as indicated by the GUID) instead of the function pointers of crypt32 (as the tests show it should)? Cheers, Paul.

May 30, 2007

Re: hhctrl.ocx: Parse HTML entities in the table of contents.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > + p++; > + if ((*p == 'X') || (*p == 'x')) > + { > + /* hexadecimal entity */ > + while ((*p >= '0' && *p <= '9') || (*p >= 'a' && *p <= 'f') || > + (*p >= 'A' && *p <= 'F')) > + p++; > + ch = strtolW(start + 2, NULL, 16); > + } This is still broken. > + if (p - start - 1 <= sizeof(char_refs[0].name)) > + { > + for (i = 0; i < sizeof(char_refs)/sizeof(char_refs[0]); i++) > + if (!strncmpW(char_refs[i].name, start + 1, p - start - 1)) > + break; > + } This is still broken too. -- Alexandre Julliard julliard(a)winehq.org

May 30, 2007

Re: mshtml #2: Added warning if a wrong Wine Gecko package version was found.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -212,8 +213,10 @@ static BOOL load_wine_gecko(PRUnichar *gre_path) > if(res != ERROR_SUCCESS || type != REG_SZ) > return FALSE; > > - if(TRACE_ON(mshtml)) > - check_version(gre_path); > + /* We may consider message box here */ > + if(ERR_ON(mshtml) && !check_version(gre_path)) > + MESSAGE("Found a version of Wine Gecko package that is not dedicated " > + "to your Wine version. Reinstalation is recommended.\n"); If you want to check versions, there needs to be a way to specify in the URL which version you want to download, and old versions need to be kept available. The target CPU should also be part of the URL so we can support multiple platforms. -- Alexandre Julliard julliard(a)winehq.org

May 30, 2007

Re: Call for Ubuntu-wine admin

by Tomas Zijdemans

Scott Richie has filled the position, since he is the one doing most wine related work in Ubuntu. Thanks for showing interest! I'm looking forward to making Wine rock in Ubuntu! Tomas.Zijdemans(a)student.uib.no wrote: > If someone is interested in leading the Ubuntu-wine team, please contact me. > > > >

May 30, 2007

Re: [ws2_32] getsockname should fail on unbound socket

by Kai Blin

On Wednesday 30 May 2007 07:56:31 Damjan Jovanovic wrote: > + case AF_INET: { > + const struct sockaddr_in *in = (struct sockaddr_in*) uaddr; > + return in->sin_port != 0; > + } Talking to Alexandre about this in IRC, he wanted me to check for all-null returns, so you probably should check if the IP address is 0.0.0.0 (or :: for IPv6), too. Also, I had the impression that the Wine convention was that case block braces go onto a new line, too. You might want to consider that for the switch you addded. Thanks for doing the work for me otherwise :) Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton.

May 30, 2007

Re: Fedora Packages

by Andreas Bierfert

On Sat, 5 May 2007 12:05:01 +0200 Andreas Bierfert <andreas.bierfert(a)lowlatency.de> wrote: > Hi, > > here is some news/status update on the fedora packages: And again a small update interesting for RHEL/Centos 4 users: All dependencies that where needed to build wine for EPEL 4 have been met and I just pushed a build for it. This means that EPEL [2] users can just install wine from the EPEL repository. > As people have been complaining about the link on the winehq webpage I have > taken the time to make a summary page[1] on the fedora wiki which is easier > for me to maintain and keep up-to-date and is probably more helpful. I would > request that the link in the download section is changed to that page. Could this please be changed. I get about 2-3 mails a day asking about this +) > [1] - http://fedoraproject.org/wiki/AndreasBierfert/Wine > [2] - http://fedoraproject.org/wiki/EPEL Regards, Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

May 30, 2007

Re: Implement the WriteEnvironmentStrings standard action

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > + HKEY env, root = HKEY_CURRENT_USER; ... > + if (flags & ENV_MOD_MACHINE) > + root = HKEY_LOCAL_MACHINE; It looks like root is not used. -- Dmitry.

May 29, 2007

Re: headers and one test

by Dmitry Timoshkov

"Evan Stade" <estade(a)gmail.com> wrote: > +WINE_DEFAULT_DEBUG_CHANNEL(gdip); > + > +COLORREF ARGB2COLORREF(ARGB color) > +{ If this is a module local function it should be static. > +GpStatus WINGDIPAPI GdipCreatePen1(ARGB color, FLOAT width, GpUnit unit, > + GpPen **pen) > +{ > + LOGBRUSH lb; > + GpPen *gp_pen; > + > + gp_pen = (GpPen*) malloc(sizeof(GpPen)); Do not use malloc in Wine, use HeapAlloc and friends. > + if(!pen){ return OutOfMemory; } if (!pen) return OutOfMemory; looks more naturally IMO without redundant braces, here and in other places. > +START_TEST(pen) > +{ > + GdiplusStartupInput gdiplusStartupInput; > + ULONG_PTR gdiplusToken; > + > + gdiplusStartupInput.GdiplusVersion=1; > + gdiplusStartupInput.DebugEventCallback=NULL; > + gdiplusStartupInput.SuppressBackgroundThread=0; > + gdiplusStartupInput.SuppressExternalCodecs=0; > + > + GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL); > + > + test_constructor_destructor(); > + > + GdiplusShutdown(gdiplusToken); It's better to check whether GdiplusStartup/GdiplusShutdown fail. > --- /dev/null > +++ b/include/GdiplusEnums.h > @@ -0,0 +1,39 @@ > +#ifndef _GP_ENUMERATIONS_H_ > +#define _GP_ENUMERATIONS_H_ > + > +typedef enum { > + UnitWorld = 0, /* seemingly equivalent to notion of "logical unit" */ > + UnitDisplay = 1, > + UnitPixel = 2, > + UnitPoint = 3, > + UnitInch = 4, > + UnitDocument = 5, > + UnitMillimeter = 6 > +} Unit; > + > +typedef enum { > + Ok = 0, > + GenericError = 1, > + InvalidParameter = 2, > + OutOfMemory = 3, > + ObjectBusy = 4, > + InsufficientBuffer = 5, > + NotImplemented = 6, > + Win32Error = 7, > + WrongState = 8, > + Aborted = 9, > + FileNotFound = 10, > + ValueOverflow = 11, > + AccessDenied = 12, > + UnknownImageFormat = 13, > + FontFamilyNotFound = 14, > + FontStyleNotFound = 15, > + NotTrueTypeFont = 16, > + UnsupportedGdiplusVersion = 17, > + GdiplusNotInitialized = 18, > + PropertyNotFound = 19, > + PropertyNotSupported = 20, > + ProfileNotFound = 21 > +} Status; Why are you duplicating dlls/gdiplus/gdip_enumerations.h? Besides my version of PSDK doesn't have Status in GdiplusEnums.h, they are in GdiPlusTypes.h. Otherwise the patch looks good. -- Dmitry.

May 29, 2007

Re: c++ code

by Dmitry Timoshkov

"Chris Robinson" <chris.kcat(a)gmail.com> wrote: > On Tuesday 29 May 2007 01:05:36 am Dmitry Timoshkov wrote: >> Yes, Microsoft doesn't support calling GDI+ flat API from anything but C++ >> wrappers. But it shouldn't be too hard to construct an appropriate object >> in plain C that represents GpBrush for instance. > > It depends if it's an actual C++ API (eg. exposing classes with non-virtual > methods and member variables), or pure-virtual interfaces grabbed through a C > API ala DirectX. If it's the former, it may not be possible to convert it all > to C due to the name mangling and/or calling convention differences between > Unix/GCC and Windows. For that, the only thing that may work is to make an > actual cross-compiled Win32 DLL. GpBrush is a pure implementation specific internal thing, as well as other "classes". So it's completely in an developer favour to put anything he likes to be there. -- Dmitry.

May 29, 2007

GDI+: headers and one test

by Evan Stade

Changelog: *Added public GDI+ headers in include/ *Added private GDI+ headers in dlls/gdiplus *Added small implementation of GDI+ pens in dlls/gdiplus/pen.c *Added (first) GDI+ test dlls/gdiplus/Makefile.in | 3 + dlls/gdiplus/gdip_defines.h | 43 +++++++++++++++++++ dlls/gdiplus/gdip_enumerations.h | 57 ++++++++++++++++++++++++++ dlls/gdiplus/gdiplus.c | 27 ++++++++++++ dlls/gdiplus/gdiplus.spec | 8 ++-- dlls/gdiplus/gdiplus_private.h | 43 +++++++++++++++++++ dlls/gdiplus/pen.c | 84 ++++++++++++++++++++++++++++++++++++++ dlls/gdiplus/pen.h | 30 ++++++++++++++ dlls/gdiplus/tests/Makefile.in | 13 ++++++ dlls/gdiplus/tests/pen.c | 44 ++++++++++++++++++++ include/Gdiplus.h | 10 +++++ include/GdiplusEnums.h | 39 ++++++++++++++++++ include/GdiplusFlat.h | 23 ++++++++++ include/GdiplusGpStubs.h | 10 +++++ include/GdiplusInit.h | 26 ++++++++++++ include/GdiplusTypes.h | 7 +++ 16 files changed, 462 insertions(+), 5 deletions(-) -Evan Stade

May 29, 2007

Re: Call for Ubuntu-wine admin

by Adam Petaccia

On Tue, 2007-05-29 at 01:28 +0200, Tomas.Zijdemans(a)student.uib.no wrote: > If someone is interested in leading the Ubuntu-wine team, please contact me. I was actually looking at how to do that earlier today. I would like to volunteer for the position.

May 29, 2007

Re: Pretty Build System (Take 3)

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Attached is a patch that reduces the verbosity of the build system by > printing the build commands in one of two formats: > COMMAND output_file > or > COMMAND input_file -> output_file > > I hope it meets Alexandre's requirements of not reducing portability > of Wine to other platforms (including Windows). The MAKEFLAGS stuff is still not portable, and I still think this belongs in make itself. Here's a quick proof of concept patch against GNU make. It needs a better algorithm for extracting the command name, and some sort of command-line option; this is left as an exercise for the reader. Index: job.c =================================================================== RCS file: /sources/make/make/job.c,v retrieving revision 1.186 diff -u -p -r1.186 job.c --- job.c 11 May 2007 20:57:21 -0000 1.186 +++ job.c 29 May 2007 21:07:47 -0000 @@ -1079,9 +1079,21 @@ start_job_command (struct child *child) /* Print out the command. If silent, we call `message' with null so it can log the working directory before the command's own error messages appear. */ + { + char *ptr, cmd[128]; - message (0, (just_print_flag || (!(flags & COMMANDS_SILENT) && !silent_flag)) - ? "%s" : (char *) 0, p); + strncpy( cmd, argv[0], sizeof(cmd)-1 ); + cmd[sizeof(cmd)-1] = 0; + if (!strcmp(cmd,"/bin/sh")) + { + if (argv[1] && !strcmp(argv[1],"-c")) strncpy( cmd, argv[2], sizeof(cmd)-1 ); + if ((ptr = strchr( cmd, ' ' ))) *ptr = 0; + } + if ((ptr = strrchr( cmd, '/' ))) memmove( cmd, ptr + 1, strlen(ptr+1) + 1 ); + + message (0, (just_print_flag || (!(flags & COMMANDS_SILENT) && !silent_flag)) + ? "[%s] %s" : (char *) 0, cmd, child->file->name); + } /* Tell update_goal_chain that a command has been started on behalf of this target. It is important that this happens here and not in -- Alexandre Julliard julliard(a)winehq.org

May 29, 2007

Re: Pretty Build System (Take 3)

by Kirill K. Smirnov

You probably forget to run 'autoconf'. I can see nice messages like: $ autoconf ... $ ./configure ... $ make depend ... $ make ... CC extrachunk.o CC factory.o CC getframe.o CC icmstream.o CC regsvr.o CC tmpfile.o >I get the following (on Slackware 11) while running the make depend >portion of ./configure && make depend && make && sudo make install: >make[1]: Entering directory `/home/speeddy/wine-git/tools' >../tools/makedep -C. -S.. -T.. -I/usr/include/freetype2 bin2res.c >fnt2bdf.c fnt2fon.c make_ctests.c makedep.c relpath.c sfnt2fnt.c >make[1]: Leaving directory `/home/speeddy/wine-git/tools' >make[1]: Entering directory `/home/speeddy/wine-git/tools' >make[1]: `makedep' is up to date. >make[1]: Leaving directory `/home/speeddy/wine-git/tools' >make[1]: Entering directory `/home/speeddy/wine-git/dlls' >make[2]: Entering directory `/home/speeddy/wine-git/dlls/acledit' >../../tools/makedep -C. -S../.. -T../.. main.c >make[2]: Leaving directory `/home/speeddy/wine-git/dlls/acledit' >make[2]: Entering directory `/home/speeddy/wine-git/dlls/acledit' >make[2]: MAKERULE_MAKEDEP@: Command not found >make[2]: *** [depend] Error 127 >make[2]: Leaving directory `/home/speeddy/wine-git/dlls/acledit' >make[1]: *** [acledit/__depend__] Error 2 >make[1]: Leaving directory `/home/speeddy/wine-git/dlls' >make: *** [dlls/__depend__] Error 2

May 29, 2007

Re: wininet: Add a new NETCON_query_data_available function.

by Stefan Leichter

Am Monday 28 May 2007 12:16 schrieb Robert Shearman: > Use it to implement the behaviour where InternetReadFileExA does a > synchronous request if the data is available and asynchronous otherwise. > --- > configure.ac | 1 + > dlls/wininet/internet.c | 49 > +++++++++++++++++++++++++++-------------- > dlls/wininet/internet.h | 1 + > dlls/wininet/netconnection.c | 35 ++++++++++++++++++++++++++++++ > 4 files changed, 69 insertions(+), 17 deletions(-) Hello, your patch broke the compilation for me. Bye Stefan make[2]: Entering directory `/usr/src/wine/wine-build/dlls/wininet' gcc -c -I../../../wine-git/dlls/wininet -I. -I../../../wine-git/include -I../../include -D__WINESRC__ -D_WINX32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o netconnection.o ../../../wine-git/dlls/wininet/netconnection.c ../../../wine-git/dlls/wininet/netconnection.c: In function ‘NETCON_query_data_available’: ../../../wine-git/dlls/wininet/netconnection.c:585: error: ‘WININET_NETCONNECTION’ has no member named ‘peek_msg’ ../../../wine-git/dlls/wininet/netconnection.c:586: error: ‘WININET_NETCONNECTION’ has no member named ‘peek_len’ make[2]: *** [netconnection.o] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/wininet'

May 29, 2007

Re: Pretty Build System (Take 3)

by Tom Spear

On 5/29/07, Robert Shearman <rob(a)codeweavers.com> wrote: > Hi, > > Attached is a patch that reduces the verbosity of the build system by > printing the build commands in one of two formats: > COMMAND output_file > or > COMMAND input_file -> output_file > > I hope it meets Alexandre's requirements of not reducing portability of > Wine to other platforms (including Windows). I get the following (on Slackware 11) while running the make depend portion of ./configure && make depend && make && sudo make install: make[1]: Entering directory `/home/speeddy/wine-git/tools' ../tools/makedep -C. -S.. -T.. -I/usr/include/freetype2 bin2res.c fnt2bdf.c fnt2fon.c make_ctests.c makedep.c relpath.c sfnt2fnt.c make[1]: Leaving directory `/home/speeddy/wine-git/tools' make[1]: Entering directory `/home/speeddy/wine-git/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/speeddy/wine-git/tools' make[1]: Entering directory `/home/speeddy/wine-git/dlls' make[2]: Entering directory `/home/speeddy/wine-git/dlls/acledit' ../../tools/makedep -C. -S../.. -T../.. main.c make[2]: Leaving directory `/home/speeddy/wine-git/dlls/acledit' make[2]: Entering directory `/home/speeddy/wine-git/dlls/acledit' make[2]: MAKERULE_MAKEDEP@: Command not found make[2]: *** [depend] Error 127 make[2]: Leaving directory `/home/speeddy/wine-git/dlls/acledit' make[1]: *** [acledit/__depend__] Error 2 make[1]: Leaving directory `/home/speeddy/wine-git/dlls' make: *** [dlls/__depend__] Error 2 -- Thanks Tom

May 29, 2007

Pretty Build System (Take 3)

by Robert Shearman

Hi, Attached is a patch that reduces the verbosity of the build system by printing the build commands in one of two formats: COMMAND output_file or COMMAND input_file -> output_file I hope it meets Alexandre's requirements of not reducing portability of Wine to other platforms (including Windows). -- Rob Shearman

May 29, 2007

Re: Call for Ubuntu-wine admin

by Vijay Kiran Kamuju

Hi I will be member, if you ask I may act as a leader. Thanks, VJ On 5/28/07, Tomas.Zijdemans(a)student.uib.no <Tomas.Zijdemans(a)student.uib.no> wrote: > If someone is interested in leading the Ubuntu-wine team, please contact me. > > > >

May 29, 2007

Re: Happy SOC'ing all.

by Jesse Allen

On 5/28/07, Bryan DeGrendel <sirnuke(a)gmail.com> wrote: > > > > I believe most non-bug fix changes will be limited to a small part of the > WINE tree (the mscoree dll), so creating an entire git fork is overkill for On the contrary, I believe that git is ideal for forking (and later merging) like this.

May 29, 2007

Crosscompile (mingw) failure with msxml3 tests

by Paul Vriens

Hi, I just wanted to report the current failures when crosscompiling the msxml3 tests with mingw (and thus no new winetest executable): xmldoc.cross.o:xmldoc.c:(.text+0x1a9): undefined reference to `_IID_IXMLDocument' xmldoc.cross.o:xmldoc.c:(.text+0x1c0): undefined reference to `_CLSID_XMLDocument' xmldoc.cross.o:xmldoc.c:(.text+0x149d): undefined reference to `_IID_IXMLDocument' xmldoc.cross.o:xmldoc.c:(.text+0x14b4): undefined reference to `_CLSID_XMLDocument' xmlelem.cross.o:xmlelem.c:(.text+0x22): undefined reference to `_IID_IXMLDocument' xmlelem.cross.o:xmlelem.c:(.text+0x39): undefined reference to `_CLSID_XMLDocument' xmlelem.cross.o:xmlelem.c:(.text+0x1425): undefined reference to `_IID_IXMLDocument' xmlelem.cross.o:xmlelem.c:(.text+0x143c): undefined reference to `_CLSID_XMLDocument' xmlelem.cross.o:xmlelem.c:(.text+0x1c46): undefined reference to `_IID_IXMLElement' xmlelem.cross.o:xmlelem.c:(.text+0x1f0f): undefined reference to `_IID_IXMLElement' collect2: ld returned 1 exit status make: *** [msxml3_crosstest.exe] Error 1 These started to happen after the addition of some patches made by James Hawkins (Add tests for [IXMLElement|IXMLDocument]) on May 26th. Cheers, Paul.

May 29, 2007

uninstaller: Shorten variable name length.. Whats wrong?

by Tom Spear

Just curious to know if there was something wrong with this patch, or if maybe it wasnt committed due to being a cosmetic change? If it's the latter, I'll just resend the other 2 parts of the patch (2and 3 of 3) against the code the way it is instead of changing the lines.. On 5/23/07, Tom Spear <speeddymon(a)gmail.com> wrote: > This patch shortens the length of some lines in > FetchUninstallInformation, as suggested by Peter Beutner > > -- > Thanks > > Tom > > -- Thanks Tom

May 29, 2007

Re: c++ code

by Chris Robinson

On Tuesday 29 May 2007 01:05:36 am Dmitry Timoshkov wrote: > Yes, Microsoft doesn't support calling GDI+ flat API from anything but C++ > wrappers. But it shouldn't be too hard to construct an appropriate object > in plain C that represents GpBrush for instance. It depends if it's an actual C++ API (eg. exposing classes with non-virtual methods and member variables), or pure-virtual interfaces grabbed through a C API ala DirectX. If it's the former, it may not be possible to convert it all to C due to the name mangling and/or calling convention differences between Unix/GCC and Windows. For that, the only thing that may work is to make an actual cross-compiled Win32 DLL.

May 29, 2007

[wiki] Child pages mess up the logo-location

by Paul Vriens

Hi, Every now and then I check for the 'Recent Changes' on the wiki. The following page caught my attention: http://wiki.winehq.org/MaartenLankhorst/SOC2007 This page is actually named "MaartenLankhorst/SOC2007" and is a child of the 'MaartenLankhorst' page. This page messes up the logo in the top-left corner. When looking at the properties of the logo it shows 'http://wiki.winehq.org/MaartenLankhorst/logo.png' instead of the correct 'http://wiki.winehq.org/logo.png'. The same logic is true for http://wiki.winehq.org/MacOSX/FAQs (and probably others). Just thought I mention it. Cheers, Paul.

May 29, 2007

Re: Start of an opengl-based gdi driver

by Stefan Dösinger

Am Dienstag 29 Mai 2007 00:31 schrieb Frank Richter: > On 28.05.2007 22:23, Stefan Dösinger wrote: > > loads it into an opengl > > texture(GL_ALPHA) and records 256 display lists to draw textured quads. > > So far no unicode support, no custom pens, but custom fonts work. > > One trick I've seen (in CEGUI) is to use one font texture per Unicode > plane. So the page you attached would be the texture for plane 0 (ie > ISO-8859-1). > > Also, why display lists? Each character is a quad. You could draw the > text from simple quads, with some buffering to reduce overhead. To cache the texture coordinate calculations, and in the hope that the driver can cache something internally. The red book also recommends the use of display lists for this, and display lists are fairly easy to call and record. As for the unicode planes, yes, that's my plan, but just not implemented yet :-)

May 29, 2007

Re: c++ code

by Dmitry Timoshkov

"Evan Stade" <estade(a)gmail.com> wrote: > The API prototypes use types that are defined as C++ classes. For example, > one prototype (from GdiPlusFlat.h) is > > GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **cloneBrush); > > And GpBrush is defined as > > class GpBrush {}; Yes, Microsoft doesn't support calling GDI+ flat API from anything but C++ wrappers. But it shouldn't be too hard to construct an appropriate object in plain C that represents GpBrush for instance. -- Dmitry.

May 29, 2007

Re: c++ code

by Evan Stade

On 5/28/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > > "Evan Stade" <estade(a)gmail.com> wrote: > > > Well the Platform SDK headers use C++. From gdiplus.h: > > > > ... > > namespace DllExports > > { > > #include "GdiplusFlat.h" > > }; > > ... > > > > And if you try to just include GdiplusFlat.h (i.e . only using the gdi+ > flat > > api), you have to include GdiplusGpStubs.h. From GdiplusGpStubs.h: > > > > ... > > class GpBrush {}; > > class GpTexture : public GpBrush {}; > > ... > > > > So it would be impossible to compile any conformance test for gdi+ in C > > using the platform sdk headers. In my eyes it seems that there are 2 > > options: edit the platform sdk headers so that they are compatible with > C > > code (change "class GpFoo {};" to "typedef void GpFoo") or use g++ to > > compile. Are you suggesting the former over the latter? > > All you need are the API prototypes, and you can get those without > including > headers that use C++. > > -- > Dmitry. > The API prototypes use types that are defined as C++ classes. For example, one prototype (from GdiPlusFlat.h) is GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **cloneBrush); And GpBrush is defined as class GpBrush {};

May 29, 2007

Re: c++ code

by Dmitry Timoshkov

"Evan Stade" <estade(a)gmail.com> wrote: > Well the Platform SDK headers use C++. From gdiplus.h: > > ... > namespace DllExports > { > #include "GdiplusFlat.h" > }; > ... > > And if you try to just include GdiplusFlat.h (i.e . only using the gdi+ flat > api), you have to include GdiplusGpStubs.h. From GdiplusGpStubs.h: > > ... > class GpBrush {}; > class GpTexture : public GpBrush {}; > ... > > So it would be impossible to compile any conformance test for gdi+ in C > using the platform sdk headers. In my eyes it seems that there are 2 > options: edit the platform sdk headers so that they are compatible with C > code (change "class GpFoo {};" to "typedef void GpFoo") or use g++ to > compile. Are you suggesting the former over the latter? All you need are the API prototypes, and you can get those without including headers that use C++. -- Dmitry.

May 28, 2007

Call for Ubuntu-wine admin

by Tomas.Zijdemans＠student.uib.no

If someone is interested in leading the Ubuntu-wine team, please contact me.

May 28, 2007

Re: Happy SOC'ing all.

by Bryan DeGrendel

On 5/28/07, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > > John Klehm schreef: > > Hey Maarten and all, > > > > Good idea about publishing the changes. I was thinking to use > > Google's project hosting thing for mine I think it supports SVN or > > something though. Guess I can try and figure out a git feed on a > > different server too, we'll see. > Git is the repository system wine uses, see http://wiki.winehq.org/GitWine > > To set up a repo first you have to register a fork of wine.git, then set > some settings and choose 'Push' rather then cloning a tree. > > To update your git repository for it, create a file in wine-git like this: > Filename: .git/remotes/sound > --- (Begin of file) --- > URL: git+ssh://username(a)repo.or.cz/srv/git/wine/sound.git > Push: refs/heads/master:refs/heads/master > ---(End of file)--- > > Then you can do something like: > git push -f sound HEAD:refs/heads/master > > Of course replace username with your username, and sound with how you > call your branch. To edit project settings, your username for it seems > to be something like: wine/branchname (without .git at end) and project > password you set yourself. Hope this is helpful for others too. > > Just want to say hello and good luck. I'm glad to be here =) > As do I, > > Maarten I believe most non-bug fix changes will be limited to a small part of the WINE tree (the mscoree dll), so creating an entire git fork is overkill for myself. I have setup a subversion repository @ [ http://svn.degrendel.com/soc2007 ], where I will be keeping patches, notes, and so on. Anyways, best of luck to everyone. -Working on .NET/Mono. Bryan DeGrendel

May 28, 2007

Re: Start of an opengl-based gdi driver

by Frank Richter

On 28.05.2007 22:23, Stefan Dösinger wrote: > loads it into an opengl > texture(GL_ALPHA) and records 256 display lists to draw textured quads. So > far no unicode support, no custom pens, but custom fonts work. One trick I've seen (in CEGUI) is to use one font texture per Unicode plane. So the page you attached would be the texture for plane 0 (ie ISO-8859-1). Also, why display lists? Each character is a quad. You could draw the text from simple quads, with some buffering to reduce overhead. -f.r.

May 28, 2007

Re: Happy SOC'ing all.

by Maarten Lankhorst

John Klehm schreef: > Hey Maarten and all, > > Good idea about publishing the changes. I was thinking to use > Google's project hosting thing for mine I think it supports SVN or > something though. Guess I can try and figure out a git feed on a > different server too, we'll see. Git is the repository system wine uses, see http://wiki.winehq.org/GitWine To set up a repo first you have to register a fork of wine.git, then set some settings and choose 'Push' rather then cloning a tree. To update your git repository for it, create a file in wine-git like this: Filename: .git/remotes/sound --- (Begin of file) --- URL: git+ssh://username(a)repo.or.cz/srv/git/wine/sound.git Push: refs/heads/master:refs/heads/master ---(End of file)--- Then you can do something like: git push -f sound HEAD:refs/heads/master Of course replace username with your username, and sound with how you call your branch. To edit project settings, your username for it seems to be something like: wine/branchname (without .git at end) and project password you set yourself. Hope this is helpful for others too. > Just want to say hello and good luck. I'm glad to be here =) As do I, Maarten

May 28, 2007

Re: Happy SOC'ing all.

by John Klehm

Hey Maarten and all, Good idea about publishing the changes. I was thinking to use Google's project hosting thing for mine I think it supports SVN or something though. Guess I can try and figure out a git feed on a different server too, we'll see. Just want to say hello and good luck. I'm glad to be here =) John Klehm - Tablet PC Support On 5/28/07, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > > For all other students joining SummerOfCode, I think it's a good idea if > we have a public place where we can see each other's changes. > > I set up my own fork, sound.git at http://repo.or.cz/w/wine.git - if > others want to do the same I encourage them to do so, it's easy when you > figure out how to git push. > > Since soc now officially started (according to date, in holland anyway), > I just want to say: > - Happy coding > - Good luck all > > Cheers, > Maarten > > >

May 28, 2007

Re: Start of an opengl-based gdi driver

by Stefan Dösinger

Hi, A few additions to my previous mail - Why can't I think about all this when I'm writing the mail. A GDI engine won't help Direct3D applications because the gdi engine still operates in system memory. It would not avoid the need of downloading from opengl and uploading again. A GDI engine can help DirectDraw Games(although this can be improved in wined3d too), and other apps making heavy use of DIB sections with direct access. DDraw can be improved by moving the rendering from wined3d's code to the X server. This would shift the expensive opertions away from GetDC to surface locking. And my font manager: I'm aware that I can't store the font Handle, I have to store the LOGFONT structure, together with the pen settings. This was just a quick and dirty way which works for most apps. But in theory the font handle can be destroyed and another one recreated with the same value but different settings.

May 28, 2007

Re: c++ code

by Evan Stade

On 5/26/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > > "Evan Stade" <estade(a)gmail.com> writes: > > > I want to write conformance tests for gdiplus and that requires the use > of > > c++. Even if I were to focus on the gdi+ flat api, the windows SDK > headers > > for that have c++ code in them, also eventually when the gdi+ c++ > wrappers > > are written on top of the flat api then we will need to be able to > compile > > c++ in the wine environment. What do I have to do to be able to write > these > > tests? > > I don't see any need to use C++ for that. All the exported APIs are > callable from C code, and the corresponding headers are C compatible > too. > > -- > Alexandre Julliard > julliard(a)winehq.org > Well the Platform SDK headers use C++. From gdiplus.h: ... namespace DllExports { #include "GdiplusFlat.h" }; ... And if you try to just include GdiplusFlat.h (i.e . only using the gdi+ flat api), you have to include GdiplusGpStubs.h. From GdiplusGpStubs.h: ... class GpBrush {}; class GpTexture : public GpBrush {}; ... So it would be impossible to compile any conformance test for gdi+ in C using the platform sdk headers. In my eyes it seems that there are 2 options: edit the platform sdk headers so that they are compatible with C code (change "class GpFoo {};" to "typedef void GpFoo") or use g++ to compile. Are you suggesting the former over the latter? -Evan Stade

May 28, 2007

Happy SOC'ing all.

by Maarten Lankhorst

For all other students joining SummerOfCode, I think it's a good idea if we have a public place where we can see each other's changes. I set up my own fork, sound.git at http://repo.or.cz/w/wine.git - if others want to do the same I encourage them to do so, it's easy when you figure out how to git push. Since soc now officially started (according to date, in holland anyway), I just want to say: - Happy coding - Good luck all Cheers, Maarten

May 28, 2007

Start of an opengl-based gdi driver

by Stefan Dösinger

Hi, One of our remaining fundamental d3d problems is the slowness of IDirectDrawSurface7::GetDC(and d3d9). This call allows performing gdi operations on surfaces. Currently this is handled through downloading the opengl surface, performing the gdi operation, and uploading it again. This is slow, especially on render targets. On textures this is rarely used, and wined3d can better cache the texture. Most applications use it to render text text on the back buffer. Applications I have are the d3d7 sdk demos, Empire Earth, Prince of Persia 3D, Age of Empires 2. Sometimes it is also used to load textures with a BitBlt. I have discussed two ways of solving this issue with alexandre. One was to tell the X server to perform the calls in opengl(EXT_texture_from_pixmap looked promissing), the other one was writing an opengl gdi driver in wined3d. The X server approach failed because there is just no API to get that handled, and EXT_texture_from_pixmap explicitly doesn't do that job, and even if there is a hacky way driver support will be bad. So I spent the last days to check how an implementation in wined3d would work - and here it is. So far this driver handles only ExtTextOutW, and I only successfully used it with the directx sdk samples. ExtTextOut uses a Helper device context(normal gdi) to get the glyphs with GetGlyphOutline, loads it into an opengl texture(GL_ALPHA) and records 256 display lists to draw textured quads. So far no unicode support, no custom pens, but custom fonts work. I have 2 screenshots of a dx7 sdk demo with classic getdc and the opengl driver(radeon M9, 1.6 ghz pentium M, 512 mb ram). There seems to be some parameter missing, the text is slightly displaced. Tex.gif(attached) is the created font texture(warning, white text on transparent background). http://stud4.tuwien.ac.at/~e0526822/gl.png http://stud4.tuwien.ac.at/~e0526822/gdi.png One problem of this approach is that the driver has to handle everything. However, I keep a DIB section of the size of the surface, and if I encounter some unsupported call I can print a FIXME, download from gl and call the dib section to do the job. After ReleaseDC the surface code has to upload it again. Its the slow old behavior, so we don't gain anything for unsupported calls, but its no loss either. So far most forward functions are missing, so the DIB driver refuses to initialize itself - Edit CreateDC in dlls/wined3d/gdi.c to activate it. ExtTextOut has an example how the forwarding looks like. A big problem I still have are operations that involve 2 device contexts. Prince of Persia 3D(good test case for custom fonts) calls StretchBlit from/to my gl dc. So in X11drv one of the physdevs is a WineD3DSurfaceImpl * instead of a WINEX11DRV_PHSYDEV * - not good. So far I haven't found a way to let x11drv access my surface data, or enforce that my function is called, fetch the hdc from the x11 phsydev and call my fallback dc, or request the device's content from x11drv and handle the blit myself.

May 28, 2007

Start of an opengl-based gdi driver

by Stefan Dösinger

Hi, One of our remaining fundamental d3d problems is the slowness of IDirectDrawSurface7::GetDC(and d3d9). This call allows performing gdi operations on surfaces. Currently this is handled through downloading the opengl surface, performing the gdi operation, and uploading it again. This is slow, especially on render targets. On textures this is rarely used, and wined3d can better cache the texture. Most applications use it to render text text on the back buffer. Applications I have are the d3d7 sdk demos, Empire Earth, Prince of Persia 3D, Age of Empires 2. Sometimes it is also used to load textures with a BitBlt. I have discussed two ways of solving this issue with alexandre. One was to tell the X server to perform the calls in opengl(EXT_texture_from_pixmap looked promissing), the other one was writing an opengl gdi driver in wined3d. The X server approach failed because there is just no API to get that handled, and EXT_texture_from_pixmap explicitly doesn't do that job, and even if there is a hacky way driver support will be bad. So I spent the last days to check how an implementation in wined3d would work - and here it is. So far this driver handles only ExtTextOutW, and I only successfully used it with the directx sdk samples. ExtTextOut uses a Helper device context(normal gdi) to get the glyphs with GetGlyphOutline, loads it into an opengl texture(GL_ALPHA) and records 256 display lists to draw textured quads. So far no unicode support, no custom pens, but custom fonts work. Attached are 2 screenshots of a dx7 sdk demo with classic getdc and the opengl driver(radeon M9, 1.6 ghz pentium M, 512 mb ram). There seems to be some parameter missing, the text is slightly displaced. Tex.gif is the created font texture(warning, white text on transparent background) One problem of this approach is that the driver has to handle everything. However, I keep a DIB section of the size of the surface, and if I encounter some unsupported call I can print a FIXME, download from gl and call the dib section to do the job. After ReleaseDC the surface code has to upload it again. Its the slow old behavior, so we don't gain anything for unsupported calls, but its no loss either. So far most forward functions are missing, so the DIB driver refuses to initialize itself - Edit CreateDC in dlls/wined3d/gdi.c to activate it. ExtTextOut has an example how the forwarding looks like. A big problem I still have are operations that involve 2 device contexts. Prince of Persia 3D(good test case for custom fonts) calls StretchBlit from/to my gl dc. So in X11drv one of the physdevs is a WineD3DSurfaceImpl * instead of a WINEX11DRV_PHSYDEV * - not good. So far I haven't found a way to let x11drv access my surface data, or enforce that my function is called, fetch the hdc from the x11 phsydev and call my fallback dc, or request the device's content from x11drv and handle the blit myself.

May 28, 2007

Re: New Gecko package

by Jacek Caban

Luke Bratch wrote: > > Perfect, that fixes all regressions that I can find - > and the scroll bars still work in Steam! > Great, thanks. I will wait until tomorrow and then upload it to SourceForge. Some changes in Gecko installer will be needed to support different package versions. Thanks, Jacek

May 28, 2007

Re: New Gecko package

by Jacek Caban

Jacek Caban wrote: > I've attached a hack from Picasa tree that > causes links opening in new window to be opened in winebrowser. I forgot to attach the patch. Here it is. Jacek

May 28, 2007

Re: New Gecko package

by Luke Bratch

--- Jacek Caban <jacek(a)codeweavers.com> wrote: > Thanks a lot for testing! You've found a serious > problem with handling > https protocol (shame on Mozilla build system). I've > fixed it and did > serious changes in the package. I hope it's a final > version of the package: > > http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko.zip Perfect, that fixes all regressions that I can find - and the scroll bars still work in Steam! Thanks Luke ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

May 28, 2007

Re: New Gecko package

by Jacek Caban

Vitaliy Margolen wrote: > Jacek Caban wrote: > >> Vitaliy Margolen wrote: >> >>>>> BTW why JavaScript doesn't work or any pop-up windows don't open? I know >>>>> this works fine with Firefox. >>>>> >>>>> >>>>> >>>> It needs some support from Gecko embedder (MSHTML in our case) and I >>>> haven't worked on it yet (with exception of built in alert pop-up). >>>> >>>> >>> You mean that what Wine has now uses gecko for just HTML rendering and >>> nothing else?! That you are pretty much rewriting the whole browser from >>> the scratch?!! How is that better then what we had before?!!! >>> >>> >> Well, it would be perfect if we used it only for rendering... but I >> don't think we'll ever reach that state. Just take a look at how deep an >> API may meddle with a HTML document. In case of pop-ups Gecko asks the >> embedder to create the window. It's not like IE API, which is a complete >> browser. Pop-up window is, in fact, a new IE window. Gecko isn't >> anything like a complete web browser, it's just an engine. The embedder >> creates a window and integrates it with its other windows. In case of >> Wine it's not trivial, as this new window should be, in fact, an IE >> window with its associated MSHTML object etc. >> >> > So you want to say that we will never have pages with embedded > JavaScript working in Wine? > It already works! I only said that pop-ups don't work. >>> The impression you gave about a year ago that Mozilla active-X controls >>> needed number of things modified, but other then that it worked fine. >>> >>> >> And my impression was that people would like to use apps like Picasa and >> Steam out of box with perspectives of getting much more instead of >> having a lots of "won't fix" bugs. >> >> > Indeed they would. Only I would say picasa to steam ratio would be > 1-to-100. Hm, where do you have those statistics from? How do you know how many apps are *fixed* by switch to the new implementation? > And btw only most rudimentary things work in both! Steam > worked _perfectly_ before. And I'm sure would still worked. But now, you > can't buy stuff, you can't open screen-shots (because they are popups) > you don't see MOTO when joining servers, lots of things do not work. So > I would use Steam as an example on the contrary. > Steam didn't work at all unless you used Mozilla ActiveX control used by TG that had some unacceptable forthe main Gecko tree hacks. I didn't know about pop-ups in Steam. I've attached a hack from Picasa tree that causes links opening in new window to be opened in winebrowser. It's a nicer behavior than opening them in our IE replacement, but it's not guaranteed to work (app doesn't have control over it, different cookie manager...). As I wrote, correct implementation is much more complicated, but we're getting nearer to it. Eg. implementing InternetExplorer object (more or less that's what iexplore.exe is) was a big step forward. Anyway if the attached patch helps, it may go to Git IMO. >>> Here I see only most rudimentary things work, and everything else would >>> probably never work. And Wine is open for stream of never ending >>> security issues, that so far no one even risen. >>> >>> >> Well, if you call apps like Outlook a rudimentary thing... Sure, there >> > Yes they are! Most e-mails don't have anything even close to most simple > website has. > Not from API point of view. First of all app has to be able to embed HTML, then we can think about how nicely is HTML handled. > >> still is a lot to do, but with correct architecture we can support more >> complex apps. Mozilla ActiveX control will never allow us to run >> programs like Outlook. And it's not the only example. Pop-ups, in >> particular, arn't too interesting as apps that embed HTML documents >> don't usually use them. >> > Ok if we can support more apps, then why aren't we? > Aren't we? Still more and more works. Take a look at number of MSHTML patches. Do you think they are only to make Wine compilation time longer? > Do you have a todo list? Yes, fix a few MSHTML bugs I'm working ATM, then come back to activation context to get it accepted to Wine. I usually target on a specific app and fix it, so I have no clear todo list. There are a few hacks I'd like to fix (we're slowly getting there) and find time to make bug hunting on bugzilla. > Or at least a list of what needs to be done before we can open a > stinking popup? > Test how exactly does WebBrowser/MSHTM/InternetExplorer interface in this case and implement it or stay with the attached patch for now. > Or what all needs to be done to get JavaScrip working? > As I wrote, it works. JavaScript is not only for pop-ups. >>> I hate to sound negative about things here, but how hard will it be to >>> put things back the way they were before? Or at least make it possible >>> to use Mozilla ActiveX controls instead of wine_gecko? >>> >>> >> It'd be quite simple, but don't count on my support in it. I very much >> disagree with such ideas and I prefer concentrating on improving MSHTML >> rather than looking for ugly workarounds. Mozilla ActiveX control may >> work only for WebBrowser control but it *can't* work with MSHTML. >> >> > The thing is, I personally, as well as most users want things *to work*. > Users don't care how proper the architecture is. With Mozilla ActiveX > things used to and still does work! But now Wine can't use it, because > you removed such possibility. What's wrong with having two alternative > implementation? Let users decide what they want - Picasa, Outlook or Steam. > It will add configure option that we will want to remove anyway. Jacek

May 28, 2007

Re: New Gecko package

by Jacek Caban

Luke Bratch wrote: > Yup this fixes that problem for me, however I've found > another regression. > > If you view for instance this page in most browsers > including the old wine Gecko, you will see "Buy Now" > buttons: > > http://www.tghost.co.uk/sale.html > > But with the new one, they are rendered as the > alternative text rather the image. > Thanks a lot for testing! You've found a serious problem with handling https protocol (shame on Mozilla build system). I've fixed it and did serious changes in the package. I hope it's a final version of the package: http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko.zip Thanks, Jacek

May 28, 2007

winmm: PlaySound SND_ASYNC fix

by Vedran Rodic

Hi, this patch is still not applied though I've submitted it last Wednesday. I guess it's not obviously clear that it is correct, so I'm asking for a review here. I've peronally tested it with alsa and oss sound backends. It specifically fixes one series of Croatian child educational games named "Suncica". Detailed info: Applications expect PlaySound() not to block when called with SND_ASYNC flag. However, if a sound is currently playing, there is a real chance of PlaySound() blocking for up to 1/3 of a second (size of the playsound buffer), because of a sound buffer waiting to be played. This patch adds a hWave field in the WINE_PLAYSOUND internal struct in winemm.h so that MULTIMEDIA_PlaySound() function can call waveOutReset when a sound is already playing to quickly remove it from the sound system. Another scenario is when application wants to quickly stop a currently playing sound at a specific time. Blocking behaviour isn't necessarily a problem for such applications, but playing the sound for additional 300 miliseconds could be. ChangeLog entry: Vedran Rodic <vrodic(a)gmail.com> - fix PlaySound so it doesn't block when another sound is already playing. Thanks

May 28, 2007

Re: ddraw/tests: Fix compilation with Visual C++ 2005.

by Francois Gouget

On Sun, 27 May 2007, Stefan Dösinger wrote: > > - light.dvAttenuation0 = 0.0 / 0.0; /* NaN */ > > + light.dvAttenuation0 = zero / zero; /* NaN */ > Are you sure the compiler doesn't optimize that away to 1.0 ? I added a printf to see what's the value of dvAttenuation0 after the assignment and got the expected result in each case. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

May 27, 2007

Re: setupapi/tests: There is no strncascmp() on Windows. So we mustuse msvcrt's _strnicmp() function instead.

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > 4. use a kernel32 export lstrcmpiA s/lstrcmpiA/CompareStringA -- Dmitry.

May 27, 2007

Re: setupapi/tests: There is no strncascmp() on Windows. So we must use msvcrt's _strnicmp() function instead.

by Dmitry Timoshkov

"Francois Gouget" <fgouget(a)free.fr> wrote: > There are other alternatives: > * we could have an #ifdef _MSC_VER to switch between strncasecmp() and > _strnicmp(). > * we could reimplement _strnicmp(). > * or maybe the test could be modified to not need this function at all? 4. use a kernel32 export lstrcmpiA P.S. Even in Wine code strncasecmp/strcasecmp should be deprecated since it uses wrong locale. -- Dmitry.

May 27, 2007

Re: how to compile test cases?

by Dmitry Timoshkov

"RusH" <citizenr(a)gmail.com> wrote: > rasz(a)capek:/media/hdc6/home/rasz/source/wine/dlls/ws2_32$ make test > make: Nothing to be done for `test'. > rasz(a)capek:/media/hdc6/home/rasz/source/wine/dlls/ws2_32$ make crosstest > make: Nothing to be done for `crosstest'. > > I want to build only ws2_32 tests, preferably using mingw. Try the commands above after 'cd tests'. -- Dmitry.

May 27, 2007

how to compile test cases?

by RusH

rasz(a)capek:/media/hdc6/home/rasz/source/wine/dlls/ws2_32$ make test make: Nothing to be done for `test'. rasz(a)capek:/media/hdc6/home/rasz/source/wine/dlls/ws2_32$ make crosstest make: Nothing to be done for `crosstest'. I want to build only ws2_32 tests, preferably using mingw. -- Who logs in to gdm? Not I, said the duck.

May 27, 2007

Re: ddraw/tests: Fix compilation with Visual C++ 2005.

by Stefan Dösinger

> - light.dvAttenuation0 = 0.0 / 0.0; /* NaN */ > + light.dvAttenuation0 = zero / zero; /* NaN */ Are you sure the compiler doesn't optimize that away to 1.0 ?

May 27, 2007

Re: The ddraw tests don't compile with Visual C++ 2005.

by Francois Gouget

On Sun, 27 May 2007, Marcus Meissner wrote: [...] > Why doesn't the code try using the INFINITY and NAN #defines? > Would this help with Visual C++? Do you mean the INFINITY macro defined in /usr/include/bits/inf.h? (which one gets through math.h) I have not found any macro called INFINITY in the PSDK or the Visual C++ headers. So this would not work. Visual C++'s math.h header has a _HUGE and a HUGE symbol that look like they could be +INFINITY but this would not work in Wine (Winelib apps cannot import exported variables). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

May 27, 2007

Re: The ddraw tests don't compile with Visual C++ 2005.

by Marcus Meissner

On Sun, May 27, 2007 at 01:17:23PM +0200, Francois Gouget wrote: > > Visual C++ 2005 does not like the way we compute the infinity and NaN > values. I've tried replacing the current divisions by zero with > arithmetic on FLT_MAX (at least for the infinity calculations), but it > did not like that either. > > Does anyone know how to make these calculations portable? > How does one get at these values on Windows? > > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > [...] > light.dvAttenuation0 = -1.0 / 0.0; /* -INFINITY */ > [...] > light.dvAttenuation0 = 1.0 / 0.0; /* +INFINITY */ > [...] > light.dvAttenuation0 = 0.0 / 0.0; /* NaN */ Why doesn't the code try using the INFINITY and NAN #defines? Would this help with Visual C++? Ciao, Marcus

May 27, 2007

Re: wined3d: Implement support for gamma corrected (sRGB) texture loading

by Stefan Dösinger

Appart of two things Henri already said the patch looks good to me(Use device in texture.c, break out the changes to surface_upload_data and surface_download data into seperate patches). As for a wine test, I think its not easy to test it reliably since the opengl extension gives implementors quite a lot of room and doesn't require exact results. I think all we can reasonably test for are the oddnessnes hl2 requires, like gamma-corrected Q8W8V8U8 and what the rendering outcome is - but that should go into a different patch.

May 27, 2007

Re: The ddraw tests don't compile with Visual C++ 2005.

by Stefan Dösinger

Am Sonntag 27 Mai 2007 13:17 schrieb Francois Gouget: > Visual C++ 2005 does not like the way we compute the infinity and NaN > values. I've tried replacing the current divisions by zero with > arithmetic on FLT_MAX (at least for the infinity calculations), but it > did not like that either. > > Does anyone know how to make these calculations portable? > How does one get at these values on Windows? Does it like less obvious calculations, like float one = 1.0; float zero = 0.0; float infinity = one / zero; float nan = zero / zero; I couldn't find any usable way of getting a NaN and INF, only the test for it via isNaNf. The same problem will occur in d3d8 and d3d9 I think.

May 27, 2007

[PATCH 4/4] dpnhupnp: Implement IDirectPlayNatHelper stub

by Vijay Kiran Kamuju

Hi, It seems there is a problem with the fake dll entry for dpnhupnp.dll in wine.inf @@ -2129,6 +2129,7 @@ HKLM,%CurrentVersion%\Telephony\Country List\998,"SameAreaRule",,"G" 11,,dmusic.dll,1 11,,dplayx.dll,1 11,,dpnet.dll,1 +11,,dpnhupnp,1 11,,dsound.dll,1 11,,dswave.dll,1 11,,dxdiagn.dll,1 The ebtry should have been 11,,dpnhupnp.dll,1 Correct and resend Thanks, VJ

May 27, 2007

The ddraw tests don't compile with Visual C++ 2005.

by Francois Gouget

Visual C++ 2005 does not like the way we compute the infinity and NaN values. I've tried replacing the current divisions by zero with arithmetic on FLT_MAX (at least for the infinity calculations), but it did not like that either. Does anyone know how to make these calculations portable? How does one get at these values on Windows? diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c [...] light.dvAttenuation0 = -1.0 / 0.0; /* -INFINITY */ [...] light.dvAttenuation0 = 1.0 / 0.0; /* +INFINITY */ [...] light.dvAttenuation0 = 0.0 / 0.0; /* NaN */ -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

May 27, 2007

Re: wined3d: Implement support for gamma corrected (sRGB) texture loading

by H. Verbeet

On 27/05/07, Phil Costin <philcostin(a)hotmail.com> wrote: > Hi, > > This patch has been a long time in the making. The following test was used > during the creation of the patch: > > http://ati.amd.com/developer/samples/dx9/sRGBTest.html > If it's not too much trouble, a proper wine test would be nice. The changes to surface_upload_data and surface_download_data look like they should be separate changes. In cubetexture.c, and similar code in texture.c and volume.c: > + } else if (GL_SUPPORT(EXT_TEXTURE_SRGB) && This->baseTexture.bindCount > 0) { > + currentSrgbMode = This->resource.wineD3DDevice->stateBlock->samplerState[This->baseTexture.sampler][WINED3DSAMP_SRGBTEXTURE]; > + srgbModeChanged = (This->baseTexture.srgbWhenLoaded != currentSrgbMode); > + This->baseTexture.srgbWhenLoaded = currentSrgbMode; You've got "device" here, no need to use "This->resource.wineD3DDevice" sRGBmode looks a bit awkward as a variable name, I'd rather see something like srgb_mode, but I guess that's more a personal preference. It would also probably be better to submit/commit this right after a release instead of right before one.

May 27, 2007

Re: Wine does not compile

by Marcus Meissner

On Sun, May 27, 2007 at 10:36:44AM +0200, martin pilka wrote: > > Hello, > > I just tried to compile Wine on Ubuntu 6.06 and Ubuntu 7.04 (both updated). On > both machines, I got following error: > > make[2]: Entering directory `/home/mpilka/cxtest/wine/dlls/msxml3' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o > attribute.o attribute.c > In file included from attribute.c:32: > msxml_private.h:67: error: expected declaration specifiers or ‘...’ before > ‘xmlNodePtr’ > msxml_private.h:68: error: expected declaration specifiers or ‘...’ before > ‘xmlNodePtr’ > make[2]: *** [attribute.o] Error 1 > make[2]: Leaving directory `/home/mpilka/cxtest/wine/dlls/msxml3' > make[1]: *** [msxml3] Error 2 > make[1]: Leaving directory `/home/mpilka/cxtest/wine/dlls' > make: *** [dlls] Error 2 > > > Just wanted to let you know that, Which libxml2 version is used? and what is reported by: grep HAVE_LIBXML include/config.h Ciao, Marcus

May 27, 2007

Re: Wine does not compile

by martin pilka

I see Bryan already submitted patch for this. Going to try to install libxml-dev thing in meantime. Thanks, Martin > Hello, > > I just tried to compile Wine on Ubuntu 6.06 and Ubuntu 7.04 (both updated). On > both machines, I got following error: > > make[2]: Entering directory `/home/mpilka/cxtest/wine/dlls/msxml3' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o > attribute.o attribute.c > In file included from attribute.c:32: > msxml_private.h:67: error: expected declaration specifiers or ‘...’ before > ‘xmlNodePtr’ > msxml_private.h:68: error: expected declaration specifiers or ‘...’ before > ‘xmlNodePtr’ > make[2]: *** [attribute.o] Error 1 > make[2]: Leaving directory `/home/mpilka/cxtest/wine/dlls/msxml3' > make[1]: *** [msxml3] Error 2 > make[1]: Leaving directory `/home/mpilka/cxtest/wine/dlls' > make: *** [dlls] Error 2 > > > Just wanted to let you know that, > Martin

May 27, 2007

Wine does not compile

by martin pilka

Hello, I just tried to compile Wine on Ubuntu 6.06 and Ubuntu 7.04 (both updated). On both machines, I got following error: make[2]: Entering directory `/home/mpilka/cxtest/wine/dlls/msxml3' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o attribute.o attribute.c In file included from attribute.c:32: msxml_private.h:67: error: expected declaration specifiers or ‘...’ before ‘xmlNodePtr’ msxml_private.h:68: error: expected declaration specifiers or ‘...’ before ‘xmlNodePtr’ make[2]: *** [attribute.o] Error 1 make[2]: Leaving directory `/home/mpilka/cxtest/wine/dlls/msxml3' make[1]: *** [msxml3] Error 2 make[1]: Leaving directory `/home/mpilka/cxtest/wine/dlls' make: *** [dlls] Error 2 Just wanted to let you know that, Martin

May 27, 2007

Ok, NOW is it time to delete wineinstall?

by Scott Ritchie

A couple of years back we had a discussion about this. Does anyone still use Wineinstall? What advantage does it have over ./configure && make && make install ? I'm asking because today I found a user who managed to somehow accidentally compile Wine from source: http://ubuntuforums.org/showthread.php?t=454815 Thanks, Scott Ritchie

May 26, 2007

Re: some doubts about sendind patches - is text/plain way good?

by Kirill K. Smirnov

>You might want to try the following: Select the patch from >http://thread.gmane.org/gmane.comp.emulators.wine.patches/ , >select the link after "Direct link" on the bottom, append "/raw" >without quotation marks after the URL. Now you can save the file >at that URL as is and use it with patch, it will ignore the headers. It works! Cool! (but a little complicated ;-) Thanks a lot for hint! -- Kirill

May 26, 2007