Run 64-bit apps on S15Pup32 & vice-versa

[peebee]

Replace the 32-bit kernel with a 64-bit version then

Install 64bit-compat-s15pup32-22.12.sfs
from https://sourceforge.net/projects/spup/f ... 32/addons/

Install and run your 64-bit app

Note:
Computer will need to have a CPU that is 64bit capable.
Most have this, even if it originally had a 32bit version of Windows on it.

(also works on LxPupSc32 which comes with a 64-bit kernel)
(Also JammyPup32 with a 64-bit kernel)
(Also VoidPup32 with a 64-bit kernel)

e.g. 64-bit Chromium running on S15Pup32 with kernel 6.1.4 64-bit:

Screenshot.png (229.81 KiB) Viewed 1938 times

[peebee]

Run 32-bit apps on S15Pup64

Install the 32-bit libraries: 32bit-compat-s15pup64-22.12.sfs
from: https://sourceforge.net/projects/spup/f ... 64/addons/

n.b. do NOT use on VoidPup64 due to its lib structure

Screenshot.png (234.07 KiB) Viewed 1928 times

[Duprate]

Peebee: Your 32 and 64 bit compatibility packs have been very helpful to me! Thanks!

64bit-compat-s15pup32-22.12.sfs, worked perfectly on JammyPup32 (UPupJJ+D-22.04) ....

[bigpup]

Replace the 32-bit kernel with a 64-bit version then

Install 64bit-compat-s15pup32-22.12.sfs
from https://sourceforge.net/projects/spup/f ... 32/addons/

Install and run your 64-bit app

(also works on LxPupSc32 which comes with a 64-bit kernel)
(Also JammyPup32 with a 64-bit kernel)

e.g. 64-bit Chromium running on S15Pup32 with kernel 6.1.4 64-bit:

Screenshot.png

So you are just turning the 32bit version into the 64 bit version of S15Pup?

So is it still a 32bit version or a 64 bit version, that still has the stuff to run 32 bit software?

[jrb]

Wow! Just fired up my goto low ram ScPup32_21.04 and used LibreWolf, Brave, TextMaker2021. All 64bit only. Granted the 64bit kernel uses a bit more ram than 32bit but its still at least 150Mb less than any of my 64bit OS's. Browsers seem to take the same ram as in 64bit OS.

I can see where netflix users will be happy they can access in 32bit systems. Also, all those old timers, myself included, still attached to old 32bit software will be happy they can run on 64bit systems.

I'm sure imaginative Puppyians will find lots of uses for these compatibilty packs.

As usual, Thanks for this.

Cheers, J

[mikeslr]

As the initial posts by peebee and Duprate revealed that the 64-bit compatibility SFS could be used with Slacko based S15 and LxPupSc32 and jammy, which is a Ubuntu/debian based Puppy, and usable 32-bit Web-browsers are becoming few and far between, I did some exploration and opened a thread in the Browsers and internet Section. https://www.forum.puppylinux.com/viewto ... 550#p78550,

The above post provides an overview of my exploration with links to posts providing more details. Explored so far were xenialpup32, tahrpup32, dpup-stretch and Slacko_5.7.2CE. The best results were running the most recent Palemoon under tahrpup32; but tarhpup32 was the only Puppy I ran palemoon under. Palemoon did not suffer a loss of any functionality, though its did not properly display toolbar icons. It also required the least RAM. firefox-quantum required nearly a GB of RAM just to post text to this forum. But at its worst, it still required less RAM than running a web-browser in a Chroot IIRC.

I have a hunch that palemoon under dpup-stretch may do as well as under tahrpup32; perhaps under other Puppys newer than tahrpup32.

Congratulations, peebee for developing a marvelous piece of technology. Obtaining more RAM is usually less expensive and time consuming than either acquiring a new computer or fleshing out a new Puppy.

[mikewalsh]

Replace the 32-bit kernel with a 64-bit version then

Install 64bit-compat-s15pup32-22.12.sfs
from https://sourceforge.net/projects/spup/f ... 32/addons/

Install and run your 64-bit app

(also works on LxPupSc32 which comes with a 64-bit kernel)
(Also JammyPup32 with a 64-bit kernel)

e.g. 64-bit Chromium running on S15Pup32 with kernel 6.1.4 64-bit:

Screenshot.png

So you are just turning the 32bit version into the 64 bit version of S15Pup?

