Clean enviroments in Wine

[bigseb]

I read somewhere that in order for a program to work properly in Wine it should be installed in a clean enviroment, something along the lines of one software conflicting with anothers drivers/runtime/apps/etc. Is this true? Does this mean that I can only have one program installed with Wine at a time?

Can one not create several 'fresh enviroments'?

[Martin Gregorie]

On Fri, 2011-12-02 at 11:16 -0600, bigseb wrote:

I read somewhere that in order for a program to work properly in Wine it should be installed in a clean enviroment, something along the lines of one software conflicting with anothers drivers/runtime/apps/etc. Is this true? Does this mean that I can only have one program installed with Wine at a time?

Can one not create several 'fresh enviroments'?

Yes, you can create as many environments, known as 'prefixes' as you
want:

cd $HOME
mkdir .wine_myapp
export WINEPREFIX="$HOME/.wine_myapp"
# now install and run your application

After that you might find it worthwhile to use a wrapper script to run
the app. Here's a howto:
http://www.libelle-systems.com/free/win ... cript.html


Martin

[bigseb]

On Fri, 2011-12-02 at 11:16 -0600, bigseb wrote:

I read somewhere that in order for a program to work properly in Wine it should be installed in a clean enviroment, something along the lines of one software conflicting with anothers drivers/runtime/apps/etc. Is this true? Does this mean that I can only have one program installed with Wine at a time?

Can one not create several 'fresh enviroments'?

Yes, you can create as many environments, known as 'prefixes' as you
want:

cd $HOME
mkdir .wine_myapp
export WINEPREFIX="$HOME/.wine_myapp"
# now install and run your application

After that you might find it worthwhile to use a wrapper script to run
the app. Here's a howto:
http://www.libelle-systems.com/free/win ... cript.html


Martin

Thanks, Martin. I am not very terminal fluent so:
cd $HOME ----> change to home directory
mkdir .wine_myapp -----> create a dir in home folder with apps name
export WINEPREFIX="$HOME/.wine_myapp" ----> don't know what this does

I'll check out the link, in the meantime what does a wrapper script do?

[Martin Gregorie]

On Fri, 2011-12-02 at 13:25 -0600, bigseb wrote:

Thanks, Martin. I am not very terminal fluent so:
cd $HOME ----> change to home directory

Correct. Running "cd" with no arguments does the same but I showed the
other form because what it does is more obvious.

mkdir .wine_myapp -----> create a dir in home folder with apps name

Correct.

export WINEPREFIX="$HOME/.wine_myapp" ----> don't know what this does

This redefines the $WINEPREFIX shell variable, which wine uses to find
the prefix its going the use. $WINEPREFIX defaults to "$HOME/.wine"

I'll check out the link, in the meantime what does a wrapper script do?

Its a short-hand way of running an application in a non-default prefix.
You can simply type the script name at the command prompt or create a
launcher that uses it: this lets you click an icon to run it.

The site that link references is mine: I use it for computer-related
stuff.


Martin

[bigseb]

On Fri, 2011-12-02 at 13:25 -0600, bigseb wrote:

Thanks, Martin. I am not very terminal fluent so:
cd $HOME ----> change to home directory

Correct. Running "cd" with no arguments does the same but I showed the
other form because what it does is more obvious.

mkdir .wine_myapp -----> create a dir in home folder with apps name

Correct.

export WINEPREFIX="$HOME/.wine_myapp" ----> don't know what this does

This redefines the $WINEPREFIX shell variable, which wine uses to find
the prefix its going the use. $WINEPREFIX defaults to "$HOME/.wine"

I'll check out the link, in the meantime what does a wrapper script do?

Its a short-hand way of running an application in a non-default prefix.
You can simply type the script name at the command prompt or create a
launcher that uses it: this lets you click an icon to run it.

The site that link references is mine: I use it for computer-related
stuff.


Martin

Top stuff Martin. Much appreciated. I'll report on how it goes...

[bigseb]

If I need to add, say, directx or j# redistributibles to a specific enviroment (prefix??) how do I do that. winetricks always wants to add to .wine instead of .wine_myapp...

Also how do I install an app to a specific enviroment without using PlayOn Linux?

[fcmartins]

