Hi Renegade Apprentice and 
to the Kennels.
In Linux, regardless of which Linux, borrowing a phrase from music theory, https://makingmusicmag.com/music-theory ... n-a-theme/ you are always dealing with some variation on a theme.
What you already know about Linux will carry over to a large extent into Puppy Linux; and despite however much Barry K --the creator of both Puppy Linux and EasyOS-- thinks they differ, the latter is a variation of the former.
The primary distinctions between Puppy Linux and "Major Distros" is that the latter are unitary systems which do not distinguish between RAM and Storage, constantly reading and writing between them. To achieve isolation of any thing from the whole system, Major Distros confine the activity of a User to his-or-her own folder unless and until the 'the Administrator's magic password' is given. 15+ years ago, Puppy Linux realized that the User was the Administrator and dropped that non-sense. But the environment in which Puppy Linux was to evolve was a PC running Windows; and Windows --then as now-- zealously guards the locations under its control. Unguarded at that time was what could be run from a CD --after all there had to be some way to get Windows onto storage in the first place. Windows also had no control of what happens in RAM, else you wouldn't be able to play 'Space Invaders'. Initially, therefore, Puppy Linux booted from a CD, and ran 'in RAM', disappearing from RAM when shut down and Windows was none-the-wiser.
The next variations were to (1) move Puppy's system files from the CD into only a folder on the hard-drive and boot it from there; and (2) extend Puppy's capabilities by making use of Linux's ability to merge file-systems in RAM: sort of like how graphic programs use Layers, one on top of another, only the top one showing, but not actually modifying the permanent base graphic until commanded to do so.
Those concepts 'merge in RAM', 'don't become permanent until commanded' form the basic techniques by which Puppy operating systems function today; how they differ from Major distros; and --with respect to your question-- to a large extent how EasyOS differs from Puppy Linux.
SFS is an acronym for 'squashed --i.e. compressed-- file-system'. To preserve customiztions, settings and the use of applications not included by the Dev in the base SFS Puppys evolved to make use of a Save.SFS: Information in RAM being written to such file on the Storage media, and on reboot such Save.SFS mounted with the files it contained having priority over any conflicting files in the base.sfs provided by the Puppy's Dev. [SaveFolders as an alternative to SaveFiles came later]. A remaster permanently combines the files-systems, again with those from the SaveFile/Folder having priority. Puppys can boot with instructions not to employ a SaveFile/Folder or to what extent their contents are to be copied into RAM. Alternative SaveFiles/Folders can be created. SaveFiles/Folders can be easily 'backed-up', deleted, and the use of alternative Saves offered as a choice on boot-up. [There's also available under Puppys an application which will package what otherwise would be in a SaveFile/Folder into a READ-ONLY SFS. I don't know about its utility under EasyOS].
Evolving at a time when computers seldom had more than 256 Mbs of RAM, conserving RAM to perform actual work was an objective Puppy tackled early on. One method was that rather than install an application into a SaveFile, it was packages as an SFS. As an SFS it could be mounted when needed, unmounted when not. Unmounted it required no RAM at all. Unmounted, its files can not conflict with any files currently in use. Major distros have only recently discovered the value of this idea, producing applications which don't have to be installed but are merely mounted. An AppImage is one such version. Flatpaks and Snapds are two others, both less useful under Puppys as both --unlike AppImages-- require applications within the OS to manage them.
Under Puppys, AppImages only have to be made executable, then file-browsed-to and Left-Clicked to run. Alternatively, a script can be written or a symbolic link created 'on the path' which will execute the AppImage from wherever it is located. If it will run at all.
As under other Linuxes, you can open a terminal and create a symbolic link. Or you can write a bash-script ‘on the path’ to an executable which, itself, isn't 'on the path' by using a text editor, then make the script executable. Or you can Right-click and empty space and select New>Script from the popup-window.
[Oddly, once the AppImage is, itself, executable the argument in the bash script does not take on the usual form, e.g.
exec /opt/master-pdf-editor-4/masterpdfeditor4 "$@"
Rather, only something like the following is needed:
/mnt/home/Pup-Apps/Leonflix.AppImage --no-sandbox
i.e. FULL-PATH-TO/x.AppImage
Note, however, the script itself must be executable.
But Puppys and EasyOS --which both employ Rox as file-manager-- provide an easy way to create symbolic links. Open two Rox windows, one to the file, the other to somewhere 'on the path' and drag the file from the former to the latter, selecting Link(relative) from the pop-up window. Both Puppys and EasyOS have a location 'on the path' which is a convenient location for such symlinks as it is unique to those OSes: /root/my-applications/bin.
You may run into a couple of problems trying to use AppImages. First, both Puppys and EasyOS 'run as root' and many AppImages -especially those based on Chromium or its cut down version known IIRC as Electron-- will refuse to run as Root. The workarounds published for Puppy with respect to those AppImages should work under EasyOS. Essentially, they take two forms. Start the AppImage via a bash-script which contains either of these arguments 'run-as-spot' or '--no-sandbox', such as in the Leonflix.AppImage example above. Sometimes you'll need both, e.g.
run-as-spot /mnt/home/Pup-Apps/eddie-VPN.AppImage --no-sandbox
Both AppImages and SFSes-created-for-Puppys are supposed to be 'self-contained': that is include within itself all the files upon which the application depends. Neither may prove true, especially with regard to AppImages. These are built and tested to function OOTB under 3 or 4 major Linux distros; the most relevant being some versions of Ubuntu or debian as many Puppys --and, for example, EasyOS-Buster-- are 'binary-compatible' with some version of Ubuntu or debian. Binary-compatible, however, does not mean 'identical'. Rather it means that Puppys and EasyOS have been built using the binaries of such distro-version, and their Package Manager will provide direct access to such distro-version's repositories repositories and the ability to install packages from them.
Between the core files of an operating system and the files of an application are an infra-structure which enables the former to make use of the latter. Puppys' infra-structure is unique to Puppy, except to the extent that it may also be employed in EasyOS. Consequently, Puppy and EasyOS may not already contain dependencies which creators of an AppImage assumed to be present and tested against.
Under EasyOS it is important to remember that there is a distinction between the MainOS and any Containerized-OS you can run under it. The Containerized-OS operates with a curtailed ability to mount file-systems. . As a result, it can not make use of either AppImages or SFSes. But you can install applications, or manually place an application's files into it. [I'm not sure how EasyOS accomplishes it, but IIRC --always a Big IF-- files and packages installed into the Containerized-OS were available on reboot].
The possible work-around is to extract the SFS or AppImage manually place its files in their proper locations; or perhaps repackage its contents as a pet.
AFAIK, all Linux OS's contain a folder: /opt. You can put anything into it. But remember, /opt is not on the path. LibreOffice provides a good example of how it can be used. I think EasyOS has UExtract builtin. If not, you can download it from here, viewtopic.php?f=106&t=594, then Left-Click the pet to install it. You can mount an SFS by merely Left-Clicking it and selecting "view". From the window which opens you can copy any/all files into another folder. [After Left-Clicking an SFS you'll also be offered the option of installing. This can be dangerous because (a) doing so may over-write files other applications depend on; and (b) AFAIK, there's no way to 'uninstall']. To extract an AppImage, open a terminal to its PARENT folder and type a version of this command:
./appImage-name --appimage-extract
At any rate, decompress LibreOffice and examine how an application whose files are located in /opt is 'tied' into the operating system.
Also examine how MikeWalsh and fredx181 build portable-webbrowsers with scripts to run them from anywhere, viewforum.php?f=90.
Once a AppImage or SFS has been decompressed, copied to a folder and any necessary dependencies and restrictions [such as 'look only here for libraries' or no-sandbox or 'run-as-spot'] supplied that folder can be manually located in /opt. Alternatively, you can create a named folder, e.g. my-new-thing, create an /opt folder within it, copy your application's folder into that /opt, with other folders such as LibreOffice or a portable-web-browser uses to tie it into your OS, then (1) if available via Right-Click menu, right-click the my-new-thing folder and select "Create a pet package". (2) If not, open a terminal in my-new-thing's parent folder and enter the command dir2pet.
Three other things worth knowing about:
https://rockedge.org/psearch/ is a dedicated Search Engine for 'all things Puppy'.
ListDD, http://www.smokey01.com/radky/ is a great tool for determining what dependencies an application requires which your version of Puppy hasn't provided. [Unfortunately, it is of no use if what's lacking or conflicting is a python module].
and https://pkgs.org/ is a great source of links for obtaining such dependencies if Puppy's Package Manager can't.
P.S. Re-read your post. About Wine. Creating Wine packages which function, I've only found three methods; two of which won't function under a Containerized-OS, and I'm not sure about one under EasyOS, itself. One of the Wine.AppImages from this thread, viewtopic.php?p=13634#p13634 should work under a Ubuntu/Debian Main EasyOS if you follow the instructions on that thread. But not under the Containerized-OS since you can't mount it. And EasyOS-dunfel and similar may lack required dependencies. Portable-Wine from here, https://oldforum.puppylinux.com/viewtop ... 8&start=45 should run under Ubuntu/Debian based EasyOS provided that if they are 64-bit you also SFS-load the appropriate 32-bit compatibility SFS. But as it makes use of an SFS, it can't be used in containerized OSes. In passing, note that to build that portable I used one of Version2013's pets.
Building functional Wine is an art which Version2013 has mastered. I don't know any other Puppy Dev whose builds I trust, whose builds haven't generated posts about problems. I don't know whether EasyOS's package manager offers a Wine version. But my instinct is, if possible, use one of Version2013's builds.
Most of what I wrote here, viewtopic.php?p=31258#p31258 about getting a Windows program to run under EasyPup will apply to EasyOS. In particular, read the last paragraph. My recollection is that at some point I did have one of Version2013's Wine.pets running under Containerized racy. Racy is a 32-bit system OS, so doesn't need a compatibility layer. It is one of the operating systems BarryK has provided as an SFS-download. But TBH, it's been a while since I worked with EasyOS and I don't really trust my 'mid-term' memory.
A possible alternative --untested-- is that EasyOS --itself, & not a containerized OS-- could run the SFS of a Chrooted 32-bit operating system into which Wine had been installed. See the discussion here, viewtopic.php?p=33971#p33971. Note, it will not be as 'locked down' as a containerized-OS but exposure from its web-facing applications can be limited by using a VPN. FWIW, I've built such chroots using either dpup-stretch or xenialpup. Chrooted, Xenialpup's uget ran much better.
P.S. after the 3rd read of your OP.
Wine: If you employ the Wine.AppImage from the above linked thread, you'll also find instructions on that thread for linking it to your OP. An advantage of the AppImage per those instructions is that it enables you to run both 32-and-64 bit Windows programs.
Most of the Windows programs you may want to run are 32-bit. To run them under a 64-bit Puppy --other than by using the referred to AppImages-- requires that you first establish and configure a 32-bit Compatibility layer. You do this by downloading the appropriate SFS, SFS-loading it, then entering a terminal and typing, without the quotes, 'ldconfig'. The first letter of that word is a 'small' l (phonetic 'el') not a capital I (phonetic 'eye') or the letter 1. It should take some time before your terminal again becomes available. The ldconfig command sets up many links. I recommend that you have some simple 32-bit application other than Wine to test whether the command was successful.
[You can download opera-12.16-1860.i386.linux.tar.xz from here, https://get.opera.com/pub/opera/linux/1216/ and UEXtract it. Left-Clicking the opera script in the extraction folder should start it. You don't really care if it is fully functional or a web-browser Websites will grant access to].
If that application doesn't run, try re-entering the command.
Only after you've succeeded with configuring the 32-bit compatibility module will you have any hope of creating a wine emulation layer. Once you've installed a 32-bit Wine pet, or registered the 32-bit portable wine, you again have to open a terminal. Type the command 'wine winecfg'. But have a connection to the internet already established. The first thing configuring Wine tries to do is to install mono and gecko from WineHQ's repos.
It may help if you understand Linux packaging. A Package is an assemblage of files organized in such a way that the package manager of operating system for which the Package was created can unpack it and copy its files into designated folders within the structure used by that operating system. The structure of most Linux OSes are similar-to-identical, including those of Puppy and EasyOS. Puppys --while they do not employ Synaptic or Apt, or Slackware's package manager-- contain modules which can properly unpack debs and txz packages, create folders corresponding to those provided by the package creator in the package and copy the package's files and folder into your OS .
Those files were compiled against the system in which they were expected to be used. Usually, the files compiled for one OS will be identical to those for another. But not always, not even if they bear identical names. Typing a package name in pkg.org's search box will usually generate dozens of links, one for each operating system for which a package was compiled. Packages for a Ubuntu version are likely to be identical to those for a debian version of the same vintage. But the further you go from your binary-compatible distro, the more likely there will exist that some difference which will prevent a packages use OOTB, without creating symlinks, or ever.
And, of course, there's the 32-bit-64-bit dichotomy. Slackware chose to handle it one way, debian/Ubuntu another. And Puppy Linux has struggled to develop a means to work with both. But that's a story for a different day.
You're really good at reading people.