Here is my setup:
Wine version 1.0.1
Ubuntu 8.10 Intrepid Ibex x64
I have tried installing Call of Duty 4, since my friend has a copy and the app db says it works. However, during the installation, direct x fails to install. I downloaded direct x 9c and tried to install it, but it fails immediately.
I have tried different programs over a period of about 9 months, and nothing will work. Is there a trick to getting applications and games to work in Wine? It seems like I would need to add windows files (dll's and such) into wine to give it better support for all these applications, but I really don't know. I have gone through this site and googled around many times, and can't seem to figure out why I have these problems.
For example, when trying to install direct x, the following error is displayed.
"An internal system error occurred. Please refer to DXError.log and DirectX.log in your windows folder to determine the problem."
Edit: I thought about using winetricks, but the FAQ doesn't recommend it.
Any help is greatly appreciated.
I can't install anything in WINE. What am I doing wrong?
Re: I can't install anything in WINE. What am I doing wrong
Don't do that. Wine has it's own DX implementation. Native DX won't work with exception of few dlls that are missing in Wine.nonzer0 wrote:I downloaded direct x 9c and tried to install it, but it fails immediately.
I can't install anything in WINE. What am I doing wrong?
On 2009-01-17 (Saturday) 21:06:20 nonzer0 wrote:
rm -rf ~/.wine
Then try to install some application(s). You may want to read in
http://appdb.winehq.org about application you want to try to install. For
first try I recommend to install something that works according to appdb.
This way you will make sure that your Wine installation is working as you
expect. Then you can install whatever you wish.
Also I recommend you to install Wine 1.1.13. Your Wine version (1.0.1) is too
old. Many bugs was fixed and improvements was made since your version.
If you ever need to install any native dll(s), please use winetricks. This is
especially true if you are novice.
However, remember that any case where you need native dll is a bug in Wine
and should be reported to htpp://bugs.winehq.org so we can fix it.
Remember that installing native dll(s) may break your Wine prefix. For
example, if you install dcom98 many application will fail to work correctly.
To restore, just remove corresponding dll entries in winecfg and if nothing
else helping - rm -rf ~/.wine.
You may want to read in the documentation about using multiple Wine prefixes
because installing Windows applications in different Wine prefixes is good
practice - it gives you much more stable configuration because Windows
application do not conflict with each other when they are installed in
separate Wine prefixes.
Your Wine prefix is probably damaged. First, run this:Here is my setup:
Wine version 1.0.1
Ubuntu 8.10 Intrepid Ibex x64
I have tried installing Call of Duty 4, since my friend has a copy and the
app db says it works. However, during the installation, direct x fails to
install. I downloaded direct x 9c and tried to install it, but it fails
immediately. I have tried different programs over a period of about 9
months, and nothing will work. Is there a trick to getting applications
and games to work in Wine?
rm -rf ~/.wine
Then try to install some application(s). You may want to read in
http://appdb.winehq.org about application you want to try to install. For
first try I recommend to install something that works according to appdb.
This way you will make sure that your Wine installation is working as you
expect. Then you can install whatever you wish.
Also I recommend you to install Wine 1.1.13. Your Wine version (1.0.1) is too
old. Many bugs was fixed and improvements was made since your version.
If you ever need to install any native dll(s), please use winetricks. This is
especially true if you are novice.
However, remember that any case where you need native dll is a bug in Wine
and should be reported to htpp://bugs.winehq.org so we can fix it.
Remember that installing native dll(s) may break your Wine prefix. For
example, if you install dcom98 many application will fail to work correctly.
To restore, just remove corresponding dll entries in winecfg and if nothing
else helping - rm -rf ~/.wine.
You may want to read in the documentation about using multiple Wine prefixes
because installing Windows applications in different Wine prefixes is good
practice - it gives you much more stable configuration because Windows
application do not conflict with each other when they are installed in
separate Wine prefixes.
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. How do I set up multiple prefixes? I will read around, but if someone could break it down into an easy to understand form i would love that.
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. 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?
Between work and school, I don't really have any time to play games (I've been playing Treasure of the Rudras on the Wii Virtual Console for 6 months now and haven't beat it) I am just doing this to gain a little bit more knowledge on how to use linux. I am mainly doing this so friends of mine will be willing to try linux.
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?
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. How do I set up multiple prefixes? I will read around, but if someone could break it down into an easy to understand form i would love that.
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. 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?
Between work and school, I don't really have any time to play games (I've been playing Treasure of the Rudras on the Wii Virtual Console for 6 months now and haven't beat it) I am just doing this to gain a little bit more knowledge on how to use linux. I am mainly doing this so friends of mine will be willing to try linux.
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 can't install anything in WINE. What am I doing wrong?
On 2009-01-19 (Monday) 04:05:47 nonzer0 wrote:
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.
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).
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).
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.
If you not careful enough or install conflicting application in the WineThanks 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.
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.
Actually it is a tool to help to diagnose your problem, not to make it harder2. 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.
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).
I hope above helped you understand how to use winetricks if you want toAlso, 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?
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).
I recommend you to use multiple Wine prefixes. ~/.wine is default WineSo, 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?
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.
