[Fwd: WineTools is in need of some major house cleaning!]
Joachim von Thadden
thadden at web.de
Tue Jan 24 19:43:44 CST 2006
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
--
"Never touch a running system! Never run a touching system?
Never run a touchy system!!!"
More information about the wine-devel
mailing list