Portable-Wine64 development ABANDONED with reasons

[mikeslr]

As many Puppys are now 64bit operating systems, while most Windows programs which continue to be useful are 32-bit, the objective is to efficiently run the latter under the former. The Windows programs I need, and/or hoped to have available themselves occupy only 20Mbs +/- of 'storage'.

wiak's reported, https://www.forum.puppylinux.com/viewto ... 902#p65902 the possibility of being able to use 32-bit Windows programs if only 64-bit Wine was installed. Essentially, once installed this command could be run from a terminal:

$ WINEPREFIX=~/.new32prefix WINEARCH="win32" winecfg

creating a 32bit wine-prefix thereby avoiding the need to first create a Linux Multi-Arch system: one under which both 32-bit and 64-bit applications can run; or the employment of a Wine.AppImage which creates a 1500 Mb +/- prefix (folder) even before you install any of your desired programs into it.

'Portablizing' Wine has the advantage that it locates almost all its components on Storage (less than 5 Mbs are within your operating system, itself) and installs programs when necessary (use of portable-programs are not) into the wine-prefix on Storage. Wiak's post engendered the idea of using one of Version2013's Wine64 pets as a source in creating a Portable-Wine64. See, https://www.forum.puppylinux.com/viewto ... 915#p65915 for details.

As a first step to trying to see if one of Version2013's Wine64 bit pets could be portablized, it seems sensible to make certain the above mentioned command would, itself, worked using a Wine64.pet. It does; but only after first creating a 64-bit wine prefix -- /root/.wine -- which --prior to Saving to a SaveFile or Folder where it would occupy the same amount on Store-- weighed in at 1500 Mbs. Creating the 'new32prefix' added another 500Mbs initially occupying RAM.

2,000 Mbs of storage to run a 20 Mb program? If it would run. It didn't. Not even wordpad* which the above command itself created within the 'new32prefix' ran. Even after I configured my Puppy to open an 'exe' mime-type with the wine32.

Maybe I didn't configure it correctly. But I'll leave resolution of that to someone with greater expertise.

For me, when available --it's not under VanillaDpup, likely also not VanillaUpup, but as AFAIK, only those-- the process of first loading and configuring a 32bit-Compatibility SFS, then Registering Wine-portable remains the most efficient --least resource demanding-- method to run Windows programs.
-=-=--=-=--=
* winepad was the only program created within the newwine32 prefix. Such programs as winefile, wineconfig and others which you execute under a wine32 implementation as 32bit programs were absent and would be run as 64-bit programs. This suggests that unless assigned to wine32 via set run action you still couldn't run 32-bit programs.

[mikewalsh]

@mikeslr :-

In all honesty, Mike, given that MyCrudSoft themselves only abandoned 32-bit releases around 2 years ago - and AFAIK, you can still run 'legacy' 32-bit stuff from a 64-bit version of Windows anyway - I don't see that there's really a problem.

Unless you're one of these individuals that absolutely MUST ALWAYS have the very newest, bleeding-edge version of everything, the 32-bit releases of most applications are going to run perfectly OK under 'normal' WINE for most folks.

T'other Mike.

[mikeslr]

Not really a problem. But I indicated I would explore creating a Portable-Wine64. So it seemed appropriate that I post my 'discovery' and why I'm not continuing.

By the way, I just set-up another test of the new version of portable-wine we've been working on. So I'm not relying on my sometimes flaky memory to report on its effect on system resources.

Under fossapup64, a 32-bit compatibility SFS is required. It will occupy 111 Mbs of Storage. Configuring the Wine-portable will create a wine-prefix on Storage. During that process the user has the option to install either or both Mono and gecko. I didn't install gecko as, AFAIK, it is only required if you run out-dated and insecure web-browsers under Wine. It's not needed for Wine-tricks. If the offer to install Mono is declined, the 32-bit wine-prefix will use only about 500 Mbs of Storage. If Mono is installed another 500 Mbs will be used.

[AFAIK, none of the programs I run require Mono. Do you know when it actually is required?]

Effects on RAM usage: Of course, when portable-wine is not required, the compatibility SFS can be unloaded (reboot required) and PPM used to uninstall the Registration of Wine-portable, result > Zero use of RAM. With the compatibility SFS loaded and Wine-portable Registered but not in use, less than 10 Mbs of RAM is otherwise not 'Available': just that necessary to cache a couple of pixmaps, menu's desktopfiles, and a few small bash scripts. When a program is run under Wine-portable, only that program itself makes any appreciable demands on RAM usage. The files of the compatibility SFS are not loaded into RAM, only indexed in RAM-cache, used when needed, dropped when not. The same applies to the files within the wine-sfs in the wine-portable folder which the wine-portable scripts mounts and accesses only as and when needed.

I suppose using an AppImage can have comparably minimal effects. The biggest difference is how much manual user intervention is required. Wine-portable requires that the 'ldconfig' command be successfully run. Some users have had difficulty doing that. Trying to start any windows program will trigger wine-configuration. No further user-intervention is necessary as Wine-portable's wine-prefix is on Storage.

Using an AppImage the user must create symbolic links to it (optionally menu listings) and if the wine-prefix is not to occupy /root/.wine --thus placing storage demands on a SaveFile/Folder-- and to always place some demands on RAM, that wine-prefix has to be manually moved to Storage and symlinked back.

Using an AppImage or Wine-portable in a 2nd Puppy, or more, user intervention differences are trivial. With an AppImage (in addition to creating the aforementioned symbolic links) before using the AppImage the first time under the 'new' Puppy, the wine-prefix on storage must be symlinked to /root. Using Wine-portable, a new instance of 32bit compatibility must be established and configured. Registering Wine-portable again just involves one click.