Installing WINE on offline PC

[tone]

Hi,

I'm a very new user to WINE and Linux and I'm really interested in having access to my own offline repository and not being dependent on the internet.

For context I'm using MX Linux so I've played with Apt-offline to do this, but it's pretty tricky to get all the dependencies downloading them individually and installing them, so I prefer to install through terminal or package installer and so I periodically run the command: sudo cp -u -r /var/cache/apt/archives ~/Desktop/"More linux programmes"/debArchives

to copy them in the hopes that I can transfer these .deb s to another hard drive and install them all offline.

My concern is as to how to do this with WINE is heightened as I'm not sure how to download all the components like the d3dx 's and install them offline.

What if any, is the best way to do this?

P.S. just to show how inexperienced I am, can someone please explain how do I download folders on the browser, such as:
https://dl.winehq.org/wine-builds/debian/

Do I have to use a wget command or something?

Thanks in advance,
Rob

[spoon0042]

You could download that dir but that is almost certainly not what you want since it contains wine versions going back several years.

Good news though is that the wine packages are self contained; if you already have them installed on the online pc they should have been in /var/cache/apt/archives . For a given version there's just wine-devel, wine-devel-amd64, wine-devel-i386, and (optionally) winehq-devel. (Replace 'devel' with 'stable' or 'staging' if that's what you want.)

Unless by 'components' you mean you installed things with winetricks; if that's the case any files downloaded would be in $HOME/.cache/winetricks and you can simply copy that directory over.

[tone]

Hi and thanks very much for the reply; I think we're both on the same wave-length.

So I download for example wine-staging, wine-staging-amd64 and wine-staging-i386 and then backup the following directories:

/var/cache/apt/archives
$HOME/.cache
$HOME/.wine
and my winebottles

and I could even move them over to another OS and reinstall and use offline?

Side questions: which do you use, dlevel, stable or staging? What is dlevel anyway? Also, what is the difference between wine and winehq?

P.S. How even would I download that dir? (https://dl.winehq.org/wine-builds/debian/) Even if I wanted to I don't know how.

Thanks again!

[spoon0042]

Hi and thanks very much for the reply; I think we're both on the same wave-length.

So I download for example wine-staging, wine-staging-amd64 and wine-staging-i386 and then backup the following directories:

/var/cache/apt/archives
$HOME/.cache
$HOME/.wine
and my winebottles

and I could even move them over to another OS and reinstall and use offline?

Pretty much. Though only the 'winetricks' directory under .cache if it's there, ignore it if not. (.cache has things like your web browser cache which you probably don't want.) Also by default wine uses symlinks under C:\users to ~/Documents and others. It's possible some apps may use those so it's something to check if you find out you're missing something.

Side questions: which do you use, dlevel, stable or staging? What is dlevel anyway? Also, what is the difference between wine and winehq?

See here. Short version is 'devel' is the current and in development version of wine with releases generally every two weeks, 'stable' is, well, stable with only a few releases a year for certain bug fixes after the initial release. 'staging' is a set of experimental patches on top of 'devel'. If 'stable' works for what you want to run, then great. If something depends on a bug being fixed or some feature being implemented you may need 'devel' or 'staging'. (Those are in active development though so things can break as well.) There is the AppDB where you can read others (and post your own) experiences getting things to run.

The winehq-$BRANCH package just contains symlinks in /usr/bin/ so you can start applications by typing 'wine whatever.exe' in a terminal. If you don't install it you'll have to use the full path: /opt/wine-$BRANCH/bin/wine

