[Fwd: WineTools is in need of some major house cleaning!]

Juan Lang juan_lang at yahoo.com
Tue Jan 24 11:16:21 CST 2006

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?


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the wine-devel mailing list