If I need to add, say, directx or j# redistributibles to a specific enviroment (prefix??) how do I do that. winetricks always wants to add to .wine instead of .wine_myapp...

Also how do I install an app to a specific enviroment without using PlayOn Linux?

That's what the purpose of the line

export WINEPREFIX="$HOME/.wine_myapp"

The terminal (shell) creates a "yellow post it" of this (WINEPREFIX) and then wine, winecfg, and, I guess, winetricks check for this "post it" (variable) when they are run. Re-read the 1st reply to the post and further explanation later on.

[vitamin]

cd $HOME
mkdir .wine_myapp
export WINEPREFIX="$HOME/.wine_myapp"

Not entirely correct. You need just last line. Wine will make directory automatically.

[bigseb]

If I need to add, say, directx or j# redistributibles to a specific enviroment (prefix??) how do I do that. winetricks always wants to add to .wine instead of .wine_myapp...

Also how do I install an app to a specific enviroment without using PlayOn Linux?

That's what the purpose of the line

export WINEPREFIX="$HOME/.wine_myapp"

The terminal (shell) creates a "yellow post it" of this (WINEPREFIX) and then wine, winecfg, and, I guess, winetricks check for this "post it" (variable) when they are run. Re-read the 1st reply to the post and further explanation later on.

I still don't understand When I open the winetricks app it says at the top of the window "Winetricks - choose a wine prefix" but there is no way of adding to .wine_myapp

As an example: I have a software called MoI. The .exe is in my downloads folder. I would like to install this not in the .wine folder but in the .wine_MoI folder. How do I do this?

Another software I have is called Alibre. Its .exe is also in my dowmloads folder. This I would like to install to .wine_alibre but it also needs J# redistributibles and directx9. How do I go about this?

Please help me through this. I much appreciate it.

[dimesio]

I still don't understand When I open the winetricks app it says at the top of the window "Winetricks - choose a wine prefix" but there is no way of adding to .wine_myapp

You can't use winetricks' GUI menu to add wineprefixes of your own choosing. Use the command line with the WINEPREFIX variable both to create the wineprefix and to run winetricks.

As an example: I have a software called MoI. The .exe is in my downloads folder. I would like to install this not in the .wine folder but in the .wine_MoI folder. How do I do this?

Another software I have is called Alibre. Its .exe is also in my dowmloads folder. This I would like to install to .wine_alibre but it also needs J# redistributibles and directx9. How do I go about this?

http://wiki.winehq.org/FAQ#head-faf9617 ... 522d490faf

[bigseb]

http://wiki.winehq.org/FAQ#head-faf9617 ... 522d490faf

From that link:

7.2. Can I store the virtual Windows installation somewhere other than ~/.wine?

Yes: ~/.wine is just the default Wine "prefix" (a.k.a. "configuration directory" or "bottle").

You can change which prefix Wine uses by changing the WINEPREFIX environment variable (outside Wine). To do this, run something like the following in a terminal:

export WINEPREFIX=~/.wine-new
wine winecfg

Wine will then create a new prefix in ~/.wine-new.

To use the default prefix, use the command unset WINEPREFIX . Or just set WINEPREFIX to ~/.wine.

Alternatively, you can specify the wine prefix in each command, e.g.

WINEPREFIX=/path/to/wineprefix wine winecfg

You can rename, move, copy and delete prefixes without affecting others, and each prefix has its own wineserver instance.

Wherever you see "~/.wine" or "$HOME/.wine" in this Wiki, you can usually replace it with "$WINEPREFIX".

I don't know what to do with that Sorry

[fcmartins]

I don't know what to do with that Sorry

The answer to that FAQ question is actually telling you a lot of things, which might get confusing. But I'm not sure what exactly is your question now.

The following commands should do what you want:

export WINEPREFIX=~/.wine-new
wine winecfg
winetricks

Keep in mind that every time you close a terminal, the variable WINEPREFIX is removed. So, when you open a new terminal, you have to do the "export" thing for the prefix (environment) you want to use.

[bigseb]

export WINEPREFIX=~/.wine-new
wine winecfg
winetricks

Keep in mind that every time you close a terminal, the variable WINEPREFIX is removed. So, when you open a new terminal, you have to do the "export" thing for the prefix (environment) you want to use.[/quote]

