[Wine] I can't install anything in WINE. What am I doing wrong?

[L. Rahyen]

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.