Wine 4 and 5 AppImage on github - No installation needed!

[trister]

While looking for a way to run an old windows game I came to this : https://github.com/ferion11/Wine_Appimage/releases
(speciffilcally I use https://github.com/ferion11/Wine_Appima ... 4.AppImage )
This is a Wine with all deps.
I ended up completely removing my wine installation (had issues with at least half of my windows programs).
Now I have made the links /usr/bin/wine and /usr/bin/wine32 pointing to the appimage above.

At the moment almost everything ( 90%) from my programs work -even the ones that had issues in windows 10.

(example command for the link ln -s /Path-to-image/wine-staging-linux-x86-v5.11-PlayOnLinux-x86_64.AppImage /usr/bin/wine )

[proebler]

Thanks for the tip trister.
The AppImage works in EasyOS, where I use it to run the Win version of XnView.

[mikewalsh]

@trister :-

Interesting concept. As an advocate of AppImages, I'm always happy to endorse any that work.....and as a long-term WINE user, too, naturally I'm quite curious about this..!

Coupla questions (if I may?)

• Do you still need to run

  Code: Select all

  winecfg

  .....in the terminal (after creating those sym-links), in order to set-up /root/.wine?

• What about all the other stuff that's normally in /usr/sbin, and /usr/local/bin and /usr/share? All self-contained?

(Having said the above, I would assume that if you're going to run all Windows PortableApps - which a good many of mine ARE - then you wouldn't need to run 'winecfg'. PortableApps create their own 'mini-registry' within their own directory, so in theory, at least, /root/.wine isn't needed.)

I think some experimenting is called for..!

Mike.

[mikewalsh]

Well......that was easy!

I run all my AppImages from a remote-mounted partition, but for those of you who don't have such to make use of, I would recommended placing the AppImage in /mnt/home. If, however, your Puppy is running on FAT32, you'll have to put it somewhere like /opt instead. It'll take a fair chunk of space up, because this is a BIG app.

I've set-up a dedicated 'save' within my 'test' install of Bionicpup64, and am running the WINE AppImage from within this.

Symlink your AppImage into /usr/bin TWICE; once as 'wine', and then again as 'wine32', following trister's instructions. Answering my own query, you don't need to run 'winecfg', since the first time you try to install/run anything. it runs automatically. You MAY need to set the run-action for any installers/apps, however; set this to

Code: Select all

wine "$@"

.....in the wee edit box that comes up when you select rt-clk->Set Run Action.

------------------------------------

After that, it's plain sailing; anything you install/run (in the case of PortableApps, will just fire straight up. If, like me, you have dedicated MenuEntry items, you'll probably have them set to run from /root/.wine; because these AppImages set-up /root/.wine32, you'll need to set-up a '/.wine' sym-link from '/.wine32'. Everything will then behave itself.

I can thoroughly recommend this way of doing things. It's nice & simple..!

Mike.

[trister]

...
because these AppImages set-up /root/.wine32, you'll need to set-up a '/.wine' sym-link from '/.wine32'. Everything will then behave itself.
...

First a comment on what you said above: For some reason /root/.wine and ./root/wine32 have some strange issues when used as symlinks . I started with the .wine linked to .wine32 but the system on some occasions did not like it . So I ended up removing the symlink.

On all the other stuff you;re quite right
I had spend many hours making squashfs of windows apps so they can run ok. Finding out the wine AppImage was something like a breakthrough for me

How my system is :
I have a frugal install in a folder in C: with windows 10.. On other partitions/disks I have my old windows folders an programs ranging from win98 and XP.
The system runs with EXIT: so nothing actually gets saved (I made a squashfs with MONO/Gecko in root/.wine32). The *.exe are associated with wine.

With the setup I mention in the first post here I just go to the original folder eg GamesXP folder and double-click the Diablo.exe , AnarchyOnline.exe etc and in 90% of the cases everything runs ok.

It couldn't any simpler (for me at least). No winecfg needed so far (I only used wine regedit and the 'assign cdrom" options)

I couldn't run Cisco Webex -It was installed ok (the 32bit version) but It couldn'tdetect network.

Programs that I couldn't run on Windows 10 run very good on Wine! I was so impressed that I 'm thinking on using Wine on Windows . I downloaded BoxedWine and will have a try at somepoint.

[Offtopic] about appimages : You could check my scripts/parsers here viewtopic.php?f=136&t=1655 .It scans the appimages folder/subforlders and Adds a folder in /root/Desktop and creates ".Desktop" entries for each file found. The idea is to automate everything and only edit problematic .desktop files (eg add --no-sandbox to electron apps). The second script just presents you with a menu to run one of the appimages found

Some games I've run : Diablo,Diablo2 ,AnarchyOnline, Neverwinter Nights (preinstalled from my old windowsXP -just edited the .ini to set the installation folder), Many BigFish (Hidded Object games), Some IGN Slots games, Heroes Of Might and Magic 2,3,4, UFOAftermath ,UFOAftershock ,CSBWin (DungeonMaster/ChaosStrikesBack Win),UFO:Extraterrestrials,SpaceHulkDLC and many more.

[taersh]

Hi.

Thanks for the link to the Wine AppImages.
I downloaded the 5.11 AppImage and am using also a symbolic link /root/.wine to /root/.wine32.
No problems so far.

I wrote a script to load my compat32_ArtStudio64_1.0.0.sfs simply by a menu entry.
After loading all the necessary symbolic links are created automatically and winecfg will start.
Just closing winecfg with the default settings enabled.

After that I'm immediately able to use Qtractor with a bunch of 129 Windows VST PlugIns via LinVST 3.21 and Carla 2.0.0.
Meanwhile I composed two Songs with Windows VST Synthesizers in use.
Seems pretty stable so far.

I'd never got this to work before with different other versions of Wine.

So, again thanks!

[step]

This script shows how to start wine (appimage) with a custom prefix--the huge folder in which wine builds the Windows registry and locates C:\ etc. It this example that would be folder "test1" . Place this script and the appimage in the same folder or adjust the path in the third line.

Code: Select all

export WINEPREFIX=/path/to/.wine-appimage/test1
mkdir -p "$WINEPREFIX"
"$(dirname "$0")"/wine-staging-linux-x86-v5.11-PlayOnLinux-x86_64.AppImage "$@"

[mikeslr]

Hi trister, step & mikewalsh,

Just reminding everyone something Mike Walsh pointed out awhile back. Short names are less likely to get mangled when typing. The name of an AppImage is for your convenience. You can --I guess within reason-- rename it to anything and when started by that new name will still function as before. I followed the instructions in the OP, but first renamed "wine-staging-linux-x86-v5.11-PlayOnLinux-x86_64.AppImage" to just "wine-staging" and all went well.

Indeed, better than expected. Not only did all my many XP applications run, but one of my favorite is now again usable: Photoscape would run, but its GUI lacked icons. Started under the AppImage, that's not the case. Oh, and avidemux 2.7.6 no longer refuses to leave the top-left corner of the screen.

Has anyone explored the possibilities which the 'PlayOnLinux' in its name suggests? Or is that a misnomer? The application 'PlayOnLInux' is supposed to enable you to install more than one Wine Version and choose under which version a program would be run.

Has anyone tried using it with a 32-bit Puppy? a 32-bit Puppy with a 64-bit Kernel?

[mikewalsh]

@mikeslr :-

Just reminding everyone something Mike Walsh pointed out awhile back. Short names are less likely to get mangled when typing. The name of an AppImage is for your convenience. You can --I guess within reason-- rename it to anything and when started by that new name will still function as before. I followed the instructions in the OP, but first renamed "wine-staging-linux-x86-v5.11-PlayOnLinux-x86_64.AppImage" to just "wine-staging" and all went well.

Absolutely, Mike. AFAICT, the act of clicking on the AppImage's 'outside' container transfers the executable action to the AppRun script inside, and this is what actually fires it up. So shortening the name as far as is practical makes it easier to remember AND to work with.....and, as you say, means there's less chance of it getting "mangled" during editing/scripting/whatever.

Just another convenient method of working with the things, and which makes them easier than ever to work with.

Mike.

[trister]

Has anyone tried using it with a 32-bit Puppy? a 32-bit Puppy with a 64-bit Kernel?

it's only for 64bit OS (but it contains the libs needed for running 32bit Windows apps).

I also wanted a similar appimage for my 32bit puppies/dogs but I couldn't find anything.

About the big appimage name: I have created a link to this file. Even the creator suggests creating specific links to this appimage named wine AND wineserver (all to the SAME appimage)
https://github.com/ferion11/Wine_Appimage

[taersh]

Just reminding everyone something Mike Walsh pointed out awhile back. Short names are less likely to get mangled when typing. The name of an AppImage is for your convenience. You can --I guess within reason-- rename it to anything and when started by that new name will still function as before. I followed the instructions in the OP, but first renamed "wine-staging-linux-x86-v5.11-PlayOnLinux-x86_64.AppImage" to just "wine-staging" and all went well.

Yes. I renamed it to Wine64.AppImage and it still works well.
I do rename all downloaded AppImages.

For the Wine64.AppImage I made a mime type /etc/xdg/rox.sourceforge.net/MIME-types/application_x-ms-dos-executable.
Having lots of Windows Portable Applications I just need to click its .exe file and it starts well. No matter if 32bit or 64bit.

[mikeslr]

Hi trister,
Thanks for the link. My most important take-away from is:

"4- Make the wineserver link (for winetricks) in your bin directory:

$ ln -s wine-VERSION.AppImage wineserver

I'm not certain about ferion11's naming conventions. I now suspect that "PlayOnLinux" is in the package name because "Appimage for last Wine 32bits from PlayOnLinux" [Emphasis supplied] indicates PlayOnLinux was utilized in his build process. [Sort of like including "dir2pet-by Barry K" in a name because it was used in the creation process. Very nice for attribution purposes; but adds not significant informaton for those who will use the product].

It appears that ferion11 has been working on this project for months and that "5.11" is the most recent of published builds. I would hazard a guess that the build-and-test process generated others. Certainly during that process and for others who duplicate it a fully descriptive name is important to avoid confusion. But as I wrote, as a mere 'user' truncating the name of the product appears to have not had any adverse effects.

P.S. @ taersh: As I run several Puppies I've created a pet to install the files discussed above rather than having to do it manually for each current and future Puppy. I'm currently on Bionicpup64 which employs Wine-portable rather than the Wine-Staging.AppImage. Not exactly certain what your post meant, I file-browsed to /etc/xdg/rox.sourceforge.net/MIME-types/ to examine what was there. It already contained a file named "application_x-ms-dos-executable". Opening it in geany revealed
#/bin/sh
exec wine.sh "$@"
which is the appropriate command for wine-portable and AFAIK was written when 'Registering' portable-wine.
[IIRC, on Fossapup64, where I did deploy the Wine-Staging.AppImage, when I went to run the first exe, I had to first right-click it and "set run command" as "wine "$@" --with "$@" already present].

So I would think that for the wine-staging.AppImage the 'text/contents' of the /etc/xdg/rox.sourceforge.net/MIME-types/application_x-ms-dos-executable file would be:
#/bin/sh
exec wine "$@"

p.p.s. The need to specify mime-types suggests that --contrary to suggestions in posts which I may have echoed without testing-- it may be difficult to impossible to run multiple versions of wine-and-or-Wine_portable. [This might help if there was a need to use both Wine and Wine-portable: MIME-types defined in /etc are, I believe, subordinate to those in /root/.config/rox.sourceforge.net/SendTo, the latter being assignable via Right-Click>Customize Menu].

p.p.p.s As I was rewriting the above 'link' pet to include the above files, I took another look at https://github.com/ferion11/Wine_Appimage for other things to include. None applied to my usage. But you might want to read it if you PRIME or vulkan mean anything to you.

[trister]

I always try to keep naming conventions/versions to know what works and what not.
I know that with each update i will have to update the links but I accepted that.

I don't know if this helps but I post here my shortcuts + my mimeapps.list with its equivalent wine.desktop (I use openbox) https://pastebin.com/KmqD76Ft

Note: ferion11 also has an AppImage for proton (for Steam games).

[mikewalsh]

@trister / @mikeslr :-

Oooh, I am WELL impressed with this, guys..!

Finally - after much messing about with non-matching 32-bit compat SFS packages, trying to make it run via chroot, etc - I now have WINE functioning flawlessly in Quirky64 "April" 7.0.1. And it was so simple.

-------------------------------

I've run jrb's 'lite' spin on the above Quirky64 for well over a year now; it's my "go-to", "do-anything", daily-driver. Of course, it bears the mark of the PuppyMaster.....these were always Barry's 'babies' from the word go. And it shows, with countless neat little additions that just make life so easy.

Thank you, Barry!

The 'standard' way most of us normally run WINE in 64-bit Pups is to run version2013's 32-bit .pets via the 32-bit_compat_libs SFS. I'm not knocking his 64-bit WINE .pets, but they've never really worked out for me. Not for lack of trying, either...

The 32-bit WINE builds always work flawlessly.

The issue here is that when Barry built these 'experimental' 64-bit Puppies, he meant for them to be just that; 64-bit only. A 32-bit_compat_libs package was never produced, as far as I'm aware, so the 'standard' way of installing WINE just hasn't been available to me. (*...sniff...*) Jrb suggested using the Tahr64 compat_libs package, but Quirky didn't want to know, did it?

I got re-reading this thread this afternoon. I don't know why, but 3 months or so back it just simply didn't occur to me to try these AppImages with Quirky. I proved to my satisfaction that it worked fine with Bionicpup64, and.....I guess I kinda walked away with the impression that it was more for newer, more modern Pups. Quirky IS getting a bit long in the tooth, now.....this is Tahrpup- era, after all.

Anyways....

---------------------------------------

I thought, "Hell; in for a penny..." I backed-up Quirky prior to experimentation, then went for it.....and I am well-"chuffed".

I created the 3 sym-links from the AppImage in /usr/bin, then it was "Eeny-meeny-miny-mo" time; what to try first? I eventually settled on the Audacity PortableApp. Brought it up; clicked on the 'exe file, and.....well; you could have knocked me down with a feather. 'Gobsmacked' wasn't the word...!

Winecfg ran, and promptly installed Mono & Gecko for me; moments later, it was all systems go. 5 seconds later, Audacity-portable fired-up, neat as you please. Nice one!

Now; this is the REALLY neat bit.

I got to thinking. I already had a fully-stocked & functional /.wine directory, sitting inside the 'external' WINE install I normally use. There's a lot of stuff in there, including TextAloud!, the text-to-speech industry standard, and around 4 GB-worth of AT&T "voices". That's a huge chunk of data to re-install (and pretty pointless duplicating it all). So.....

Moments later - after sym-linking the external /.wine directory into /root, and re-naming to /.wine32 - WineCfg popped-up, spent about 20 seconds 'updating', and.....all my standard Windoze apps were available. Brill!! Yeees.....

I'm going to convert the other 64-bitzers to use this, given that it runs happily under the oldest of 'em.

--------------------------------------------

To this end, I've put a small .pet together to simplify things, consisting of 5 sym-links. That's all.

The Wine64-5.11 AppImage has been copied over to inside the external WINE 'install'. There's the wine, wine32 & wineserver sym-links to /usr/bin.....and a .wine sym-link from the 'external' to /root, re-named to .wine32 (plus a /root/.wine sym-link to /root/.wine32; covering all the bases, y'see).

That's GOT to be the simplest route EVER to a fully-stocked & fully-functional WINE install; a single click to install 5 sym-links. Eee, I'm a happy bunny tonight..!!

Thanks again, Trister.

Mike.

[trister]

Yes, this wine Appimage changed much in my everyday usage.
Almost everything from my old computers run (much better than win10)...

Combining with WINEPREFIX and ushare the possibilities are even more.
I managed to run many Big Fish hidden object games, Anarchy Online, Diablo I,II , UFO aftermath, Chessbase up to ver 14 (if someone manages to run chessbase16 please inform ).
I even run my old Mame32 with wine now (I'm too bored to find correct roms for the newest linux MAMEs ).

Btw, have a look how I make my scripts in /root/Desktop (and run them like they are offline)

# CB14offline.sh
cd "/root/.wineCB14/drive_c/Program Files/ChessBase14/CBase14/"
WINEPREFIX="/root/.wineCB14/" unshare -n wine CBase14.exe

[geo_c]

I loaded the appimage, symlinked it, On first run Wine could not find the 'mono installer needed for NET applications' and asked to download it. I did NOT download it. But should I look into it?

I'm not overly concerned, because I really only wanted Wine for some music gear firmware editors that are basically XP programs, and so far they have worked.

Just wondering if that would be an issue for other applications.

[mikewalsh]

@geo_c :-

I loaded the appimage, symlinked it, On first run Wine could not find the 'mono installer needed for NET applications' and asked to download it. I did NOT download it. But should I look into it?

I'm not overly concerned, because I really only wanted Wine for some music gear firmware editors that are basically XP programs, and so far they have worked.

Just wondering if that would be an issue for other applications.

I'd delete the hidden ".wine32" directory in /root - this is the WINE 'prefix', or sand-boxed container where your virtual \:C drive exists - and run the

Code: Select all

winecfg

.....command to re-initialize everything. And this time, LET the installer download/install MONO.

You don't need to worry about the security/veracity of this thing. It doesn't come from anywhere to do with MyCrudSoft (if it did, it wouldn't work anyway). This comes direct from the WineHQ's own secure servers, and is always built for each specific release of WINE.

All the years I've used WINE, I've never, ever had any kinds of issues with it.

Just my two-penn'orth, FWIW..!

Mike.

[geo_c]

.....command to re-initialize everything. And this time, LET the installer download/install MONO.

Mike.

How about the Gecko package? Install that too?

[mikewalsh]

.....command to re-initialize everything. And this time, LET the installer download/install MONO.

Mike.

How about the Gecko package? Install that too?

Yup. Let the installer run through & install both - there's only those two. Gecko is, I think, something to do with HTML rendering - like if you run a web-browser; very few people use WINE for this, but even if you never do, WINE still won't run without it.

Again, it's direct from WineHQ's secure servers, & compiled for the version of WINE that you're running.

Mike.

[geo_c]

Wines running great! Appimages are the Bomb! It kind of makes me want to have a barebones system with mostly appimages and portables. Easy migration and syncing.

[mikeslr]

@ MikeWalsh.

I wondered if the Wine-Staging.AppImage was functional under Void64. It does. But fortunately I had chosen to create a SaveFolder rather than a SaveFile. Unless I did something wrong in deploying the AppImage or measuring its effects on my system, it appears to have created a folder in /root which occupies 800+ mega-bytes. That's kind of hefty even for a mastiff-puppy.

A quick survey suggests all that space is used primarily by mono & the 32-bit prefix. Can you check if deployment on your system has similar effects. If so, I was wondering if the technique we developed here, viewtopic.php?p=335#p335 could prove useful.

And no, I'm not playing Tom Sawyer again. I thought of asking you and hunted for the above post in order to save you some time. I had forgotten the details of how 'Externalization' came about until I found and read it.

[mikewalsh]

@mikeslr :-

And no, I'm not playing Tom Sawyer again.

^^^Lololol!!! (No, I haven't forgotten, ya cheeky beggar..! )

In my case, the entire WINE install is in its own, dedicated external directory.....on a partition of my big secondary data drive. The WINE AppImage is sym-linked into /usr/bin 3 times.....as 'wine', as 'wine32', and as 'wineserver'. The /root/.wine directory in the external directory is sym-linked into /root twice; as '/.wine', and as '/.wine32'. And I have a small, separately-installed package that merely runs the 'winecfg' command.

That's all I do. It is the easiest way, bar none, that I have ever found to add WINE into any 64-bit system. You don't need the 32-bit_compat_libs SFS.....the 32/64-bit conversion all happens within the AppImage itself. The guy who put these together made a pretty thorough job of it. It even works a treat for Barry's old 64-bit Quirky 'April' (which jrb gave the 'lite' treatment), for which a 32-bit_compat_libs package was never built; BK built those old 64-bit Quirkies to BE 64-bit only, and never intended people to run 32-bit apps on them... For such as them, he built 32-bit versions. (Why bother to run 32-bit apps on a 64-bit OS, when there's a 32-bit version of that same OS available in the first place?)

That was, I suspect, the thinking when he was working on them, some years ago.

T'other Mike.

[mikeslr]

There's a wine-staging_7.0-x86_64.AppImage available from here, https://github.com/mmtrt/Wine_Appimage/releases. Works as well as Wine-Staging4 at least under Fossapup64.
I'm not sure what's changed as I started to post the URL before I thought of that question. Will post then hunt for the Changelog.
Couldn't find a changelog. One change is that it's grown from a 298 Mb download to a 514 Mb download.

[mikewalsh]

@mikeslr :-

Ouch. That's getting slightly silly...

I have already made one unsettling discovery. You cannot re-use an existing 'prefix', as you could with the original AppImages trister found for us. WINE 7.0 appears to have changed quite a few things, and now functions somewhat differently.....unless this guy builds differently to ferion11. Top & bottom, if you've got a fairly full, complete 'prefix' already set-up - as I have - and you want to use this new AppImage build, then it's bad news for you. 'Cos you're going to have to set it up all over again.....right from scratch. In my case that not only means several of Adobe's CS2-series applications, but also a full 'set' of AT&T 'Natural' voices for text-to-speech on Nextup.com's 'TextAloud' (at around 600 MB a pop!) It's no wonder I keep the entire WINE install in its own directory on my secondary 3 TB data drive, is it?

(It also insists on OpenGL as well, these days....along with proprietary, up-to-date GPU drivers. 'Nouveau' & 'radeon' just ain't gonna cut the mustard any more....*shrug*)

I'll stick with WINE 5.11, thank you very much! Everything that uses it runs perfectly.....I can't see any need to change. In this particular instance, change for the sake of change is totally & utterly pointless. It's not like I'm trying to run brand-new apps, anyways.....most of mine are already several years old. PhotoScape hasn't been updated for over 6 years....and most software seems to perform better when run under date-sympathetic stuff that was current at the time it was originally released.

As always, though, thanks for bringing it to our attention, Mike.

T'other Mike.

[amethyst]

The sizes of these 64-bit Wine packages are horrendous. I only use old, small 32-bit programmes so think not worthwhile. I've also decided to stick with 32-bit Puppy until it becomes unusable (that will be whenever the internet browser becomes obsolete). Maybe I'll change to 64-bit if and when I get a newer machine with lots of ram so 64-bit can weave its magic........Is the size thing now something of the past? It seems as if very few are still concerned with the way things are going BIGGER, BIGGER, BIGGER, NEWER, NEWER, NEWER. If size no longer matters one may as well try other big distributions with all the bells and whistles . BTW - I'm back using Xenial 7.5. Lovely, polished Puppy which can actually run all the new 32-bit browsers it seems.

[version2013]

One interesting bit in the wine-7.0 release notes:

... "WoW64 thunks are implemented for most Unix libraries, enabling a 32-bit PE
module to call a 64-bit Unix library. Once the remaining modules are
converted to PE, this will make it possible to run 32-bit applications
without installing 32-bit Unix libraries." ...

https://www.winehq.org/announce/7.0

[mikeslr]

The sizes of these 64-bit Wine packages are horrendous. I only use old, small 32-bit programmes so think not worthwhile. I've also decided to stick with 32-bit Puppy until it becomes unusable (that will be whenever the internet browser becomes obsolete). Maybe I'll change to 64-bit if and when I get a newer machine with lots of ram so 64-bit can weave its magic........Is the size thing now something of the past? It seems as if very few are still concerned with the way things are going BIGGER, BIGGER, BIGGER, NEWER, NEWER, NEWER. If size no longer matters one may as well try other big distributions with all the bells and whistles . BTW - I'm back using Xenial 7.5. Lovely, polished Puppy which can actually run all the new 32-bit browsers it seems.

I explore other Puppys and methods. But my 'daily-driver' is Bionicpup64 with 32-bit compatibility SFS loaded and portable-wine 3.3 registered. On boot-up --after caching and buffering-- only about 177 Mbs of RAM are actually 'used', i.e. not otherwise available to applications. The 32-bit compatibility SFS is a 180 Mb download. Expanding into RAM would require about 450 Mbs. But Puppys cache that at a ratio of 5:1, so the wine-implementation actually only uses about 90. Portable-wine only installs a couple of symbolic links and some /usr/share/...desktop files: almost nothing at all.
As a result, my 'wine-installation' actually requires very little overhead while providing the convenience of the ability to use Window Programs as and when I need them without having to boot into a different OS; and still have immediate use of current Web-browsers and other applications.

From time to time --thanks to Puppys modular design-- I update just the kernel. That system could remain viable for many years to come, long after 32-bit Web-browsers are just a memory.
Fossapup64 set up similarly only requires a little more RAM and will be ready if and when Bionicpup's glibc and openssl can no longer support the then current applications.

None of this would be possible had it not been for shinobar, the Japanese Team and version2013's pioneering work on wine-portable.

There's a lot I could say about the trend to create applications requiring gigabytes in order to avoid using two applications each requiring only a couple hundred megabytes. But I'd rather take this opportunity to encourage shinobar, the Japanese Team and version2013 to consider this:
The only reason to run Wine is to take advantage of the thousands of 32-bit Windows programs which are available.* Wine-portable enabled Puppy Linux to provide the most efficient method among Linux distributions to do that. It still does.
At best, I can only re-use the system they devised to try to update to a newer Wine version Version2013 publishes. Wine continues to evolve. And Puppy Linux faces the challenge of overlays someday entirely superseding the 'another file system' mechanism upon which wine-portable depends. Perhaps they could re-examine the potential of wine-portable under those conditions; and whether a new publication of wine-portable is possible and warranted.

-=-=-=-=-----=-
* There are Linux Applications to do everything a 'home-user or amateur' might want [even, for those unaware of it, applications to prepare your US Tax returns]. Linux is not the primitive, arcane, toy-for-technicians it was when some of those technicians realized that being able to port Window's programs to Linux was a good idea. Businesses needing the latest 64-bit business programs are going to run those programs under the Windows operating systems for which they were designed, on the newest computers capable of running those and write the expense off as a tax deduction.

p.s. See my post here regarding using Duprate's 32-bit compatibility SFS for Voidpup64 together with portable-wine, viewtopic.php?p=48758#p48758

[amethyst]

There are a few windows programmes I have to run because the linux alternatives are so crap. Text-to-speech conversion, a proper audio player (with all the functions I want) and then a very good small word processor in Atlantis, and so on. I currently use Wine 3.3 but all my small applications used to work with a very old version of Wine which was loaded as an sfs with size of only 17MB.

[mikeslr]

jrb --who generally know which end is up -- has posted about successfully using Wine-x86_64-debian.stretch.AppImage, from here https://github.com/Hackerl/Wine_Appimag ... h.AppImage in VoidPup64, ScPup64, and others. See his post here, https://www.forum.puppylinux.com/viewto ... 840#p65840 about how he set it up. That technique looks very interesting.