Opinions on priority for an enhancement that Dan suggested some time ago?

Tom Spear speeddymon at gmail.com
Fri Sep 3 23:24:39 CDT 2010

Hi all, so it has been a long time since I have posted here. Much has
changed; I now have 3 little ones. :-)

Anyways, right to the point: I stumbled on an old bug of mine this evening
while doing some long overdue mailbox maintenance. Bug 657:

Dan made a very good point back in 2007 that I believe now is the right time
to possibly look at beginning an implementation of: [1]

To summarize: Similar to the way that we now have a popup about wine-gecko
missing, I believe it would be prudent to have some warning appear when
certain native dll's are missing which required by the app being run, and
which we do not implement builtins for. Similarly, I feel that it would be
prudent for warnings to appear if certain linux shared objects are missing.

More to the point is that there are quite a number of DLL's which won't be
implemented soon, if ever, but yet we support running wine from the GUI both
through shortcuts, and through binfmt_misc, thereby completely bypassing any
hope of a user ever seeing some pretty critical errors that may occur. These
errors could, if popped up on their screen, prevent a bunch of duplicates
from appearing in Bugzilla, because the user can google for the error and be
directed directly to a bug which someone else made, as opposed to not seeing
anything and having no idea what to try googling for other than "app x does
this +wine"

As an example on the shared object side, on FC13 x86_64, using the rpm from
the yum repo that RH provides, I can install wine, but since there is no RPM
dependency currently for OpenAL (i686), I get "no such file/directory"
warnings about the OpenAL shared objects when running certain programs
(specifically, World of Warcraft and Starcraft II). Now granted the fact
that OpenAL is not installed is, debatibly something to take up with the
wine packager for RedHat and derivatives; I wanted to point out that with
the way wine is at present, if I didn't run wine from a console, I would
never have known that, and probably would still not have working sound,
because there is nothing that says "Hey! You're missing OpenAL!"

I'd like to hear opinions from others about what it might take, time-wise,
if someone were to start now, to have something like this implemented. And
also what kind of a priority this type of thing should have. Sure it is an
enhancement, and so is naturally lower priority than, say a segfault in
ntdll, but (imho) it's a pretty critical enhancement that is (again, imho)
long overdue.

Thoughts? Questions?

[1] http://bugs.winehq.org/show_bug.cgi?id=657#c37

Also see comments of his below #37.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100903/8139a6e5/attachment.htm>

More information about the wine-devel mailing list