bigseb wrote:>
> fcmartins wrote:
> > 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
(http://wiki.winehq.org/ThirdPartyApplications), 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.
fcmartins wrote:> 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 ;-) .
fcmartins wrote:> 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 :-) .