Re: Make test status - latest CVS
Robert Reif wrote: Shachar Shemesh wrote: The problem is that I'm not interested in this test. I just think that, off the shelf, tests should not fail. My opinion is that if this is not a problem with Wine, it shouldn't fail the test. Does this patch help? It should fail the same way windows does now. No, it regresses tests that used to pass: -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html capture.txt Description: application/stream
Commercial support
Hi Jer, When you finally get around to adding a commercial support to Winehq, I would love this list to include: Lingnu Open Source Consulting, web at http://www.lingnu.com. On a different note. There is a page at http://www.winehq.org/site/support, but there does not appear to be any link to it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
short-circuting a dialog box?
I'm trying to figure out if there is a way to short-circuit a dialog box. Basically, I want to traps calls to DialogBoxParam, pump calls into lpDialogFunc for dialog init, and then clicking of the Ok button, and finally trap calls to EndDialog. It seems that this is ... hard. :) There is a lot of resource loading, window initialization code, etc that goes on inside DialogBoxParam, and I'd need to handle all of that, I think. There even appears to be issues with 16 vs 32 bit handler addresses, etc. Looks really ugly. Is there a simpler way to programatically click Ok on a dialog box? (The dialog box coming from code that I don't have source for...) -- Kees Cook@outflux.net
Re: short-circuting a dialog box?
Hi, On Tue, May 03, 2005 at 12:36:09AM -0700, Kees Cook wrote: Is there a simpler way to programatically click Ok on a dialog box? (The dialog box coming from code that I don't have source for...) I'm not sure about that at all, but maybe CBT (Computer-Based Training) hooks are what you want? Andreas Mohr
Re: Commercial support
Shachar Shemesh schrieb am 03.05.2005 um 09:19 Uhr: When you finally get around to adding a commercial support to Winehq, I would love this list to include: Lingnu Open Source Consulting, web at http://www.lingnu.com. Following that proposal, I'd also ask you to add ITOMIG, at http://www.itomig.de Thanks, David
Re: Commercial support
Hi All, I'm not sure, if winehq should be a platform for advertisements of commercial services (except maybe codeweavers), otherwise there will be a very long list there, very soon. And who to include and who not? Are there such plans to include such links on the website, except for community based support? Shachar Shemesh wrote: Hi Jer, When you finally get around to adding a "commercial support" to Winehq, I would love this list to include: "Lingnu Open Source Consulting", web at http://www.lingnu.com. On a different note. There is a page at http://www.winehq.org/site/support, but there does not appear to be any link to it. Shachar -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost at www.mediahost.org Skype: startcom Phone: +1.213.341.0390 Import StartCom Public CA smime.p7s Description: S/MIME Cryptographic Signature
Re: Commercial support
MediaHost (TM) wrote: Hi All, I'm not sure, if winehq should be a platform for advertisements of commercial services (except maybe codeweavers), otherwise there will be a very long list there, very soon. That's good, in principle. The problem brought up during wineconf was that the lack of commercial support is viewed by potential deployers as a minus, making wine a dangerous technology. Saying here is a list of companies willing to take your money and give you support is actually a good thing for Wine. And who to include and who not? Ah, there you have hit a more serious problem. For example, there is no doubt that CodeWeavers has been both a^Hthe major wine driving force, AND a financial sponsor. However, if we don't allow other companies room, we are unfair towards the other companies, towards CodeWeavers (why should they continue to be practically the only ones carrying the load), and towards Wine (and we don't want Wine to become a CodeWeavers subproject, do we?). I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to in the past year. At the moment, I believe only three companies pass that criteria (CodeWeavers, Lingnu, and Dimi's company, whose name he has successfully kept secret, for some reason). Alternatively, we can have several lists. A Gold list, which includes companies that have the means to produce fixes to wine itself if necessary (as judged by the above criteria), and a normal list, which merely includes anyone who declares that they are willing to provide commercial support. I would have suggested a nominal fee (i.e. - a $50 contribution to the wine fund per year, or some such thing) from the last list. On the up side, it allows us to know the company is still active in this field. On the down side, I don't think we have the resources to start tracking who paid and who didn't. I could even suggest a platinum list, which would include any company that employs the equivalent of a full time Wine developer or up. Of course, this currently only includes CodeWeavers. The idea I'm trying to push here is that we can do such a list, so long as we keep clear objective criterias for who gets listed where. Are there such plans to include such links on the website, except for community based support? That's what we talked about over wineconf. It seems that such a list gives credibility to a project, and as such is a wanted thing. A company considering wine deployment is more likely to accept wine if they know they can get support for it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: short-circuting a dialog box?
Kees Cook wrote: I'm trying to figure out if there is a way to short-circuit a dialog box. Basically, I want to traps calls to DialogBoxParam, pump calls into lpDialogFunc for dialog init, and then clicking of the Ok button, and finally trap calls to EndDialog. It seems that this is ... hard. :) There is a lot of resource loading, window initialization code, etc that goes on inside DialogBoxParam, and I'd need to handle all of that, I think. There even appears to be issues with 16 vs 32 bit handler addresses, etc. Looks really ugly. Is there a simpler way to programatically click Ok on a dialog box? (The dialog box coming from code that I don't have source for...) For simple things, merely sending the dialog a WM_COMMAND with the right parameters will do it for you. You can programatically find the dialog using FindWindow. I've done such things before. For simple things, this works very well. As soon as things stop being simple, this gets very hairy very fast. Just hope that your case is a simple one. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
On Dienstag 03 Mai 2005 10:53, Shachar Shemesh wrote: And who to include and who not? [..] I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to in the past year. At the moment, I believe only three companies pass that criteria (CodeWeavers, Lingnu, and Dimi's company, whose name he has successfully kept secret, for some reason). I cannot say I am convinced this is a good rule to follow. First of all, maybe I got things wrong at wineconf, but I remember something like anyone who wants to be listed there should be being the last statement I heard in the lecture room. While it seems to me that the selection by code contribution as proposed would not be quite feasible (what exactly is a non-trivial patch?), I also think that there is a lot more to Wine than just code, starting from documentation, including stuff like donations, helping out on wine-users, or training (commercial or not) are important, too, and won't directly bring any code into the project - which does not make these things less valuable IMHO. So I'd suggest listing anyone who can prove he has contributed to Wine in whatever way - making a donation, having contributed code, whatever - , and let the customers decide whom to select for their particular problem. That said, I definetly think we could allow code contributors a sentence or two of space that describes their area of expertise in Wine (i.e. what part they contributed to), as this is certainly valuable information for customers, and good advertising for those companies. Cheers, David pgpx6dvAEzO3h.pgp Description: PGP signature
Re: Commercial support
David Gmbel wrote: I cannot say I am convinced this is a good rule to follow. First of all, maybe I got things wrong at wineconf, but I remember something like anyone who wants to be listed there should be being the last statement I heard in the lecture room. I'm actually in favor of this. I too think that having as many companies listed would be a good thing. While it seems to me that the selection by code contribution as proposed would not be quite feasible (what exactly is a non-trivial patch?), I also think that there is a lot more to Wine than just code, starting from documentation, including stuff like donations, helping out on wine-users, or training (commercial or not) are important, too, and won't directly bring any code into the project - which does not make these things less valuable IMHO. I agree, but I was really thinking about a different thing. Wine deployment based on existing solutions is different than a deployment that can actually change wine to solve problems. My suggestion was based on the assumption that a client would care to know that. I do think that everyone should be listed, though. So I'd suggest listing anyone who can prove he has contributed to Wine in whatever way - making a donation, having contributed code, whatever - , and let the customers decide whom to select for their particular problem. Agreed. I don't even mind listing EVERYONE, whether or not they contributed anything at all. My token monetary donation idea was based on past experience, where making a list too easy to include you and too easy to stay on it means that it becomes obsolete, and therefor not useful. We tried to run a list of consultants supporting Linux in Israel, and nobody uses it any more, for precisely that reason. Making a token donation once a year eliminates this problem (though it creates other problems, such as actually collecting the money). If, instead of money donation, we merely ask each company to reaffirm it belongs in the list once a year, that would work as well. That said, I definetly think we could allow code contributors a sentence or two of space that describes their area of expertise in Wine (i.e. what part they contributed to), as this is certainly valuable information for customers, and good advertising for those companies. Yep, that is definitely one way to do it. Cheers, David Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
I think support has nothing to do with submitting patches.but with giving support, if we are at it. Wine is going to play a major role by Linux Vendors, where support is the major income; it does it already now. Wine is integrated into migration plans quite tightly for applications with no alternative around. Now, a company giving support for wine should have enough experience and support personnel in both, Linux and Wine in order to qualify, if at all. But than again, the question remains, who to list!? Does submitting a patch qualify for better listing? I don't think there is any connection between them...coding is coding and support issues are something else But I prefer to not have any such list at all, something needing support for wine will find it David Gmbel wrote: On Dienstag 03 Mai 2005 10:53, Shachar Shemesh wrote: And who to include and who not? [..] I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to "in the past year". At the moment, I believe only three companies pass that criteria (CodeWeavers, Lingnu, and Dimi's company, whose name he has successfully kept secret, for some reason). I cannot say I am convinced this is a good rule to follow. First of all, maybe I got things wrong at wineconf, but I remember something like "anyone who wants to be listed there should be" being the last statement I heard in the lecture room. While it seems to me that the selection by code contribution as proposed would not be quite feasible (what exactly is a non-trivial patch?), I also think that there is a lot more to Wine than just code, starting from documentation, including stuff like donations, helping out on wine-users, or training (commercial or not) are important, too, and won't directly bring any code into the project - which does not make these things less valuable IMHO. So I'd suggest listing anyone who can prove he has contributed to Wine in whatever way - making a donation, having contributed code, whatever - , and let the customers decide whom to select for their particular problem. That said, I definetly think we could allow code contributors a sentence or two of space that describes their area of expertise in Wine (i.e. what part they contributed to), as this is certainly valuable information for customers, and good advertising for those companies. Cheers, David -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost at www.mediahost.org Skype: startcom Phone: +1.213.341.0390 Import StartCom Public CA smime.p7s Description: S/MIME Cryptographic Signature
Re: Commercial support
MediaHost (TM) wrote: Wine is going to play a major role by Linux Vendors, where support is the major income; it does it already now. Wine is integrated into migration plans quite tightly for applications with no alternative around. Now, a company giving support for wine should have enough experience and support personnel in both, Linux and Wine in order to qualify, if at all. I guess that would have been true, if Wine did not need so much work still. At the moment, I really don't see how you can give support for Wine without being able to work out areas where Wine is simply not good enough. There is no better way to show you can than to actually have done such a thing in the past, hence the patches suggestion. But than again, the question remains, who to list!? Does submitting a patch qualify for better listing? I don't think there is any connection between them...coding is coding and support issues are something else In my experience, you can solve 0% of enterprise support requests (which is what commercial support about) without doing some level of hacking on Wine. I'd love to hear Jeremy's input on that one, as they have MUCH more experience at it then we. It may be that it's just because we know how to hack wine that we resort to that. Then again, that does mean the customer gets a different level of support from companies that have wine hacking abilities and companies that don't. Either way, telling site visitors who can and who can't seems like useful information to me. But I prefer to not have any such list at all, something needing support for wine will find it But, as discussed at WineConf, not having such a list at all hurts wine, which is clearly not what we are trying to do. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
Shachar Shemesh wrote: MediaHost (TM) wrote: Wine is going to play a major role by Linux Vendors, where support is the major income; it does it already now. Wine is integrated into migration plans quite tightly for applications with no alternative around. Now, a company giving support for wine should have enough experience and support personnel in both, Linux and Wine in order to qualify, if at all. I guess that would have been true, if Wine did not need so much work still. At the moment, I really don't see how you can give support for Wine without being able to work out areas where Wine is simply not good enough. There is no better way to show you can than to actually have done such a thing in the past, hence the patches suggestion. I understand, that wine needs still way to go and development time is not the cheapest thing on earth (A way to get more patches in:-)). Your suggestion concerning patches might be half correct: To hack up wine for certain needs and applications is, in my opinion, not the only qualification needed, it's one of them...Now, if you submitted a patch before, doesn't mean, you can give serious support for wine enabled solutions That's why I said, it's a dangerous thing to post such a listwhy? To list anybody might work like a boomerang, if the listed entity is not capable of doing the job. This might be very counterproductive for wine and in effect make you look like a fool The intention is meant well, but still... And who is going to judge that issue?? Is money, little or much, the green card to winehq's supporting companies list?? Anyway, I see it as a problematic issue at largeand might do more harm than good But than again, the question remains, who to list!? Does submitting a patch qualify for better listing? I don't think there is any connection between them...coding is coding and support issues are something else In my experience, you can solve 0% of enterprise support requests (which is what commercial support about) without doing some level of hacking on Wine. I'd love to hear Jeremy's input on that one, as they have MUCH more experience at it then we. It may be that it's just because we know how to hack wine that we resort to that. Then again, that does mean the customer gets a different level of support from companies that have wine hacking abilities and companies that don't. Either way, telling site visitors who can and who can't seems like useful information to me. But I prefer to not have any such list at all, something needing support for wine will find it But, as discussed at WineConf, not having such a list at all hurts wine, which is clearly not what we are trying to do. Shachar -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost at www.mediahost.org Skype: startcom Phone: +1.213.341.0390 Import StartCom Public CA smime.p7s Description: S/MIME Cryptographic Signature
Re: Commercial support
Hi, On Tue, May 03, 2005 at 01:50:20PM +0300, MediaHost (TM) wrote: I think support has nothing to do with submitting patches.but with giving support, if we are at it. I have to disagree rather strongly. While Wine might get to a state where many people are going to use it and mere enduser support is needed, thus alleviating the need for patching knowledge at support companies, we want companies who CARE about good support and thus KNOW Wine in and out. Or at least they should know as much as being able to contribute some useful patches. IMHO writing some first Wine patches is not a skill issue, it's a time issue. If you're not a programmer, you are still able to spend a lot of time using and getting to know Wine, and once you've done that, writing a couple of (even simple) patches for the Wine environment will be quite easy. Bingo! You've got the entry ticket to publicly listed Wine support... But I prefer to not have any such list at all, something needing support for wine will find it Again rather strong disagreement. As discussed on wineconf2005, wine has a severe market acceptance/perception issue, thus having strong support options seems to be quite important. While a ranked list might not be the best way to represent support options, I think it allows companies such as Codeweavers which are obviously much more involved with Wine to properly represent their Wine knowledge level. Thus I'd be in favour of *something* like such a list. Andreas Mohr
Re: Commercial support
On Tue, 2005-05-03 at 13:33 +0200, Andreas Mohr wrote: But I prefer to not have any such list at all, something needing support for wine will,find it Again rather strong disagreement. As discussed on wineconf2005, wine has a severe market acceptance/perception issue, thus having strong support options seems to be quite important. While a ranked list might not be the best way to represent support options, I think it allows companies such as Codeweavers which are obviously much more involved with Wine to properly represent their Wine knowledge level. I think it is worthwhile to expand on the Samba Team's experience with commercial support lists. The primary experience is that such lists much be maintained, and current. For many years, our list was unmaintained, but over the last year we have had a new website maintainer, and at least companies that don't reply to e-mail are removed. We do not 'vet' our list, and we don't try to rank the providers. This avoids a number of issues (how would you rank them?), and this is a policy I support. We have a broad list of providers in many localities, and this does provide us a place to point users in need of paid help. I don't think it draws away from the 'top tier' providers, who distinguish themselves in the way they always have - by being relevant to their customers, and competing on their own best merits. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: Commercial support
Andrew Bartlett wrote: I think it is worthwhile to expand on the Samba Team's experience with commercial support lists. The primary experience is that such lists much be maintained, and current. For many years, our list was unmaintained, but over the last year we have had a new website maintainer, and at least companies that don't reply to e-mail are removed. Hmm, similar to my refresh once a year idea. Who's in charge of making sure that the companies do still answer email? We do not 'vet' our list, and we don't try to rank the providers. This avoids a number of issues (how would you rank them?), and this is a policy I support. I guess the reason both Andreas and myself think it is a good idea to rank them has to do with the maturity of wine vs. Samba. While it is true that both Andreas and myself believe that our companies should be ranked high (and, at least for me, I also think that the company Andreas work for should be rated high, and even higher), it is also because we believe that this measurement is actually relevant to the service we sell. I am yet to encounter a program that just works on wine. Even if there are, they still enjoy a large amount of customizing and adapting. As such, there should be an advantage to companies that know how to do that. Almost all wine hacking done for clients are generally useful. Lingnu once produced a whole DLL due to a specific client support need (Unicows). This means that the people best situated to know who is who are the people who receive the patches. While I don't think other companies should not be listed at all, but the potential customers should be able to tell them apart. We have a broad list of providers in many localities, and this does provide us a place to point users in need of paid help. I don't think it draws away from the 'top tier' providers, who distinguish themselves in the way they always have - by being relevant to their customers, and competing on their own best merits. I guess neither Andreas nor myself see the way you can provide commercial support for Wine if you can't hack it. I would love to hear from such companies, though, what is their typical support scenario. Maybe it's me who is deluded here. Andrew Bartlett Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
On Tue, May 03, 2005 at 11:33:36AM +0200, David Gümbel wrote: So I'd suggest listing anyone who can prove he has contributed to Wine in whatever way - making a donation, having contributed code, whatever - , and let the customers decide whom to select for their particular problem. Yes, I think being inclusive is better. However, I also think that we need to pick the rules carefully so we don't set up a bad precedent when half the world will be using Wine :). So here is what I propose: 1. The list should be capped to n entries (n=50, 100?) 2. It should be kept up to date, and refreshed at least yearly 3. Any list has an order by definition, this one should be ranked by how much each company benefits the project. Notes: - Rule (1) doesn't mean much now, but it may in the future if we get flooded with requests for listing - Rule (2) seems everyone agrees with. I suggest a token monetary fee that should go towards hosting the WineHQ site. - Rule (3) is the most tricky of all. But please realise that we should be talking from the project's perspective here (we are talking about WineHQ site), not our own commercial perspective. It is fundamental that things are fair to encourage future cooperation, and that is the one and most important thing from the project POV. And yes, code contributions are not the only thing. Regardless, it is not difficult to rank. Here is what I suggest: * company makes a request for linking by submitting a patch to the appropriate page on wine-patches. If they don't know how to do that, they may ask someone for help, but the patch should be posted on the list before it can go in. * if there are any disagreements as to the proposed order, we can ask for a quick vote on the list. Each vote will include the rank the voter gives to the listings. An average of the vote should determine the rank. Please check out Wisdom of Crowds why this works very well. In any event, I don't think there is that much of a problem to come up with a ranking at the time being. -- Dimi.
Commercial Support
The point I wanted to make is, that only submitting patches or saying, "we give wine support", may hurt the wine project more than it helps: 1.) I didn't want to write this, so not to make this thread as an opportunity to make some self advertisement, but I need to explain: Linux Vendors are in fact solution and support providers. We ourselves (StartCom Linux) had the opportunity's to get a certain applications for a certain customers going, by "fixing" a few lines. This does not mean, that this fix was worth for the development efforts of wine. I prefer to let others doing this job better than we do... We do not maintain a wine source tree per se, nor do we checkout from CVS nor do we intend to do it anytime soon. We build and rather fix our current RPM from official releases and provide that to the customer. However, we very carefully monitor the wine devel list and know exactly what's going on (more or less) and are mostly up to date. Based on that informations we publish a new RPM's for our distributions or not. Therefor our efforts are not for the development of wine, but rather for the usability of the end user. 2.) Linux Support and solution issues are not only based on Wine. Wine is just one (important) application contributing to this effort. Now, a person or company listed in such a list, might be able to hack up a few patches, but might not be able to maintain a support level needed. Does that mean, that a patch submitting individual gives better support than a Linux Vendor with all the staff at hand? Having GOLD and SILVER listings makes that issue even more difficult(Shahar, I know you submitted some nice work for unicode support, but does that make you own wine or making you a better wine supporting company than others??) 3.) I think, if you want to advertise your services, setup a appropriate website and make your offerings. Maybe instead of a list there should be a reference to some google searches suggesting a queryI personally think, that the community based wine should stay that way and leave the commercial issues going their own way. Well, I hope I made my point and wont bother anymore concerning this issue. Hope that this input was useful and gave you some food for thoughts -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost at www.mediahost.org Skype: startcom Phone: +1.213.341.0390 Import StartCom Public CA smime.p7s Description: S/MIME Cryptographic Signature
Re: Commercial support
On Tue, 2005-05-03 at 09:02 -0400, Dimitrie O. Paun wrote: On Tue, May 03, 2005 at 11:33:36AM +0200, David Gmbel wrote: So I'd suggest listing anyone who can prove he has contributed to Wine in whatever way - making a donation, having contributed code, whatever - , and let the customers decide whom to select for their particular problem. Yes, I think being inclusive is better. However, I also think that we need to pick the rules carefully so we don't set up a bad precedent when half the world will be using Wine :). So here is what I propose: 1. The list should be capped to n entries (n=50, 100?) 2. It should be kept up to date, and refreshed at least yearly 3. Any list has an order by definition, this one should be ranked by how much each company benefits the project. Notes: - Rule (1) doesn't mean much now, but it may in the future if we get flooded with requests for listing - Rule (2) seems everyone agrees with. I suggest a token monetary fee that should go towards hosting the WineHQ site. I would advise strongly against setting up an implied contract for advertising, by accepting money. I strongly suggest a 'these people claim they can help with Wine' list, unsorted (except by locality or name), and certainly without a 'vote' system. Folks who are incompetent will soon show this to their clients in their own time, why should Wine mailing list be making a statements about companies to which most will not have had contact as a customer. Samba has a large support directory, and as has been commented it is probably also easier to support. I suggest dealing with the 'thundering hoards' question if you really get them. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: Commercial support
Hi, On Tue, May 03, 2005 at 03:38:51PM +0300, Shachar Shemesh wrote: I guess the reason both Andreas and myself think it is a good idea to rank them has to do with the maturity of wine vs. Samba. While it is true that both Andreas and myself believe that our companies should be ranked high (and, at least for me, I also think that the company Andreas work for should be rated high, and even higher), it is also because we believe that this measurement is actually relevant to the service we sell. Indeed, the projects are quite different at the moment, thus I think that Wine support will inevitably require development knowledge for now. This will probably change, but most likely not within 2 or even 3 years. But while I certainly rate my company rather high, this is a personal rating only and doesn't have anything to do with Wine, since we're not in the Wine support business AT ALL ;-) (not even much in the Wine development business - that's just some side effects) Andreas Mohr
Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine. Wine has real trouble with refreshing drawing surface windows in Paint Shop Pro 7: - the background in a new image window isn't cleared - tools that display tooltips (such as the colour selector control) leave tooltip debris all over the drawing surface when they're moved around. - drawing surface isn't refreshed if partially / totally obscured by other windows and then made visible again. Normal windows, dialogs etc. are working fine (and tooltips work fine too above normal controls) - it would seem that the drawing surfaces in PSP7 are handled differently (presumably for speed reasons) and wine is having some serious problems handling them. Any ideas for a workaround / patch, or is this bug known about and in the pipeline to be sorted out? I've exhausted various options in the Wine config file to do with display output; the problem seems to be in core code somewhere. I get the following error message at startup as follows: fixme:ole:CoRegisterMessageFilter stub followed by several: err:region:CombineRgn Invalid rgn=(nil) ... the latter used to happen an awful lot in earlier wine builds whilst the app was being used, but note that it's *not* happening with the 20050310 build whilst I try and use the app; only at startup time. (In other words, it's quite possibly not related to the redraw issues at all) Any ideas? PSP7 is so almost there that it'd be a shame if it wasn't 100%... Happy to provide further details if someone gives me instructions as to what to look at! cheers Jules
Re: Commercial support
On 5/3/05, Shachar Shemesh [EMAIL PROTECTED] wrote: I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to in the past year. At the moment, I At some point over the next few weeks I'll throw something together (feel free to beat me to it.) I don't think we need any criteria about contribuing to Wine or a platinum level. If you're crazy enough^H^H^H^H^H able to do commercial support then we should advertise it. There's plenty of companies who can do support without the knowledge to contribute. In fact, you could think of them offering support as their way of contributing. Support companies can also 'escalate' to someone else if coding is involved. Also, I'll bet we won't have to worry about the list being too big any time in the near future. Let's not worry about that now. A lot of names would be good. -Brian
Re: Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
On Tue, May 03, 2005 at 02:33:56PM +, Jules Richardson wrote: I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine. Please use 20050419 at least, a huge amount of changes went into the respective code. Ciao, Marcus
Re: Commercial support
On Dienstag 03 Mai 2005 15:31, Andrew Bartlett wrote: Folks who are incompetent will soon show this to their clients in their own time, why should Wine mailing list be making a statements about companies to which most will not have had contact as a customer. ACK. Samba has a large support directory, and as has been commented it is probably also easier to support. I suggest dealing with the 'thundering hoards' question if you really get them. Before we start debating details that are maybe not even issues, why don't we run a Call for Listings here: Any company that would like to be listed should say so aloud here on wine-devel during, say, a week's time. Then we'll see if we are actually having trouble enforcing some list order or I'm still interested-mechanism. As things stand, the folks that have spoken up and demanded to be listed know each other personally, and at least while we're just talking about Condeweavers, LinGNU, Dimitrie and ITOMIG, I don't have a problem at all to be listed last (in fact I think that would be appropriate). Cheers, David pgpUfI5dYhcoJ.pgp Description: PGP signature
Re: Commercial support
On Dienstag 03 Mai 2005 16:43, Brian Vincent wrote: On 5/3/05, Shachar Shemesh [EMAIL PROTECTED] wrote: I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to in the past year. At the moment, I At some point over the next few weeks I'll throw something together (feel free to beat me to it.) Good! I don't think we need any criteria about contribuing to Wine or a platinum level. If you're crazy enough^H^H^H^H^H able to do commercial support then we should advertise it. There's plenty of companies who can do support without the knowledge to contribute. In fact, you could think of them offering support as their way of contributing. Support companies can also 'escalate' to someone else if coding is involved. Exactly. Also, I'll bet we won't have to worry about the list being too big any time in the near future. Let's not worry about that now. A lot of names would be good. I absolutely agree. Cheers, David pgpHaV9E3PDj2.pgp Description: PGP signature
Re: short-circuting a dialog box?
On Tue, May 03, 2005 at 11:56:35AM +0300, Shachar Shemesh wrote: For simple things, merely sending the dialog a WM_COMMAND with the right parameters will do it for you. You can programatically find the dialog using FindWindow. Ah-ha, yes. I ended up using EnumWindows (filtering out the HWND from GetTopWindow). Thanks! WM_COMMAND, IDOK, 0 did the trick. Now, a final note, is there any way to stop a dialog from displaying itself? (i.e., let dialogs become active, but not draw themselves?) The ttydrv doesn't like trying to open the dialog: fixme:ttydrv:TTYDRV_GetBitmapBits (0x7d, 0x76d3501c, 128): stub -- Kees Cook@outflux.net
Re: Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
On Tue, 2005-05-03 at 16:54 +0200, Marcus Meissner wrote: On Tue, May 03, 2005 at 02:33:56PM +, Jules Richardson wrote: I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine. Please use 20050419 at least, a huge amount of changes went into the respective code. Just done so (using 20050419 built from source) - unfortunately no change; same behaviour (including the null pointer CombineRgn errors, which may or may not be related) If there's anything I can do to get some meaningful debug out of things to help diagnose the actual root problem, let me know - I'd assume that whatever trick PSP uses to do efficient drawing is also used in other Windows apps, so no doubt a fix (or at least understanding of the basic problem) would prove useful elsewhere too... ps. your own message arrived in my inbox before my original email was even echoed back - now that's efficiency! :-) cheers Jules
Re: Benchmarking Wine againt XP Part 2
On 5/2/05, Jakob Eriksson [EMAIL PROTECTED] wrote: Dimitrie O. Paun wrote: If you can do it, it may prove useful. povray is cpubound, so should not be a large difference. //Jakob Well only one way to find out isn't it? Ive got Pov-Ray installed and running in current wine, ill install it under XP later today or tomorrow and see if there is any difference. Cheers, Tom
Re: short-circuting a dialog box?
YOu could trap it#s onshow event but be careful since most dlgs are created as modal , you could end up hanging your process. On Tue, 03 May 2005 17:23:40 +0200, Kees Cook [EMAIL PROTECTED] wrote: On Tue, May 03, 2005 at 11:56:35AM +0300, Shachar Shemesh wrote: For simple things, merely sending the dialog a WM_COMMAND with the right parameters will do it for you. You can programatically find the dialog using FindWindow. Ah-ha, yes. I ended up using EnumWindows (filtering out the HWND from GetTopWindow). Thanks! WM_COMMAND, IDOK, 0 did the trick. Now, a final note, is there any way to stop a dialog from displaying itself? (i.e., let dialogs become active, but not draw themselves?) The ttydrv doesn't like trying to open the dialog: fixme:ttydrv:TTYDRV_GetBitmapBits (0x7d, 0x76d3501c, 128): stub
Re: Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
I'll second that. I have a small win32 app that I wrote years ago in Delphi 2. It had some fancy redrawing to give rounded degraded borders to windows. This completely locks up on recent wine versions. On Tue, 03 May 2005 18:16:26 +0200, Jules Richardson [EMAIL PROTECTED] wrote: On Tue, 2005-05-03 at 16:54 +0200, Marcus Meissner wrote: On Tue, May 03, 2005 at 02:33:56PM +, Jules Richardson wrote: I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine. Please use 20050419 at least, a huge amount of changes went into the respective code. Just done so (using 20050419 built from source) - unfortunately no change; same behaviour (including the null pointer CombineRgn errors, which may or may not be related) If there's anything I can do to get some meaningful debug out of things to help diagnose the actual root problem, let me know - I'd assume that whatever trick PSP uses to do efficient drawing is also used in other Windows apps, so no doubt a fix (or at least understanding of the basic problem) would prove useful elsewhere too... ps. your own message arrived in my inbox before my original email was even echoed back - now that's efficiency! :-) cheers Jules
Re: short-circuting a dialog box?
On Tue, May 03, 2005 at 07:38:26PM +0200, [EMAIL PROTECTED] wrote: YOu could trap it#s onshow event but be careful since most dlgs are created as modal , you could end up hanging your process. How would I go about capturing that? (Or, how would I hook the event handler?) -- Kees Cook@outflux.net
wineconf videos
We need some help with editing, questions can be heard in the background, but I think that if someone could turn the volume of the comments up it would be almost as good as if the people speaking had a microphone. Also we need someone to split the sound from the video so we can have audio files for those without fast connections. Ivan.
Re: Commercial support
Oh, fine, start a flame war while I'm off travelling around Germany. grin In my not very humble opinion, I think that any commercial support section of the WineHQ web site should be open to anyone that requests to be listed there, and that it should be in alphabetical order. However, I think the list should be fairly simple with a link to full details. I do think that some reasonable pruning is fair; someone that is obviously trolling without any Wine credentials at all, or someone that falls off the map, for example, should get pruned. But it should be awfully hard to get kicked out, imo. Now you can take my $0.02 and add EUR $1.48, and you have a cup of coffee (and you really will, because you don't have to factor in tax, and that's so nice) :-/ Cheers, Jeremy
wineconf presentations
Please send all presentations/PDFs/whatever to [EMAIL PROTECTED] and I'll upload them to the server that will be providing the wineconf videos. Ivan.
Re: wineconf videos
To split video and sound, I use VirtualDubMod with wine. It works very well. It is quite easy to do but if you want me to do it, there is no problem. Maxime On Tue, 2005-05-03 at 22:00 +0200, Ivan Leo Puoti wrote: We need some help with editing, questions can be heard in the background, but I think that if someone could turn the volume of the comments up it would be almost as good as if the people speaking had a microphone. Also we need someone to split the sound from the video so we can have audio files for those without fast connections. Ivan.
Re: short-circuting a dialog box?
On Tue, May 03, 2005 at 08:29:10PM +0200, [EMAIL PROTECTED] wrote: It appears you really have very little knowlege of win32 API programming, I'm not sure this is the place for you to start. That's true. I should probably take this off channel. Is this a wine problem ? If so in what way. It's not a Wine problem exactly. More of a make it work with Linux via Wine issue. I've been developing against the Wine libraries (I don't use Windows natively). The tool I've been writing loads and runs DirectShow DLLs via the IFileSourceFilter APIs: http://outflux.net/software/pkgs/srcfilter/ In the process, I've been writing patches to wine to fully implement some of the calls made by the DLLs I've tried. In an effort to make srcfilter as easy to use as possible, I've been trying to make it as non-interactive as possible, hence my desire to make the dialogs never display, not require X11, etc. I need the dialog to think it's running, though. -- Kees Cook@outflux.net
Re: Commercial support
On Tue, 03 May 2005 22:22:34 +0200, Jeremy White [EMAIL PROTECTED] wrote: Now you can take my $0.02 and add EUR $1.48, and you have a cup of coffee (and you really will, because you don't have to factor in tax, and that's so nice) :-/ LOL ! bEUR $1.48 /b eh? I have long suspected the existance of eurodolloars , now the cats out of the bag. We'ed probably be as well adopting the US constitution while we're about it. It makes more sense that the wooly non-constitution they are trying to ram down our throats at the moment. Still I am sure we can rely on the French to reject it . Votez NON !!
Re: crypt32: CryptProtectData/CryptUnprotectData
On Tue, May 03, 2005 at 01:58:18PM -0700, Juan Lang wrote: Someone previously posted pretty good information about the format of CryptProtectData on MSDN. I think it should be possible to implement a close facsimile, except that the user's credentials (password) would be missing in Wine since there isn't any at the moment. If you have time to do this, it would be ideal. Failing that, doing any stateless transformation (e.g. no change at all, or xor-ing with some magic value) would be preferrable to storing this data in the registry, if I understood Alexandre's comments correctly. Okay. The article (while very good: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/windataprotection-dpapi.asp) doesn't fully address the opaque data blob. I have taken it apart and found some common lengths, etc, so I think I can produce a reasonable guess at it, so that the future implementations will have very little to change. The clues in the section Protected data blob is what I'm using for the guesses at the data blob format sections. I should have a new patch ready soon. Luckily all the tests and documentation will remain valid. :) We're trying to avoid proliferation of OpenSSL in Wine. Relying on CryptoAPI is a safer bet. Is there somewhere I can find details on what's been completed in the CryptoAPI? The http://winehq.com/site/winapi_stats page say it's at 21%. Thanks for all the clarification. I appreciate it! -- Kees Cook@outflux.net
wineconf video downloads
Videos will appear here http://wineconf.geldorp.nl/ enjoy. Ivan.
Re: crypt32: CryptProtectData/CryptUnprotectData
On 5/3/05, Kees Cook [EMAIL PROTECTED] wrote: Is there somewhere I can find details on what's been completed in the CryptoAPI? The http://winehq.com/site/winapi_stats page say it's at 21%. The easiest way to determine how much of CryptoAPI is implemented is to dig into the code and see what has been implemented. You can also look at the dll spec file to see which functions are 'implemented' and which are true stubs, where 'implemented' means either truly implemented or stubbed out (FIXME(stub\n) etc). Browsing the source will also help to familiarize you with CryptoAPI. -- James Hawkins
