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

[Joachim von Thadden]

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!!!"