See, this is where I get lost. Take those first three lines of code, I don't know what they do The first creates a new wine folder called (in this case) wine-new. The second and third lines I haven't a clue. I know you're trying to help but I'd really like to understand why I'm typing what you suggest. I also not sure what you mean in the last paragraph. Sure, closing the terminal will 'lose my place' so to speak but what do I do with the exporting bit.

As I said above, I have the .exe in my Downloads folder. I double click it and it installs in the .wine folder and the program works beautifully but since it is being recommended to install in clean prefixes I'd like to learn how its done.

Thanks though for all your input so far.

[dimesio]

See, this is where I get lost. Take those first three lines of code, I don't know what they do The first creates a new wine folder called (in this case) wine-new.

No, it doesn't. What it does is set .wine-new as the default wineprefix for that terminal session.

The second and third lines I haven't a clue.

The second line runs winecfg for the wineprefix you specified in the first line. If you haven't yet created it, it will be created automatically before winecfg opens. The third line runs winetricks for the wineprefix specified in the first line.

Sure, closing the terminal will 'lose my place' so to speak but what do I do with the exporting bit.

You don't do anything with it after setting it, unless you want to change to a different wineprefix in the same terminal session.

[jjmckenzie]

On Sat, Dec 3, 2011 at 3:07 PM, bigseb <[email protected]> wrote:

export WINEPREFIX=~/.wine-new
wine winecfg
winetricks

You need to find a good book/web site on how to use Unix scripts.
Then you can create a launcher for each program that will set the
WINEPREFIX, change to the program directory within it and then launch
the program you want to run. You were told this before.

James

[motub]

export WINEPREFIX=~/.wine-new
wine winecfg
winetricks

Keep in mind that every time you close a terminal, the variable WINEPREFIX is removed. So, when you open a new terminal, you have to do the "export" thing for the prefix (environment) you want to use.

See, this is where I get lost. Take those first three lines of code, I don't know what they do The first creates a new wine folder called (in this case) wine-new. The second and third lines I haven't a clue.

OK, one reason why you're confused is because you've misunderstood a bit.

The export command does not create the new folder which will contain the files and configuration of the new WINEPREFIX. It's just a name, or rather, a pointer (rightly called a variable) .

Let me give you an example, if I may. If you were on Windows, and you needed help, and I said 'Go into the "Windows" folder', you would most likely know exactly where that was, because by default every Windows system since Windows 1.0 has put the Windows folder on the root of the C: drive. So unless you had just installed Windows for the first time 2 hours ago, you would go directly to C:\Windows without me having to describe "Go into My Computer, then go to the C drive and then find the Windows folder".

