Repository Applications Update Information

CCleaner was reverted to v5.44 by Avast because with v5.45 they introduced a change in telemetry gathering and people revolted. CCleaner would keep running in Task Manager when exited and I had a hard time tweaking it to stay off (I think I eventually managed).

 

Recently someone made a fork of the Classic Shell source code and named it "Classic Start." I think there was some sort of naming conflict with another app or something, as the app is now named "Open-Shell." I just upped the latest version and had to change app path, reg entries, etc., and finally got it to work. I included a collection of start buttons and skins, and for some OS's have set a start button but it would normally require an explorer restart to become effective. Open-Shell_v4.4.131_ssApp.apz

 

Actually, it looks like they had renamed it to "NeoClassic-UI" briefly before ultimately(?) naming it "Open-Shell"

(https://github.com/passionate-coder/Classic-Start)

 

Yes, there used to be an option for ssWPI to check for new apps but that is currently defunct. I personally don't know all the details regarding that project as I personally didn't use it, but Glenn and others could tell you more about it.

ssWPI was and is, I think, most often used in conjunction with new installs, as parts of an automated install image (LastOS builds). There is the AppDisc template on here that is geared toward live usage and which is centered around ssWPI; it allows you to make an .iso with the pp/ssApps of your choice. I think at the time there was talk of having a server compile .iso's with apps of your choice, so you would be able to download an updated AppDisc that includes apps of your choice (rather than downloading apps piecemeal).

Yes, I think a small group of people uses the SetupS app system. The number probably increases around the time any LastOS-based images get released at other places, since ssWPI and other tools are part of those images and have info about/links to this forum.

There are always pros and cons regarding the various methods of silent/automated app installs and the various portable formats. I've tried most of them and personally prefer the SetupS app system. As always with these type of tools, it is best if you learn how to use them and create apps, images, etc., because it was designed more to empower people than it was to provide download links to ready-made stuff. That said, I think here we usually share any apps we do make, so if that works out for you at any given time, then great. ssApps are much like your regular silent installers, although they do include some extras like icons, pngs, screeshots of the app (to be used in ssWPI and to give app icons to your app path folders, etc.).

ppApps are kind of a different animal than any other type of app out there: they aren't true portables (unless true portables are used for the making of a ppApp, which is possible) in that they're basically packed program files that may or may not write data to other locations such as programdata, appdata, registry, etc., depending on the app itself. This is why it is best to always have all or most runtimes installed because ppApps might require these to function (some true portable apps might include the runtimes). We do pack, for example, Visual C++ runtime .dll's into the ppApps at times but not always. You can also install ppApps to other drives/partitions (say, on D:\) with the benefit that when you need to reinstall your OS (say, on C:\) and after that run SetupS' regen function, it will scan the previously installed ppApps (in this case, on D:\) and automatically "install" them for you new OS install on C:\ to use (including shortcuts, tweaks, any required programdata/appdata, etc., files). By default, SetupS will install ppApps on C:\ but you can set them to install on another drive which would allow you to use the above-mentioned regen, making it so that ppApps are therefore kind of independent from your OS install. ppApps also usually allow greater control over the way an app is installed than regular (and/or automated) installers.

 

I mostly no longer use Search Everything and instead use WizFile as it is MUCH faster for NTFS disk searching and doesn't bog down the system if you have a disk with millions of files Like everything does. Everything will even slow down mass file copies so I used to disable it for them jobs and re-enable/scan when I was done. WizFile is much easier on HDD access.

I gave up on the online repository system due to the hosting at that time shutting down our server twice in a row. I could use the existing php method to generate a download list that you can save from using a local app, but I've sort of stopped everything PC related, it would be easier to just give you FTP access as the requests for such access is not common @TheFreezerBox, do we still have a guest FTP we can share with dedicated members?

Due to issues with Windows 10 some of the old solutions for system integration were removed, if you require such features it is actually best to manually install them - or you can master how to make ssApps and just add the required setup switches to make it do what you desire You can make almost everything you want to happen happen with SetupS or by using a script called from it, even powershell scripts can be called with it.

 

Try this: Everything.(Search)_v1.4.1.895_ssApp.apz

It's tweaked to show context menus and I turned off automatic update checks (both via installer switches).

----

I downloaded the regular installer for WizFile as well, but it does not include an option for the creation of context menus. It is possible to make a reg tweak to create such context menus (even for ppApp versions) but the issue with this is that the program itself can not undo the context menu, then. So if you uninstall/remove the program, the empty context menu will remain and you'd have to manually delete the entry in the registry.

It would be possible to include 2 .reg files inside, say, the ppApp program folder, which would allow you to add and/or remove the context menu entries by double-clicking them.

----

I was playing with IrfanView ssApps just now. There is something odd about its installers and how they create shortcuts in that SetupS is having trouble detecting them automatically, but I think I just made some headway when I manually entered the shortcuts into the .app file. Since there are both the program installers and the plugin installers, I think I'll post them as separate x64 and x86 versions because otherwise things get too complicated and prone to error. Since the 32-bit version can also be installed on x64 systems, the 32-bit-based ssApp will, as usual, not indicate architecture in its name. So we'd have: IrfanView_v4.51.+.Plugins_ssApp for the 32-bit version (can be installed on x64 systems as well); and IrfanView_v4.51.+.Plugins_x64_ssApp (for installing on x64 systems only). [You probably know this already but that is how we normally deal with 32-bit installers than can also be installed on 64-bit systems; we only indicate "x86" in the app's name (and .app file) if the app is truly x86-only, in that it can't be installed on x64 OS.]

I did notice that the IrfanView installer's default behavior does NOT associate the program with the various image files. If you manually install you'll see that the file association boxes are not checked in the setup options before install. I checked their website and they don't appear to offer switches for automatic file association. So any file association would have to be set by you manually, after install. Also, context menu are not created by default. "Send to" was enabled after the ssApp installed, but not context menus. When you install from the original installers manually, context menus are not enabled by default, either; no switches for that, either. So ssApps are possible, but I'm not sure if there are any benefits to them over the ppApp version.

I'll edit this post once I have the 2 installers upped.

 

No, nothing yet. I'll look into making a basic read-only account for the repo. Such a thing would be useful with WinSCP & wget though I think wget can retrieve files without FTP access as well -- it can use HTTP -- as can WinHTTrack which we do have a ppApp for (http://repo.lastos.org/WinHTTrack_v3.49-2_ppApp.apz). WinHTTrack has a GUI whereas the other two are more suited for batch/script files.

A couple years ago I was surprisingly successful with incorporating into ssGooey that ability to read from an online directory the title/descriptions (even the screen-shots) which could then download/install batches of selected ssApps & ppApps (and ppGames). But I sort of put that on a back-burner because of all the various hosting issues at the time -- as Glenn has mentioned. Though except for a few glitches with Cloudflare, it all seems pretty stable these days; so I might take the dust-cover off that old project again.

 

Yeah, but since IV doesn't offer install switches for association nor for context menu, the installer version probably has few, if any, benefits over the ppApp version. With the x64 plugin installer being 25mb and the x86 version only 16mb, I doubt there are many, if any, more plugins for x86 than there are for x64 because that size difference looks like more than architecture-related only. I'm upping them right now so they should be in the repo by the time you read this.

You're welcome. But that's why I made Everything ssApp, so that you don't have to manually install next time

 

Actually was working on that too in conjunction with ssGooey as both projects required the same backend code.

 

Unfortunately, as you'll find out, it's mostly broken at the stage I left it. But I do know the concepts and everything would work just fine if I ever completed it.

 

Changed the naming of the Visual Runtime AIO installers because the old naming had been bugging me. Now, the previously named 'lite' version is called simply 'AIO' and the more elaborate version if now called 'AIO.Plus' to indicate it has additional stuff. Still not perfect but I feel better about it. So the naming is now as follows:

MS.Visual.Runtimes.AIO_2018.11.12_ssApp
MS.Visual.Runtimes.AIO.Plus_2018.11.12_ssApp

The regular AIO version has the VC runtimes from 2005-2017 and a collection of older runtimes (extra.exe) included as installer. This is what most people would want.

The AIO Plus ssApp has all that, plus VSTOR ('Visual Studio 2010 for Office Runtime') and F# and J# runtimes.

 

Kind of reconfigured the ppApp forms of some portable browsers: Firefox, Google Chrome, and SRWare Iron (so far). I made them dual-arch now, so both architectures are now included in the ppApp, and it will install the browser architecture that corresponds with the architecture of your OS (so Firefox 64-bit gets installed on 64-bit Windows, etc.).

We already have Opera ssApp as dual-arch (thanks to Freezer) and I had been updating it that way, but other browser pp/ssApps are not all consolidated into dual-arch yet. At the time I held off in case people use certain extensions that won't work on 64-bit browsers and stuff, but I think most people who are on 64-bit OS have moved on to 64-bit browsers now.

So my question is: should we just go ahead and make all browser packages be dual-arch? I could consolidate Firefox, Chrome ssApps this way too if desired. That way we can just assume any browser package will be dual-arch, unless otherwise stated in the title or here. The thing to keep in mind of course the fact that a x86 version of any app that will also run on x64 systems would have no architecture indicator in the title, and in that sense the titles of these would be identical to dual-arch apps. In the case of browser you can pretty much bet that any pp/ssApp that is significantly larger than ~50mb would be dual-arch. So unless anyone has any objections I think we could go ahead and just make all browser packages dual-arch?

EDIT: made Opera Portable dual-arch ppApp also.

EDIT2: forgot to mention what started all this for me Thunderbird ssApp and ppApp I upped the other day are both dual-arch too now.

 

Sounds good. I'm assuming the ppApps are of the Type 2a variety (like the ssApps DualArch-Installers)?

 

Yes, they are. In fact, the shortcuts for these have architecture-specific naming so for example: "Firefox Portable x64". I initially did this to differentiate in case you would install a 32-bit version of the ppApp as well (so shortcuts wouldn't get overwritten) but I kept it that way in these dual-arch ones as well (with just "Firefox Portable" for x86 OS).

Well I got Google Chrome and Firefox made into dual-arch ssApps too just now, so I'll delete the arch specific versions from the repo and upload them.

EDIT:

So these are the ppApps and ssApps from now on dual-arch (Opera ssApp already was):

ppApps:
Firefox.Portable_v63.0.3_ppApp
Google.Chrome.Portable_v71.0.3578.80_ppApp
Opera.Portable_v57.0.3098.76_ppApp
SRWare.Iron.Portable_v70.0.3650.1_ppApp
Thunderbird.Portable_v60.3.2_ppApp

ssApps:
Firefox_v63.0.3_ssApp
Google.Chrome_v71.0.3578.80_ssApp
Opera_v57.0.3098.76_ssApp
SRWare.Iron_v70.0.3650.1_ssApp*
Thunderbird_v60.3.2_ssApp

*Also added SRWare Iron (dual-arch) ssApp as we didn't have an ssApp for this at all yet. These installers by default have a flash installer included which I disabled through switches. They further utilize custom names for 64- and 32-bit shortcuts, program files locations, but it looks like SetupS handles it well without extra guidance so I think these are OK. This way we have a SRWare Iron ssApp template as well.

 

Re-upped the HDCleaner and TweakPower ppApps: had to add in an exclusion for Open Shell (start menu) so that they won't remove references to it, making it not load. The apps were wise enough to not remove the Notepad2-mod reg entries as some do. (For example, Wise apps do this: Wise Registry Cleaner, Wise Care, which is made exclusions for protecting Notepad-mod associations.)

HDCleaner, TweakPower, and RegCool are all made by the same programmer; these are pretty cool apps with broad functionality. https://kurtzimmermann.com/index_e.html

 

Re-upped Autoruns, it went to v13.93 some days ago and its download page was updated but the .zip itself in the dl link was still the .91 version: fixed.

 

VirtualBox v6.0.0, major update: https://www.virtualbox.org/wiki/Changelog-6.0

LibreOffice Portable ppApp now dual-arch as well.

 

Google Chrome ssApp re-upped. Apparently they did a silent update on the same version no. as the hashes of the .msi's are different but the old x64 one would not install. So if you noticed anything, that's probably it. Fixed.

 

I have added the do not wake PC for updates and the passwords never expire to the Last10 Tweaks, also updated the hosts and Autoruns while at it