So is it still a 32bit version or a 64 bit version, that still has the stuff to run 32 bit software?

Poor old Bigpup! Always running the very newest, up-to-date 64-bit versions of everything, you really can't see the point of this, can you? I can just hear you, muttering to yourself; "Why not just run the newest 64-bit Puppy and be done with it?"

Partly because this is one of those things that legend has it simply cannot be done, and this proves it's entirely possible to do so.....and partly just for the hell of it, because we CAN.

AND.......because it's FUN. There doesn't always HAVE to be a 'point' to everything, y'know..... Certainly works for me, 'cos I've always liked 32-bit Xenial. It annoyed the hell out of me when Google deprecated 32-bit Widevine more or less on a whim, despite giving 3 years warning. It just wasn't a good enough reason, to my mind....

Posting this from the 64-bit current Iron-portable, running under Xenialpup 7.5 via Fossapup64's k5.4.53 kernel. I've only tried this one Pup yet, but this is bloody good fun..!

Nice one, Peter.

Mike.

[jrb]

AND.......because it's FUN.

Very nicely expressed Mike, a man after my own heart.

[bigpup]

So you are just turning the 32bit version into the 64 bit version of S15Pup?

So is it still a 32bit version or a 64 bit version, that still has the stuff to run 32 bit software?

This is asking for information on exactly what this is doing!

I want to fully understand what this is doing!!!

Tell me how this is any different from adding the 32bit compatibility SFS to a 64bit Puppy version?

If this is requiring the computer that is running the 32bit Puppy version, needing to have a CPU that is 64bit capable???.

If not. How is it getting around the need for a 64bit CPU to run 64bit software?

[mikeslr]

Yes, bigpup, you do need a computer capable of running a 64bit kernel. But how many computers do you think were manufactured in the last 20 years which couldn't. Once the 64bit architecture was economically possible it didn't make economic sense to manufacture computers with 32bit architecture. But it did make sense to sell 32-bit operating systems sitting on shelves and to sell 64bit operating systems at a premium. We've long been able to run 64-bit Linux on computers sold with the 32-bit Windows operating system.

And you need a kernel capable of supporting 64-bit applications.

We've also been able to run 32-bit applications on 64-bit Puppys using a compatibility SFS which provided the necessary frame-work (libraries and such), I don't know how peebee accomplished the opposite. But its long been a possibility as both debian and Ubutu have long been publishing multi-architectured operating systems. I think FatDog is; and I guess Slackware is also. EasyOS can run either 32-bit or 64-bit Puppys in a container; and Watchdog and MikeWalsh figured out how to do that in a chroot. Both containers and chroots require using an entire operating system: only the kernel, drivers and firmware are shared. Somehow peebee figure out how to do it while reducing the overhead and complete isolation those systems entail.

The Main operating system remains a 32-bit one. I've been able to install and run 32-bit applications. Like the other Mike, I have fun with this possibility. But I also think there's a practical aspect. The most useful windows programs are the many which were produced for XP and 32-bit Windows 7. Installation of Version2013's wine pets remains the easiest way to use them. And isn't steam a 32-bit application? 32-bit system, and the applications which run under them are still more ram efficient that 64-bit systems and their applications. But fully functional 32-bit Web-browsers are becoming scarce. Employment of the 64-bit SFS is not a panacea. But it is better than not being able to access most web-sites. And it will enable those who are otherwise happy with their 32-bit system to avoid, at least for now, having to replace it. Buying more RAM is still cheaper than buying a new computer.

Hopefully, as those of us who are technically inclined explore peebee's creation further we'll be able to solve the major flaw I mentioned. Only palemoon was able to upload attachments.

[peebee]

I've uploaded new versions of the .sfs with small tweaks.....

Here is small .pet to update the glib2 schemas for those pups with older versions:

[mikeslr]

Thanks, again peebee.

[mikeslr]

I'm posting from Brave64. The pet providing the glib-schema worked. But I'm not sure the new SFS does. While trying to upload the following attachment Brave crashed. I thought I had replaced the original SFS with the revised version. But maybe I got distracted while doing so. So installed the pet which enabled me to upload the following jpg.

I'll be back to explain what it shows. Have a couple things to do which are more pressing.

Wine-and-Brave64-2.jpg (27.29 KiB) Viewed 1553 times

But just in case I forget. Running Brave64 to post this, infranview under wine, and PupSys-Info simultaneously required 756 Mbs of RAM.