P.S. How even would I download that dir? (https://dl.winehq.org/wine-builds/debian/) Even if I wanted to I don't know how.

You were on the right track, that's what 'wget' is for. It has options for mirroring whole sites if you want, you can look at 'man wget' for more information than you ever wanted.

Thanks again!

Sure, I hope this has been more helpful than scary.

[tone]

Hi,
Another very helpful reply, yes thank you. I'll have a look at the AppDB.

"The winehq-$BRANCH package just contains symlinks in /usr/bin/"

So if I download winehq-staging, wine-staginghq-amd64 and winehq-staging-i386 it would be the preferable option.

However, when you said "If you don't install it you'll have to use the full path: /opt/wine-$BRANCH/bin/wine" can you elaborate on what you mean, because I've never done that...?

Cheers!

[tone]

You were on the right track, that's what 'wget' is for. It has options for mirroring whole sites if you want, you can look at 'man wget' for more information than you ever wanted.

P.S. in addition to my previous post a minute ago. So would the command be:

wget --recursive --no-parent https://dl.winehq.org/wine-builds/debian/

Not that I'm actually going to do this!

Thanks again!

[tone]

P.P.S I've had a bit more of a think and I'm also wondering: if I installed WINE and did a straight cut and paste of my winebottles onto another OS, would they work? The reason I'm asking, is if I'm offline and don't have the chance to install the MS DLLs from the internet. Side question, is there any way to download all of these as are offered on winetricks for example as they are required in new winebottles, at a later date offline?

Much appreciated and thanks again!

[spoon0042]

Hi,
Another very helpful reply, yes thank you. I'll have a look at the AppDB.

"The winehq-$BRANCH package just contains symlinks in /usr/bin/"

So if I download winehq-staging, wine-staginghq-amd64 and winehq-staging-i386 it would be the preferable option.

However, when you said "If you don't install it you'll have to use the full path: /opt/wine-$BRANCH/bin/wine" can you elaborate on what you mean, because I've never done that...?

Cheers!

It would be four packages altogether: 'winehq-staging wine-staging wine-staging-amd64 wine-staging-i386'.

As for paths, on Unix/Linux/etc in a terminal those are the paths it searches when running a program. You can 'echo $PATH' to see for yourself. Programs in those directories can be run just by typing their name. Programs elsewhere can be run by specifying the full (absolute) path to them, like /opt/wine-staging/bin/wine. (Or by relative path, like ./foo/bar or ../bin/something.)

wget: something like that, yes. There's -m/--mirror specifically for mirroring that turns on --recursive and some other options. --no-parent would be good to add in the case you were mirroring that directory I think.

dlls: your bottles should be portable, I think. If you had to install any dlls they are in the wineprefix already. In fact if you have things working in a wineprefix you shouldn't need to copy over winetricks or its cache at all.

[tone]

Hi,
Another very helpful reply, yes thank you. I'll have a look at the AppDB.

"The winehq-$BRANCH package just contains symlinks in /usr/bin/"

So if I download winehq-staging, wine-staginghq-amd64 and winehq-staging-i386 it would be the preferable option.

However, when you said "If you don't install it you'll have to use the full path: /opt/wine-$BRANCH/bin/wine" can you elaborate on what you mean, because I've never done that...?

Cheers!

It would be four packages altogether: 'winehq-staging wine-staging wine-staging-amd64 wine-staging-i386'.

As for paths, on Unix/Linux/etc in a terminal those are the paths it searches when running a program. You can 'echo $PATH' to see for yourself. Programs in those directories can be run just by typing their name. Programs elsewhere can be run by specifying the full (absolute) path to them, like /opt/wine-staging/bin/wine. (Or by relative path, like ./foo/bar or ../bin/something.)

wget: something like that, yes. There's -m/--mirror specifically for mirroring that turns on --recursive and some other options. --no-parent would be good to add in the case you were mirroring that directory I think.

dlls: your bottles should be portable, I think. If you had to install any dlls they are in the wineprefix already. In fact if you have things working in a wineprefix you shouldn't need to copy over winetricks or its cache at all.

Fantastic, thanks for your time in replying.

So the benefit of installing winehq-staging is just the symlinks for wine-staging paths?

I'm slowly getting my head around it, although struggling to change from wine-stable to wine-devel, as I have broken packages which are evading my best efforts.

Thanks

[tone]

As for paths, on Unix/Linux/etc in a terminal those are the paths it searches when running a program. You can 'echo $PATH' to see for yourself. Programs in those directories can be run just by typing their name. Programs elsewhere can be run by specifying the full (absolute) path to them, like /opt/wine-staging/bin/wine.

Hi, I've been on something of an odyssey (which I'll write-up on another thread for the benefit of others when I have my thoughts in order...dependency hell etc.).

