On 2009-01-19 (Monday) 04:05:47 nonzer0 wrote:
> Thanks L. Rahyen and vitamin, I figured it had its own directx, but wasn't
> sure what to do.
>
> OK. I updated my wine to version 1.1.13, and removed the .wine directory.
> I also managed to get COD4 installed, but receive error r6002.I have a few
> questions now.
>
> 1. What is the wine prefix, and how would it be damaged? It came
> preinstalled in ubuntu.
If you not careful enough or install conflicting application in the Wine
prefix - it will be damaged. Damaged Wine prefix means that behavior of
Windows program in such prefix isn't the same as in clean Wine prefix. This
can be said about Windows too, it is very easy to damage it when you either
install a lot of programs or doing something very special.
> 2. After reading through some forums, it says that I am likely missing
> DLLs and to try using winetricks. But I also remember reading that you
> shouldn't use winetricks because it modifies the default files, making it
> harder to diagnose a problem with wine.
Actually it is a tool to help to diagnose your problem, not to make it harder
but to make it simpler. For example, I have a program which work better or
perfectly if I run "winetricks gdiplus". That means, I found a bug in builtin
gdiplus. And this is exactly what should be reported: builtin gdiplus in the
program shows a bug (and use of winetricks gdiplus proves it if native
gdiplus helps the program in question to work better). Then add detailed
description of the problem, and perhaps terminal output - with clean Wine
prefix (all DLLs are set to builtit).
> Also, if you use winetricks, not
> to submit a bug report. Should I use winetricks, or is there a better way
> to go about adding missing DLLs?
I hope above helped you understand how to use winetricks if you want to
report a bug. You may use winetricks to see how particular native DLL(s) may
affect your problem. If some native DLL(s) don't change the buggy behavior
or make it worse - *probably* bug is in other DLL(s). Otherwise, if you are
lucky, you may find out that installing particular minimum set of native DLLs
helps you partially or fully to solve your problem/bug - and this is exactly
what should be added to your bug report: the minimum set of native DLLs
to "fix" the bug. In this way developers will know right away what component
of Wine is buggy.
However, when reporting bug report you should post terminal output and bugs
you found only with clean Wine prefix; minimum set of native DLLs to "fix"
or "bypass" the bug is nothing more than a bit of additional information in
any bug report which may help developers to fix your problem faster. Use of
native DLLs isn't real fix, and any bugs reproducible only with native DLLs
should never be reported except few special cases (please note then everywhere
in this message by "native DLL" I mean here *only* native DLLs with
corresponding builtin replacements in Wine).
> So, should I avoid winetricks in order to help the maintainers of the
> software or is it ok to use it and still report a bug?
I recommend you to use multiple Wine prefixes. ~/.wine is default Wine
prefix. To create some other Wine prefix, do this:
export WINEPREFIX=~/.name-of-your-wineprefix
Optionally you may run "wineboot" to actually create Wine prefix if you want
to copy native DLLs to it by hand (without winetricks). If you are using
winetricks or just want to run setup for your Windows program Wine prefix
defined in WINEPREFIX environment variable will be created automatically for
you.
A program installed and tested in just created Wineprefix is a program tested
in clean Wine prefix. Any bug in Wine you find when doing such test is a bug
to report.
Here is an example. Let's say we have a program X. First, you setup clean
Wine prefix to test it:
export WINEPREFIX=~/.wine-clean
rm -rf $WINEPREFIX
"rm -rf" make sure that ~/.wine-clean is empty. Then you run setup for
program X:
wine programXsetup.exe
Let's say installation went OK. Now you are trying to run program X:
cd ~/.wine-clean/drive_c/Program\ Files/programX/; wine programX.exe
For example, you see that everything works OK but there is some minor UI
bug. You can write your bug report now but don't yet submit it.
Now you try winetricks comctl32 and after this you see the bug "disappeared".
So you add this information to your bug report that problem can be "solved"
by winetricks comctl32 to prove that comctl32 is the component in Wine which
makes UI in program X look wrong.
Of course in most real world cases everything may be much more complex, and
you may need to test the program multiple times. For example, it is good idea
to backup ~/.wine-clean Wine prefix after you installed program and found a
bug in Wine but before running winetricks or copying native DLLs by hand. For
example:
cp -a ~/.wine-clean{,-backup}
By returning to a backup clean copy of your ~/.wine-clean after each
unsuccessful attempt of using native DLLs (either no change in behavior or
worse behavior of the program) you save the time needed to find minimum set
of native DLLs or to find out that use of native DLLs doesn't help at all in
some particular case.
And as I said before remember to describe problems in your bug reports *only*
found when using clean Wine prefix. If some native DLL(s) helped you to "fix"
the problem this may be useful bit of information in the bug report but
that's all: use of native DLLs isn't a real fix.