My earlier post on this thread suggested the possibility of simultaneously running applications under Wine while employing the 64-bit compatibility SFS to run 64-bit Web-browsers. Eventually, that reminded me that some time ago in order to run wine in a Chroot I had remastered xenialpup32 so that wine was included in its core/base sfs, puppy_xenialpup_7.5.sfs. So what I did was substitute the original version of puppy_xenialpup_7.5.sfs with my remastered version. Then booted it up, sfs-loaded the 64-bit compatibility SFS, started MikeWalsh’s Brave-portable64, started ifranview under wine, took a screenshot with xenialpup’s 32-bit Take-a-Shot, resized it with ifranview and uploaded it as an attachment to the post with Brave.

I’ll provide some more details about that on this thread, https://www.forum.puppylinux.com/viewtopic.php?t=7799

Regarding my mentioning being distracted above. Besides testing the above system it occurred to me that if the compatibility SFS was always to be used, it could be renamed adrv_YOUR_PUPPY.sfs or ydrv_YOUR_PUPPY.sfs so that at boot-up it would automatically be used. So I was also testing that change and may have picked the wrong version of the SFS to rename –and when it didn’t work-- SFS-load. I’ll re-download the latest version and test. But I’ve since decided that being able to SFS-(un)-load it is really better. Unloaded, ram requirements return to the original ‘only 32-bit’ condition.

All in all, peebee's 64bit-compat-s15pup32-22.12.sfs permits the building of a very versatile operating system in addition to extending the life of 32-bit Puppys. Thanks, again, peebee.

[mikeslr]

There is a functioning 32bit Compatibility SFS for VoidPup64, https://www.mediafire.com/file/9mc351ks ... 4.sfs/file. IIRC, I started with an SFS Duprate published, extracted the SFS and moved the libs so as to comply with the 'user-merge' Rule. I'll see if I can figure out why that didn't work when starting with peebee's sfs. I thought the moves would be identical: out of top-level /lib to either /usr/lib. /usr/local/lib or /root/my-applications/lib. But working from memory, maybe I didn't do it right.

The same moves should hold true for the 64-bit compat re-structuring.

[wiak]

There is a functioning 32bit Compatibility SFS for VoidPup64, https://www.mediafire.com/file/9mc351ks ... 4.sfs/file. IIRC, I started with an SFS Duprate published, extracted the SFS and moved the libs so as to comply with the 'user-merge' Rule. I'll see if I can figure out why that didn't work when starting with peebee's sfs. I thought the moves would be identical: out of top-level /lib to either /usr/lib. /usr/local/lib or /root/my-applications/lib. But working from memory, maybe I didn't do it right.

The same moves should hold true for the 64-bit compat re-structuring.

I haven't read this thread, but thought struck me that moving libs to /usr/lib often also needs making /lib a symlink to /usr/lib in case some utiliity expects the libs to remain at /lib.

[mikeslr]

...[quoting my previous post]...I haven't read this thread, but thought struck me that moving libs to /usr/lib often also needs making /lib a symlink to /usr/lib in case some utiliity expects the libs to remain at /lib.

AFAIK, you're right. That's what has always been done. It seems that unlike executables --where the OS will search for anything 'on the path'-- some executables will only find its dependent libraries if they are in a specific location unless re-directed by a symlink. But on one occasion I didn't provide a symbolic link; merely located the libraries in /root/my-applications/lib.

While you're thinking about that, read the questions I posed here, https://www.forum.puppylinux.com/viewto ... 146#p79146. You certainly will have a better idea about that circumstance than I.

The post was written just after I deconstructed void32 and vanilladpup32 to examine how they were handling libraries hoping that would provide a clue as to why Void can't use peebee's compatibility SFSes; and whether some structure could be used that would be universally acceptable. Unfortunately, I'll have to do that exploration again: forgot to Save my notes before rebooting.

[Duprate]

Currently using S15pup32 + 64bit-compat-s15pup32-22.12.sfs (https://sourceforge.net/projects/spup/f ... 32/addons/) as a preferred system. Always on the lookout for updates at (https://github.com/peabee/releases/releases).
It turns out that I had a better performance on the PC (mainly Windows XP programs via Wine), than directly using a 64bit system (better even than S15pup64)
Always using the 64bit kernel that you make available at: ( https://sourceforge.net/projects/lxpup/ ... /interims/ )

Thank you, Peebee!