A couple questions which might be relevant to this thread which you may be able to shed some light [please] on regarding the above quote regarding /opt/.

Correct me if I'm wrong, but the .wine folder that gets created on the home directory is like a 'default prefix or test-bottle' of sorts?

I notice that the /opt/ folder has stable, devel and staging within:

-Is it in these folders which offers the installation options for things like d3dx, or even some of the MS DLLs when using winecfg or playonlinux? I notice they are fairly large folders and seems to be some if not all inside their Lib folders.

-How can I switch between running from these /opt/ stable, devel or staging? When I try to run the binaries ./wine from the folders respectively, the system only seems to want to run my installed wine which according to '$ wine --version' is "wine4.0 debian 4.0-2" which seems like a fairly old version to me, I assume it had to retro-install an old version based on the dependencies of how I installed it. But really I'm not sure.
Similarly, if I try to run for example ./wine /foo/bar.exe from the terminal in the wine-stable folder, from memory it gives me an issue like it's a 32bit and the wineserver is 64bit or something (not at home, so can't see exact message).

I'm not exactly sure which wine is installed or where this version of wine is installed, but for now I'd be happy to just run from the binary in /opt/ because I can see that and feel I have an okay understanding of controlling it. I'm sure I'll understand the UNIX $PATH variables in due course.

Thanks again!!

[spoon0042]

You'll probably want to have a look here: Wine FAQ - wineprefixes

$HOME/.wine is the default, yes. You can specify a different one with the WINEPREFIX environment variable.

The directories under /opt are the different branches of wine and contain the wine implementations of dlls and programs. (These are called "builtin", the alternative being "native" Microsoft dlls typically installed with 'winetricks' into a wineprefix but don't worry about that right now.)

It looks like you still have the debian packaged wine installed, this is the one in /usr/bin and is the one just typing 'wine' in a terminal refers to. You can uninstall that if you want and install one of the 'winehq-' packages to make that branch the default.

re: paths, it's best practice to 'cd' to the directory containing the program you want to run first and run wine from there. For example '/opt/wine-devel/bin/wine foo.exe'. (Or you can do '/opt/wine-devel/bin/wine start /unix /path/to/foo.exe' but ignore that for now if it confuses you. )

re: 32 vs 64-bit, wineprefixes are one or the other, which is set when they're created and can't be changed. (See the FAQ link above for more on that.) This shouldn't cause issues though, you may want to double check you have both the -i386 and -amd64 packages installed for wine-devel, etc.

Hopefully that resolves some of your confusion.

[tone]

You'll probably want to have a look here: Wine FAQ - wineprefixes

$HOME/.wine is the default, yes. You can specify a different one with the WINEPREFIX environment variable.

The directories under /opt are the different branches of wine and contain the wine implementations of dlls and programs. (These are called "builtin", the alternative being "native" Microsoft dlls typically installed with 'winetricks' into a wineprefix but don't worry about that right now.)

It looks like you still have the debian packaged wine installed, this is the one in /usr/bin and is the one just typing 'wine' in a terminal refers to. You can uninstall that if you want and install one of the 'winehq-' packages to make that branch the default.

re: paths, it's best practice to 'cd' to the directory containing the program you want to run first and run wine from there. For example '/opt/wine-devel/bin/wine foo.exe'. (Or you can do '/opt/wine-devel/bin/wine start /unix /path/to/foo.exe' but ignore that for now if it confuses you. )

re: 32 vs 64-bit, wineprefixes are one or the other, which is set when they're created and can't be changed. (See the FAQ link above for more on that.) This shouldn't cause issues though, you may want to double check you have both the -i386 and -amd64 packages installed for wine-devel, etc.

Hopefully that resolves some of your confusion.

Ahh, okay, yes that does clear things up a bit, maybe I don't have both -i386 and -amd64 installed for -devel, -staging and -stable, because when I run a winearch=win64 for one of the branches (can't remember which) it gives me a wineserver issue.

Case in point, I tried running your example '/opt/wine-devel/bin/wine foo.exe' from the directory containing the programme, but it didn't work, perhaps you were simplifying it expecting me to have more common sense, but when I ran it with the prefix etc. e.g. as the following:

WINEARCH=win32 WINEPREFIX=~/wines/testbottle2 /opt/wine-stable/bin/wine ~/wines/testbottle2/drive_c/"Setup Project64 v2.3.2-202-g57a221e.exe"

It did work (except for the aforementioned 64bit issue). So I'm pretty confident I can run any branch on a winebottle from the terminal using the above method. If I ran the setup, would the installation icons on the desktop go to this bottle, or are they only for the ~/.wine prefix?

Finally, how would you suggest I remove the default /usr/bin ? (For instance if I wanted a different default branch) If I do a apt-get purge wine command or something, would that be best?

P.S. After-thought- what installation aspect was it that created the /opt/ -devel, -staging and -stable folders? I don't remember what I did which put them there. I suppose they don't strictly speaking need to be located in /opt/

Thanks and all the best!

[spoon0042]

Ahh, okay, yes that does clear things up a bit, maybe I don't have both -i386 and -amd64 installed for -devel, -staging and -stable, because when I run a winearch=win64 for one of the branches (can't remember which) it gives me a wineserver issue.

