Miscellaneous discussion (SetupS)

Did you try to install the ssApp by itself (without ssWPI)? Just double-click the ssApp.app file (only if SetupS is installed, of course) and see if it installs. This way you can at least determine if the ssApp works, and then try via ssWPI to see if that is where the issue emerges.

EDIT: Ah nice, the datacollection switch

 

Shame I can't try it right now; I normally always verify pp/ssApps work, so it's frustrating I can't test it right now Freezer may see something in the .app file that needs changing (like in Assembly). I was thinking about the instructions indicating the double quotation marks are important, and I was wondering if SetupS has issues with those.

 

Are you saying just installing SetupS caused it to put stuff in Recycle Bin? Or when you install VMWare?

 

That sure is odd, because that's the version of SetupS we've been using for a long time and over various OS's. Wonder what is going on there.

 

Okay, did a quick Last10 install (from my Last10-Ent-LTSC-x64_2021.09.26.iso) in VirtualBox VM (Win7 host). These are my findings:

1. Yes, the double quotation marks a) don't work; or, b) don't work in relation to the .app file. From what you said, VMWare probably put up wrong instructions
2. Removing the quotation marks around the serial makes the ssApp work as intended (as I made it, but minus the quote marks around serial). KeepInFolder works, multiple VMWare shortcuts inside the start menu folder. VMWare installs successfully and is licensed.
3. Setups latest (20.03.17.0) gets installed automatically with the Last10 iso in my case. It installing did not throw any system files or folders or shortcuts in Recycle Bin. Even when installing VMWare ssApp, nothing additional got thrown in the Bin.

So on my end this all works, even in VM (installing VMWare in VirtualBox VM, hehe). So the issues on your end don't appear to be related to the ssApp at all, but given that I can't see how SetupS would consistently act this strangely when just being installed...

Are you doing start menu sorting? Because if you apply sorting via SetupS Control Panel (or have ssWPI set to sort the start menu), that DOES place shortcuts and folder in Recycle Bin (but these can be retrieved when reverting to Standard sorting later on).

 

If we can replicate the test bed then freezer can trace for the bug, so your saying it's specific to v20 and v17 was fine? just need to be able to reproduce the issue and know if it's version specific, then it should be solvable, as for SetupS re-writing .app files, that is what it does. So it makes sense that it may change double quotes to single to replace path variables.

 

Regenerator also does a tidy up at the end, so it's possible that the cleanup routine has a glitch in the listing in file or maybe a different glitch all together.

 

Is that the one that if you right-click Properties will show this, right?

​

I'm not sure, though, that this works with the shortcut on the Startmenu; as I've always done this by right-clicking Properties on "This PC" (AKA "My Computer" previously) either from the one on the Desktop or the one in Explorer. Also "System" from the Control Panel.

Anyway, I was looking at the file, "MenuDefaults.ini", which contains the shortcut defs for the various default or "pack-in" startmenu shortcuts that comes with a fresh install of Windows and I noticed that none had actually been defined specifically for Windows 10 (or Windows 11 for that matter). Though I do reference Windows 10 in the file's header as a filter called ".WIN_10".

The shortcut-def for "Computer" ("This PC") has changed slightly over the years:

Code:

[computer.lnk.Win_2000.Win_XP.WIN_XPe.Win_2003]
Target=%windir%\explorer.exe
Arguments=shell:::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
WorkingDir=%windir%
Icon=%SystemRoot%\system32\SHELL32.dll
Index=-16
Description=See the disk drives and other hardware connected to your computer.
Default=%Programs%\Accessories\System Tools
Catalog=System Tool
Shortcut=Computer

[computer.lnk.WIN_VISTA.WIN_7]
Target=%windir%\explorer.exe
Arguments=shell:::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
WorkingDir=%windir%
Icon=%windir%\system32\imageres.dll
Index=109
Description=See the disk drives and other hardware connected to your computer.
Default=%Programs%\Accessories\System Tools
Catalog=System Tool
Shortcut=Computer

[computer.lnk.WIN_8]
Target=%windir%\explorer.exe
Arguments=shell:::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
WorkingDir=%windir%
Icon=%windir%\system32\imageres.dll
Index=109
Description=See the disk drives and other hardware connected to your computer.
Default=%Programs%\System Tools
Catalog=System Tool
Shortcut=Computer

As you can see, no filters for ".WIN_10" (nor "WIN_11", of course). So perhaps this why it is getting deleted during a startmenu sort (even a "Standard" sort).

FYI, if you can find your way to the "Change desktop icons" from Control Panel's Personalization and ticking the checkbox for "Computer" will restore it to the Desktop. And from there you can Pin it back to the Startmenu. (You can also "Pin to Start" from Explorer as well).

​

 

Apps like EZ CD Audio Converter that have x86 and x64 versions but that don't always get x86 cracks/patches made for them anymore are the reason some of the (mostly) ppApps at times get x64 versions only, etc. But then, sometimes, x86 cracks also surface again. So what I'm mostly doing now is retaining the _x64 / _x86 app folder method regardless, as well as keeping the dual-arch shortcut sections in the .app files, and then, for example, merely withholding the x86 versions of the app in the ppApp.7z file. This way, the structure of the apps can stay the same, and newer versions can overwrite existing installs. Right now, for EZ CD Audio Converter v9.5.3.1 there are dual-arch cracks (shfolder.dll method), but most of the time only the x64 cracks get made. So I try to make these to where you can install any version over the other one and the structure remain the same and the shortcuts viable.

 