But suppose I had (with some difficulty, because Windows doesn't like you dong this at all), installed or moved Windows to the D: drive instead of the C: drive? That would make the location of the Windows folder a variable (because its location is no longer fixed where it is normally expected)-- but naturally, Windows has to know, all the time, where the Windows system folder is. So somewhere, in the bootloader probably, is a variable that says $WINDOWS=D:\Windows, where D:\Windows is the value (location) of the variable (where the heck is) $WINDOWS.

But setting, or better yet, changing-- such a variable from, say, C:\Windows to D:\Windows-- doesn't install or move the Windows system files from the C:\ drive to the D:\ drive. You still have to do the install, or move the data from the one partition to the other or whatever.

In the same way, setting (exporting) a new value for the $WINEPREFIX variable doesn't create that $WINEPREFIX; it's just data, sitting there waiting for Wine to run. Wine, the next time it runs from that terminal session, will look at this value to know where it should operate out of as a base for its drive_c, theme settings, drive settings and so forth.

At this point, though, the folder, ~/.wine-new in this example, does not yet exist (and it doesn't need to). When you run winecfg (or whatever) from that terminal session, Wine runs (winecfg is a internal Wine base configuration GUI application, so when you run winecfg, Wine itself necessarily runs). Wine says to itself, "What is my $PREFIX? Oh, OK, ~/.wine-new." But then Wine discovers that ~/.wine-new doesn't exist, so before it does anything else (like run the app you requested, be it winecfg or something else), the folder is created and populated with a basic configuration and fake Windows system.

This is (one good reason) why winecfg is suggested as the first Wine-using command after exporting a new prefix, so that you can immediately customize the newly-created prefix. You may want to set specific additional "drives", or you may want to set that particular $WINEPREFIX to use a virtual desktop, set a theme for apps installed under that prefix, set specific overrides for individual apps installed under that prefix, or set general overrides for all apps installed under that prefix. These are all functions of winecfg, and allow you to glimpse the huge amount of flexibility you have in tailoring $WINEPREFIXes to be both distinct from each other, as well as targeted to the specific functionality that the applications installed to that $WINEPREFIX need to run their best.

Since you're still in the terminal session when you exit winecfg, the export is still active, so when you run winetricks (which is a third-party script available via a link in the Wiki, which allows you to easily install override DLLs and many popular application/game support apps, like Quicktime and Adobe AIR and so forth, among other things), the "default prefix" is still the same one you just exported and configured (if you don't believe me, select "Select the default prefix" in winetricks, then look at the titlebar of the next screen-- it will say "current prefix is {name of the prefix you exported}".

I agree that it is a bit confusingly worded, but as soon as I realized that I could confirm what prefix winetricks was using by looking at the titlebar, I relaxed; so should you . The result is that all of the overrides you install with winetricks under that prefix stay in that prefix, affecting only applications you install while using that particular prefix.

I also not sure what you mean in the last paragraph. Sure, closing the terminal will 'lose my place' so to speak but what do I do with the exporting bit.

What that means is that every time you run, from the terminal, a program installed to, or a program that you want to affect, a particular $WINEPREFIX, you must first re-export that $WINEPREFIX in that terminal before running the program using Wine. When the terminal changing the $WINEPREFIX variable is closed, wine naturally defaults back to.... its default, which is running everything out of .wine. But nothing horrible will happen if you forget, either your program won't run (because Wine won't be able to find it in ~/.wine if it was installed in ~/.wine-new) or you'll notice that winecfg or winetricks is set to another prefix than the one you meant, so you just cancel, do the export and then try again.

But running from the terminal is generally only strictly necessary for 1) install programs (because if you double-click on setup.exe from the file manager, the setup will run from/be installed to ~/.wine, and not ~/.wine-new, as the file manager doesn't have a clue what variables you've set in the terminal), and 2) if you have problems with the game or application and need to see the output Wine is generating.

Once the program is installed, the desktop icon or menu item includes a variable to tell Wine that the app operates from an alternative $WINEPREFIX; if you don't have or use desktop icons, it's very easy to write a simple shell script (seriously, 4 lines, including the header) that will export the correct $WINEPREFIX before running the application, for your dock, for example. Attach the icon that Wine extracted when it installed the app or game, and it looks just like the real thing .

As I said above, I have the .exe in my Downloads folder. I double click it and it installs in the .wine folder and the program works beautifully but since it is being recommended to install in clean prefixes I'd like to learn how its done.

If you only have the one program, then it's not a big deal. But once you start getting more programs, or mixing apps and games, or installing lots of games, then it's really best to get familiar with multiple prefixes.