Case in point, I tried running your example '/opt/wine-devel/bin/wine foo.exe' from the directory containing the programme, but it didn't work, perhaps you were simplifying it expecting me to have more common sense, but when I ran it with the prefix etc. e.g. as the following:

WINEARCH=win32 WINEPREFIX=~/wines/testbottle2 /opt/wine-stable/bin/wine ~/wines/testbottle2/drive_c/"Setup Project64 v2.3.2-202-g57a221e.exe"

It did work (except for the aforementioned 64bit issue). So I'm pretty confident I can run any branch on a winebottle from the terminal using the above method. If I ran the setup, would the installation icons on the desktop go to this bottle, or are they only for the ~/.wine prefix?

When it "didn't work" did you set the WINEPREFIX or not? Wasn't clear but that's important. (Saying exactly what you typed and copying any output could be helpful if it's still an issue.)
One nitpick though: https://wiki.winehq.org/Wine_User's_Gui ... s_programs
Sometimes apps assume they're started from the directory they're in so it's safest to just do that to avoid problems.
Setting WINEARCH only does anything when a prefix is created. (I guess that's two nitpicks.)
Any desktop icons created by wine should have WINEPREFIX set and set the working directory so you don't have to worry about either. (It seems to sometimes specify the full path to wine and sometimes not? So you might have to edit those, I don't know.)

Finally, how would you suggest I remove the default /usr/bin ? (For instance if I wanted a different default branch) If I do a apt-get purge wine command or something, would that be best?

Yeah, you can purge the debian packages (wine, wine32, wine64, libwine, possibly others). Might help to do a dpkg -l '*wine*' -- the winehq packages are all named wine-devel* wine-stable* or wine-staging*. Also I suspect your 32/64-bit issue might be a side effect of the debian packages, you may need to recreate any wineprefixes but hopefully that will resolve your issues.

P.S. After-thought- what installation aspect was it that created the /opt/ -devel, -staging and -stable folders? I don't remember what I did which put them there. I suppose they don't strictly speaking need to be located in /opt/

The winehq packages (when you did 'apt install wine-devel' etc) install into /opt ...they are self-contained and you can copy them elsewhere say if you had something that only works with a certain wine version. Don't worry about that though.

Thanks and all the best!

np

oh, and if you haven't upgraded devel or staging recently you may want to hold off until 5.8 releases. 5.7 and 5.6 too I think had regressions. May not affect what you're trying to run but just to avoid another headache.

[tone]

Ahh, okay, yes that does clear things up a bit, maybe I don't have both -i386 and -amd64 installed for -devel, -staging and -stable, because when I run a winearch=win64 for one of the branches (can't remember which) it gives me a wineserver issue.

