motub wrote: > > 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 :-) . 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?