Obviously the program you've installed works fine without need for overrides (Platinum app! Good on ya!). But what if you now want to install another app that according to the AppDB is only a Bronze (and that rating was way back in Wine 1.2 days or earlier)? You could conceivably mess up your perfect program by installing overrides that it doesn't need (but the other program does) if the two share a $WINEPREFIX. Overriding dlls is still risky business, after all. Even worse is if the second app or game itself installs older versions of system files than what the prefix already has (which a lot of older apps and games do, without asking-- install for-them-current-but-for-us-ancient versions of things like Direct X or Quicktime), thereby causing a version mismatch (if you're "lucky"), or breaking the media capabilities of both applications (most likely ).

And what then? You might easily wind up with either a nightmare trying to remove the overrides so that the first, formerly working, program might work again, or a waste of time by deleting the ~/.wine folder entirely and reinstalling the platinum progam again (and regretfully ditching the other). And that's assuming that there's only two progams installed. I daresay many, if not most, if not indeed almost all of us have substantially more installed than that (often all to ~/.wine)-- and the prospect of reinstalling some 5 or 10 or 20 programs just because your luck ran out with the last one is not appealing.

Installing multiple $WINEPREFIXes can sound confusing and alarming to new, terminal-inexperienced Linux users, but it's a lot less trouble to create a safe sandbox for every app or game to play in (unless you know for sure that they play well together, such as two apps by the same software house, or two games in a series), then it is to sort out the mess if a fight turns into a free-for-all in Program Files.

But feel free to take your time. Everything doesn't have to be installed in a day, hopefully. And, you know, Linux is not Windows. Here, you can just "follow instructions" and type what you're told (by trustworthy people) to type, and then examine the effects.

When you type in the export command, nothing will happen (because it's an internal variable and there's nothing that you, the user, needs to see happen as such). But then when you type winecfg, you'll see a little dialog saying that Wine is creating the folder .wine-whatever-your-new-prefix-is, after which winecfg opens. So you can begin to understand how the process works, since you see the effect of your command and how everything fits together. As I said, when you select the "default prefix" in Winetricks, winetricks immediately tells you (in the titlebar) what it considers the default prefix to currently be (and now I get it, what it means by default prefix is the value of $WINEPREFIX, whatever that may be. The idea apparently being that even though the current value of $WINEPREFIX (~/.wine-new) may not be the default value (~/.wine)--, whatever the current value is, is effectively the default. Yeah, it's still obscure).

But anyway, don't be afraid to get your hands dirty even if you don't understand thoroughly. The terminal is your friend; it really almost never bites. And the Windows habit of double-clicking in the file manager does remove some control from your hands--- control you might not realize you needed until somewhere down the road when getting it back is a big PITA. So be brave and keep control in your own hands; you might be surprised at how easy it is to run the show .

Here endeth the wall o' text for today .

[bigseb]

export WINEPREFIX=~/.wine-new
wine winecfg
winetricks

Keep in mind that every time you close a terminal, the variable WINEPREFIX is removed. So, when you open a new terminal, you have to do the "export" thing for the prefix (environment) you want to use.

See, this is where I get lost. Take those first three lines of code, I don't know what they do The first creates a new wine folder called (in this case) wine-new. The second and third lines I haven't a clue.

OK, one reason why you're confused is because you've misunderstood a bit.

The export command does not create the new folder which will contain the files and configuration of the new WINEPREFIX. It's just a name, or rather, a pointer (rightly called a variable) .

Let me give you an example, if I may. If you were on Windows, and you needed help, and I said 'Go into the "Windows" folder', you would most likely know exactly where that was, because by default every Windows system since Windows 1.0 has put the Windows folder on the root of the C: drive. So unless you had just installed Windows for the first time 2 hours ago, you would go directly to C:\Windows without me having to describe "Go into My Computer, then go to the C drive and then find the Windows folder".