Case in point, I tried running your example '/opt/wine-devel/bin/wine foo.exe' from the directory containing the programme, but it didn't work, perhaps you were simplifying it expecting me to have more common sense, but when I ran it with the prefix etc. e.g. as the following:

WINEARCH=win32 WINEPREFIX=~/wines/testbottle2 /opt/wine-stable/bin/wine ~/wines/testbottle2/drive_c/"Setup Project64 v2.3.2-202-g57a221e.exe"

It did work (except for the aforementioned 64bit issue). So I'm pretty confident I can run any branch on a winebottle from the terminal using the above method. If I ran the setup, would the installation icons on the desktop go to this bottle, or are they only for the ~/.wine prefix?

When it "didn't work" did you set the WINEPREFIX or not? Wasn't clear but that's important. (Saying exactly what you typed and copying any output could be helpful if it's still an issue.)
One nitpick though: https://wiki.winehq.org/Wine_User's_Gui ... s_programs
Sometimes apps assume they're started from the directory they're in so it's safest to just do that to avoid problems.
Setting WINEARCH only does anything when a prefix is created. (I guess that's two nitpicks.)
Any desktop icons created by wine should have WINEPREFIX set and set the working directory so you don't have to worry about either. (It seems to sometimes specify the full path to wine and sometimes not? So you might have to edit those, I don't know.)

Finally, how would you suggest I remove the default /usr/bin ? (For instance if I wanted a different default branch) If I do a apt-get purge wine command or something, would that be best?

Yeah, you can purge the debian packages (wine, wine32, wine64, libwine, possibly others). Might help to do a dpkg -l '*wine*' -- the winehq packages are all named wine-devel* wine-stable* or wine-staging*. Also I suspect your 32/64-bit issue might be a side effect of the debian packages, you may need to recreate any wineprefixes but hopefully that will resolve your issues.

P.S. After-thought- what installation aspect was it that created the /opt/ -devel, -staging and -stable folders? I don't remember what I did which put them there. I suppose they don't strictly speaking need to be located in /opt/

The winehq packages (when you did 'apt install wine-devel' etc) install into /opt ...they are self-contained and you can copy them elsewhere say if you had something that only works with a certain wine version. Don't worry about that though.

Thanks and all the best!

np

oh, and if you haven't upgraded devel or staging recently you may want to hold off until 5.8 releases. 5.7 and 5.6 too I think had regressions. May not affect what you're trying to run but just to avoid another headache.

Hi,
To be clear when I copied what you previously said without the prefix, that's when it didn't work, so what I meant was that you probably just expected me to have common sense and do the prefix (but I wasn't sure it was mandatory). Anyway nevermind that.

I will wait install 5.8 when it comes out (I believe I read that releases are biweekly). I also read that -staging is no longer done, but that article was perhaps out of date and it is continued again.

I performed: sudo apt-get remove --purge "wine.*"
although maybe I should have done sudo apt-get remove --purge "^wine.*" or just sudo apt-get remove wine
However, I'm still new at this, so live and learn.

And I wanted to try using ./config and make on wine_5.6~buster.tar.xz which I had, to see if I could install a later version that way. I didn't realise that this was only 23mb, now it is currently in the process of 'make'-ing as we speak and the folder is growing in size (over 600mb currently). So what is happening, is it downloading dependencies etc from the internet or just growing from compiling the source code?

Would another better way to install a later version of wine be to launch winehq-devel_5.6~buster_amd64.deb and wine-devel_5.6~buster_i386.deb from the package manager? From what you've previously said, would I need to install BOTH of these, as well as the winehq-devel for symlinks?

As always, your guidance is much appreciated!

[spoon0042]

Hi,
To be clear when I copied what you previously said without the prefix, that's when it didn't work, so what I meant was that you probably just expected me to have common sense and do the prefix (but I wasn't sure it was mandatory). Anyway nevermind that.

I will wait install 5.8 when it comes out (I believe I read that releases are biweekly). I also read that -staging is no longer done, but that article was perhaps out of date and it is continued again.

staging did have a bit of a hiatus back around the 3.0 release, I think, but has been actively developed since.

I performed: sudo apt-get remove --purge "wine.*"
although maybe I should have done sudo apt-get remove --purge "^wine.*" or just sudo apt-get remove wine
However, I'm still new at this, so live and learn.

huh, I didn't know apt took wildcards. Always learning. That should wipe out any wine packages. The debian.org packages also have some name libwine* as well.

And I wanted to try using ./config and make on wine_5.6~buster.tar.xz which I had, to see if I could install a later version that way. I didn't realise that this was only 23mb, now it is currently in the process of 'make'-ing as we speak and the folder is growing in size (over 600mb currently). So what is happening, is it downloading dependencies etc from the internet or just growing from compiling the source code?

If you did './configure' and then 'make' then yeah it's building / compiling. (For future reference make has a -j option to set the number of "jobs" it runs at once. If you have a quad core cpu for example '-j 4' would speed things up by running the compile on all four cores.)

Would another better way to install a later version of wine be to launch winehq-devel_5.6~buster_amd64.deb and wine-devel_5.6~buster_i386.deb from the package manager? From what you've previously said, would I need to install BOTH of these, as well as the winehq-devel for symlinks?

As always, your guidance is much appreciated!

The winehq repository has packages going back a while so yeah you don't have to compile yourself in most cases. AFAIK apt will complain unless you specify all 3 (or 4) packages at once, e.g. 'apt install wine-devel=5.6~buster wine-devel-amd64=5.6~buster wine-devel-i386=5.6~buster' and optionally 'winehq-devel=5.6~buster'. If you do this you'll probably want to look up how to 'hold' packages otherwise the next 'apt upgrade' will install the latest again. 5.8 will likely release tomorrow though so you can probably just not worry about it. For future reference, again.

[tone]

If you did './configure' and then 'make' then yeah it's building / compiling. (For future reference make has a -j option to set the number of "jobs" it runs at once. If you have a quad core cpu for example '-j 4' would speed things up by running the compile on all four cores.)

The winehq repository has packages going back a while so yeah you don't have to compile yourself in most cases. AFAIK apt will complain unless you specify all 3 (or 4) packages at once, e.g. 'apt install wine-devel=5.6~buster wine-devel-amd64=5.6~buster wine-devel-i386=5.6~buster' and optionally 'winehq-devel=5.6~buster'. If you do this you'll probably want to look up how to 'hold' packages otherwise the next 'apt upgrade' will install the latest again. 5.8 will likely release tomorrow though so you can probably just not worry about it. For future reference, again.

You always have such helpful insights. Okay let me get this straight because search engines weren't much use and I only had a brief look at the manual. Can I do something like ./configure && make -j4

Most of my machines are i4 or i7 I think, I have a couple old AMDs which I don't regularly use. those intel's are all 4core if memory serves? So why have I never heard anyone mention that 'jobs' trick, I assume you can use it all the time on building anything?

Seriously, that is amazing that a 23mb folder can grow to be 1.6gb after being './configure' and 'make'?! That must be a serious amount of binary created from relatively few lines of code.

Okay, I'll install all three at once, I didn't know that, probably why I had issues in the past.

All the best,

Rob

[spoon0042]

You always have such helpful insights. Okay let me get this straight because search engines weren't much use and I only had a brief look at the manual. Can I do something like ./configure && make -j4

That's it, yep.

Most of my machines are i4 or i7 I think, I have a couple old AMDs which I don't regularly use. those intel's are all 4core if memory serves? So why have I never heard anyone mention that 'jobs' trick, I assume you can use it all the time on building anything?

I think the i-series are all at least 4. You can check with something like 'grep cores /proc/cpuinfo'. And yeah it's just one of those things you pick up along the way, heh. And of course you can use a lower number if you're doing something else but with a modern cpu you may not even notice.

Seriously, that is amazing that a 23mb folder can grow to be 1.6gb after being './configure' and 'make'?! That must be a serious amount of binary created from relatively few lines of code.

Well the initial 23 MB was compressed too but it still blows up.

Glad to help.