The only thing that isn't perfect in my approach is the naming convention. This example, EZ CD Audio Converter ppApp, is not designated as "_Dual-Arch_" specifically; instead I'm just withholding any reference in the name to "x64" or "x86," which signifies dual-arch. However, it gets muddy when you do that, because many x86 apps can run on x64 OS (including EZ CD), and it would only be the x86-only apps (that won't run on x64 OS) that would get the "x86" designation in the name. To avoid this, the designation "Dual-Arch" would have to be present in the name. This would make many app's names longer, of course. So I'm not sure what is best. It remains muddy unless we designate as "Dual-Arch" (I notice Freeezer does do this and I'm sure for this very reason) but perhaps it's a tolerated type of mud Or should we just make "Dual-Arch" the official naming convention for dual-arch apps from now on?

EDIT: This would mean the following:

If any reference to architecture remains absent in the name, AND the "dual-arch" designation is absent, it means the app is x86 but can run on x86 and x64 OS. (And in the .app file this would mean the default Architecture "Any" would be used.)

EDIT2: I forgot to mention, I added PhotoZoom Pro v8.0.6 ppApp back to the repo, because I noticed that the 8.1.0 version only works on Win10/11, not Win7. This is only so because of the nature of the cracked .exe of v8.1.0 -- the original PhotoZoom .exe v8.1.0 does run on Win7. Hence I kept version 8.1.0 ppApp in but added "_NT10_" to the name, and re-upped 8.0.6.

 

I'm not sure but that may be the convention we'd already been adhering to all along...

DualArch-Installers and File-Naming Best Practices​

Also I think it has always been assumed that the "Any" Architecture was in fact actually an x86 (32-bit) as that would be the only type that would run on either a 32-bit or 64-bit OSArch. This is also the Type 2a mentioned in the DualArch reference, above -- though it still "installs" an "_x86" folder if it originated from a DualArch package. Of course a ppApp or ppGame can be still packaged as a non-DualArch (no "_x86" or "_x64" folders) with "Any" Architecture and the end result would still be transparent to the user.

Regular apps (and ssApps) do something similar folder-wise but use "Program Files" for 64-bit and "Program Files (x86)" for 32-bit. But that is also merely cosmetic as any of those in the "Program Files (x86)" folder will work just fine out of the "Program Files" one.

FYI, the "x86" Architecture flag was meant to be applied to those that only work on a 32-bit OSArch, though I don't think there has ever been such a beast.

We're seeing an uptick in x64-only apps probably because Windows 11 is strictly a 64-bit OSArch now. Though 32-bit apps will still work forever on them; they just aren't getting updated; presumably because it's assumed everyone is on a x64 machine by now -- or should better be.

-- EDIT: Fixed the reference links above.

 

Only if it contains both x86/x64 packages. The "Any" Architecture (x86) package gets no special filename tag (such as "x64" or "DualArch") because there was no real need for one; think of them as acting like filters -- for both human and machine, if you will.

 

You're right, DualArch (not Dual-Arch as I spelled it) was recommended by you to be used in the app's name. What I meant was that I had not been following that naming convention (I think: ever) and was wondering if it made any sense to start doing it now

I stand corrected on the "Any" portion of my comment, there is indeed a specific DualArch option available. However, that option kind of puzzles me right now. If I indicate DualArch in the app file, and I install a DualArch ppApp, it installs both _x86 and _x64 folders (rather than follow the OS architecture as to which one to choose). I can't really imagine a purpose for installing both architectures, though. And then the shortcuts would have to be distinguished as well. For example, a DualArch BurnAware ppApp: it will install both _x64 and _x86 folders, and unless I indicate the architecture in the shortcuts as well ("BurnAware Pro x64" and "BurnAware Pro x86", for example -- or not x86 if the x86 version runs on x64 OS as well) only one shortcut gets created -- in this case, only the shortcut to the x64 version (when on x64 OS).

So is then the DualArch designation in the .app file only to force the install of both x64 and x86 versions of an app, however unlikely the scenario one would even use/want to install both architectures? EDIT: And would not then having "DualArch" in the name, but not having the DualArch designation in the .app file, be confusing?

 

LOL, I was working on MediaHuman YouTube Downloader/MP3 Converter ppApps, and encountered another exception to my own proposed new rule So, with these particular apps, since they started making x64 versions, almost never have cracks come out for both architectures of the app, and 95% the cracks have been for x64 versions. Which is why, whenever the x64 versions came out, I just made x64 versions without the _x64/_x86 internal folders as I don't think I ever made a combo versions (due to cracks for x86 not being there). So in the case of these apps, I'd have to now start using the _x64 folder method inside the ppApp.7z archive whereas I had never done that before. This, combined with mentioning "DualArch" in the name of an app, whilst not using the DualArch designation in the .app file (forced dual-arch install), just makes me think I'll continue as I had been I may be overlooking something, but as I see it now, I'd solve a few problems and create some others -- which is pretty much where I am already.

Note: technically, MP3 Converter is free, but they do make "cracked" .exe's for this, which I believe is just the .exe with any telemetry/feedback/etc sections cut out. So of the official version, one could make a dual-arch ppApp of that particular app.