Hm. Felt I needed to offer a counterpoint to Vitaliy's rather enthusiastic response.
I support winetools, though I don't use it myself. Not only as a matter of principle (this is open source we're talking about, and one of the beauties is we don't get to constrain how it's used.) Also because it's in line with the aims of the Wine project: run Windows apps. Wine is nice in that it doesn't require you to have any MS license to run Windows apps, but it can use MS software if you have a licensed copy. So winetools offers folks with MS licenses a relatively easy way to get apps to run.
Still, while that's nice for the users, it's not so nice for us Wine developers, because it's hard to get widespread testing of things we're improving if they're not being widely used.
So, as Vitaliy suggested, it would be nice for us if you guys, who know what problems you encounter running with builtin DLLs, could file bug reports in bugzilla for us. That way at least we have a chance to say, hey, that problem's now fixed, consider using builtin OLE (or whatever) in the next release of winetools.
Now for specifics. For instance, you use native advpack in all cases, but that's seen some more work recently. What bugs do you encounter if you use builtin instead? Same with ole32. Ideally, each of the apps that has a native override should have a bug report associated with it, what goes wrong if you use the builtin version instead.
Also, the default override, "*"="native,builtin" seems wrong. If we don't have a DLL at all, we use a native version of course. I don't think it should be the policy to assume the Wine version isn't up to snuff by default. This could even cause problems, e.g. I don't believe any native version of netapi32.dll will work on Wine, yet you don't specify to use the builtin version.
Also, you direct users to http://winehq.org/site/forums. That's fine since this is community support anyway, and it is often the case that winetools knowledgeable people are around (like you guys.) But it would be nicer if you could be clearer about it. Like, that we developers had nothing to do with it, and may be unfriendly to it if we're in a bad mood, or it's a Tuesday :)
It'd also be nice (for us, even though no one actually reads anything these days) if you could be clearer about what it does. That it installs MS components, that it uses these instead of the builtin versions sometimes, that you can change how it does this using winecfg, etc. That'd make it easier for us to help folks that have only used winetools that want support, because often the first question we ask is, what version of wine, and what DLLs are you using?
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I'm not sure we need a counterpoint to Vitaliy. The fact that it took over a month to hear back from the winetools guys seems like reason enough to pull it from the downloads page. Winetools might be a useful tool but we can't have wine's users depending on them if we developers can't get ahold of them and figure out when some of these issues mighe be addressed. Even if these issues are addressed we really should consider the side effects of relying on installing ms components to get applications to run.
Chris
On 1/24/06, Juan Lang juan_lang@yahoo.com wrote:
Hm. Felt I needed to offer a counterpoint to Vitaliy's rather enthusiastic response.
I support winetools, though I don't use it myself. Not only as a matter of principle (this is open source we're talking about, and one of the beauties is we don't get to constrain how it's used.) Also because it's in line with the aims of the Wine project: run Windows apps. Wine is nice in that it doesn't require you to have any MS license to run Windows apps, but it can use MS software if you have a licensed copy. So winetools offers folks with MS licenses a relatively easy way to get apps to run.
Am Tue, Jan 24, 2006 at 09:16:21AM -0800 schrieb Juan Lang:
I support winetools, though I don't use it myself. Not only as a matter of principle (this is open source we're talking about, and one of the beauties is we don't get to constrain how it's used.) Also because it's in line with the aims of the Wine project: run Windows apps. Wine is nice in that it doesn't require you to have any MS license to run Windows apps, but it can use MS software if you have a licensed copy. So winetools offers folks with MS licenses a relatively easy way to get apps to run.
That's the point.
Still, while that's nice for the users, it's not so nice for us Wine developers, because it's hard to get widespread testing of things we're improving if they're not being widely used.
So, as Vitaliy suggested, it would be nice for us if you guys, who know what problems you encounter running with builtin DLLs, could file bug reports in bugzilla for us. That way at least we have a chance to say, hey, that problem's now fixed, consider using builtin OLE (or whatever) in the next release of winetools.
While migrating we will do so.
Now for specifics. For instance, you use native advpack in all cases, but that's seen some more work recently. What bugs do you encounter if you use builtin instead? Same with ole32. Ideally, each of the apps that has a native override should have a bug report associated with it, what goes wrong if you use the builtin version instead.
Also, the default override, "*"="native,builtin" seems wrong. If we don't have a DLL at all, we use a native version of course. I don't think it should be the policy to assume the Wine version isn't up to snuff by default. This could even cause problems, e.g. I don't believe any native version of netapi32.dll will work on Wine, yet you don't specify to use the builtin version.
We will investigate that during the next tests.
Also, you direct users to http://winehq.org/site/forums. That's fine since this is community support anyway, and it is often the case that winetools knowledgeable people are around (like you guys.) But it would be nicer if you could be clearer about it. Like, that we developers had nothing to do with it, and may be unfriendly to it if we're in a bad mood, or it's a Tuesday :)
I made a suggestion for a prominent dialog box at startup in my last mail.
It'd also be nice (for us, even though no one actually reads anything these days) if you could be clearer about what it does. That it installs MS components, that it uses these instead of the builtin versions sometimes, that you can change how it does this using winecfg, etc.
I am not sure how we can provide that... this is more a question of a manual which will never be read by these people. Hmm, something like a status report together with some prominent debug channels could be a solution. But I don't think that leads to something as long as we use native libs.
Regards Joachim von Thadden
-
Chris Morgan -
Joachim von Thadden -
Juan Lang