But suppose I had (with some difficulty, because Windows doesn't like you dong this at all), installed or moved Windows to the D: drive instead of the C: drive? That would make the location of the Windows folder a variable (because its location is no longer fixed where it is normally expected)-- but naturally, Windows has to know, all the time, where the Windows system folder is. So somewhere, in the bootloader probably, is a variable that says $WINDOWS=D:\Windows, where D:\Windows is the value (location) of the variable (where the heck is) $WINDOWS.

But setting, or better yet, changing-- such a variable from, say, C:\Windows to D:\Windows-- doesn't install or move the Windows system files from the C:\ drive to the D:\ drive. You still have to do the install, or move the data from the one partition to the other or whatever.

In the same way, setting (exporting) a new value for the $WINEPREFIX variable doesn't create that $WINEPREFIX; it's just data, sitting there waiting for Wine to run. Wine, the next time it runs from that terminal session, will look at this value to know where it should operate out of as a base for its drive_c, theme settings, drive settings and so forth.

At this point, though, the folder, ~/.wine-new in this example, does not yet exist (and it doesn't need to). When you run winecfg (or whatever) from that terminal session, Wine runs (winecfg is a internal Wine base configuration GUI application, so when you run winecfg, Wine itself necessarily runs). Wine says to itself, "What is my $PREFIX? Oh, OK, ~/.wine-new." But then Wine discovers that ~/.wine-new doesn't exist, so before it does anything else (like run the app you requested, be it winecfg or something else), the folder is created and populated with a basic configuration and fake Windows system.

This is (one good reason) why winecfg is suggested as the first Wine-using command after exporting a new prefix, so that you can immediately customize the newly-created prefix. You may want to set specific additional "drives", or you may want to set that particular $WINEPREFIX to use a virtual desktop, set a theme for apps installed under that prefix, set specific overrides for individual apps installed under that prefix, or set general overrides for all apps installed under that prefix. These are all functions of winecfg, and allow you to glimpse the huge amount of flexibility you have in tailoring $WINEPREFIXes to be both distinct from each other, as well as targeted to the specific functionality that the applications installed to that $WINEPREFIX need to run their best.

Since you're still in the terminal session when you exit winecfg, the export is still active, so when you run winetricks (which is a third-party script available via a link in the Wiki, which allows you to easily install override DLLs and many popular application/game support apps, like Quicktime and Adobe AIR and so forth, among other things), the "default prefix" is still the same one you just exported and configured (if you don't believe me, select "Select the default prefix" in winetricks, then look at the titlebar of the next screen-- it will say "current prefix is {name of the prefix you exported}".

I agree that it is a bit confusingly worded, but as soon as I realized that I could confirm what prefix winetricks was using by looking at the titlebar, I relaxed; so should you . The result is that all of the overrides you install with winetricks under that prefix stay in that prefix, affecting only applications you install while using that particular prefix.

I also not sure what you mean in the last paragraph. Sure, closing the terminal will 'lose my place' so to speak but what do I do with the exporting bit.

What that means is that every time you run, from the terminal, a program installed to, or a program that you want to affect, a particular $WINEPREFIX, you must first re-export that $WINEPREFIX in that terminal before running the program using Wine. When the terminal changing the $WINEPREFIX variable is closed, wine naturally defaults back to.... its default, which is running everything out of .wine. But nothing horrible will happen if you forget, either your program won't run (because Wine won't be able to find it in ~/.wine if it was installed in ~/.wine-new) or you'll notice that winecfg or winetricks is set to another prefix than the one you meant, so you just cancel, do the export and then try again.

But running from the terminal is generally only strictly necessary for 1) install programs (because if you double-click on setup.exe from the file manager, the setup will run from/be installed to ~/.wine, and not ~/.wine-new, as the file manager doesn't have a clue what variables you've set in the terminal), and 2) if you have problems with the game or application and need to see the output Wine is generating.

Once the program is installed, the desktop icon or menu item includes a variable to tell Wine that the app operates from an alternative $WINEPREFIX; if you don't have or use desktop icons, it's very easy to write a simple shell script (seriously, 4 lines, including the header) that will export the correct $WINEPREFIX before running the application, for your dock, for example. Attach the icon that Wine extracted when it installed the app or game, and it looks just like the real thing .

As I said above, I have the .exe in my Downloads folder. I double click it and it installs in the .wine folder and the program works beautifully but since it is being recommended to install in clean prefixes I'd like to learn how its done.

If you only have the one program, then it's not a big deal. But once you start getting more programs, or mixing apps and games, or installing lots of games, then it's really best to get familiar with multiple prefixes.

Obviously the program you've installed works fine without need for overrides (Platinum app! Good on ya!). But what if you now want to install another app that according to the AppDB is only a Bronze (and that rating was way back in Wine 1.2 days or earlier)? You could conceivably mess up your perfect program by installing overrides that it doesn't need (but the other program does) if the two share a $WINEPREFIX. Overriding dlls is still risky business, after all. Even worse is if the second app or game itself installs older versions of system files than what the prefix already has (which a lot of older apps and games do, without asking-- install for-them-current-but-for-us-ancient versions of things like Direct X or Quicktime), thereby causing a version mismatch (if you're "lucky"), or breaking the media capabilities of both applications (most likely ).

And what then? You might easily wind up with either a nightmare trying to remove the overrides so that the first, formerly working, program might work again, or a waste of time by deleting the ~/.wine folder entirely and reinstalling the platinum progam again (and regretfully ditching the other). And that's assuming that there's only two progams installed. I daresay many, if not most, if not indeed almost all of us have substantially more installed than that (often all to ~/.wine)-- and the prospect of reinstalling some 5 or 10 or 20 programs just because your luck ran out with the last one is not appealing.

Installing multiple $WINEPREFIXes can sound confusing and alarming to new, terminal-inexperienced Linux users, but it's a lot less trouble to create a safe sandbox for every app or game to play in (unless you know for sure that they play well together, such as two apps by the same software house, or two games in a series), then it is to sort out the mess if a fight turns into a free-for-all in Program Files.

But feel free to take your time. Everything doesn't have to be installed in a day, hopefully. And, you know, Linux is not Windows. Here, you can just "follow instructions" and type what you're told (by trustworthy people) to type, and then examine the effects.

When you type in the export command, nothing will happen (because it's an internal variable and there's nothing that you, the user, needs to see happen as such). But then when you type winecfg, you'll see a little dialog saying that Wine is creating the folder .wine-whatever-your-new-prefix-is, after which winecfg opens. So you can begin to understand how the process works, since you see the effect of your command and how everything fits together. As I said, when you select the "default prefix" in Winetricks, winetricks immediately tells you (in the titlebar) what it considers the default prefix to currently be (and now I get it, what it means by default prefix is the value of $WINEPREFIX, whatever that may be. The idea apparently being that even though the current value of $WINEPREFIX (~/.wine-new) may not be the default value (~/.wine)--, whatever the current value is, is effectively the default. Yeah, it's still obscure).

But anyway, don't be afraid to get your hands dirty even if you don't understand thoroughly. The terminal is your friend; it really almost never bites. And the Windows habit of double-clicking in the file manager does remove some control from your hands--- control you might not realize you needed until somewhere down the road when getting it back is a big PITA. So be brave and keep control in your own hands; you might be surprised at how easy it is to run the show .

Here endeth the wall o' text for today .

Thanks Motub, that is a huge help. Dimesio's link is also very good. After reading all that I feel I have a far better understanding of how this works. I really appreciate it.

One thing I am still uncertain of though is how to install a program to a specific prefix. Going by what I read above, if I haven't closed the terminal then I am still in 'export WINEPREFIX=~/.wine-new '. So do I just run 'wine myapp.exe'? And it automatically installs to the right prefix?

[Martin Gregorie]

One thing I am still uncertain of though is how to install a program
to a specific prefix. Going by what I read above, if I haven't closed
the terminal then I am still in 'export WINEPREFIX=~/.wine-new '. So
do I just run 'wine myapp.exe'? And it automatically installs to the
right prefix?

Yes.

If you want to double check, running the command

echo $WINEPREFIX

will show you what the current setting is.


Martin

[Mateusz Stachowski]

I'm using the env variable instead of the export command and it works nicely.

Code: Select all

env WINEPREFIX="/media/Dane/.wine-Skyrim/" winetricks vcrun2008

This will run winetricks for that enviroment and install vcrun2008 without going to GUI. Unfortunately installing Steam will always create Wineprefix in home .local/share/wineprefixes/steam (that's hidden folder in Nautilus press CTRL+H) and I don't know how to change it. The good side of it is that you can copy installed Steam to other Wineprefixes and use it.

Code: Select all

env WINEPREFIX="/media/Dane/.wine-Skyrim/" winecfg

This will create new clean Wineprefix (if it isn't already there) and open the Wine configuration program.

Code: Select all

env WINEPREFIX="/media/Ubuntu/.wine-NitronicRush/" wine-raw3 "/home/mateusz/qBT_dir/NitronicRush_setup_20111111.0.exe"

With that you would install NitronicRush on /media/Ubuntu within .wine-NitronicRush prefix using a patched Wine version.

[bigseb]

Thanks so much everyone for your help. Finally got it working. Very Happy!

[dimesio]

Unfortunately installing Steam will always create Wineprefix in home .local/share/wineprefixes/steam (that's hidden folder in Nautilus press CTRL+H) and I don't know how to change it.

Supposedly specifying --no-isolate on the command line will do it. I haven't tried it myself.

[Mateusz Stachowski]

Thank you the --no-isolate did the trick. I installed Steam into specified clean Wineprefix.

Code: Select all

env WINEPREFIX="/media/Dane/.wine-Steam/" winetricks --no-isolate steam