OK, as I understand it, based on a combination of the above suggestions, this is what we're agreeing on: MKVToolNix_v65.0.0_x64_ssApp.apz (x64 "Type 1" ssApp that only runs on an x64 OSArch) MKVToolNix_v65.0.0_x86_ssApp.apz (x86 "Type 1" ssApp that only runs on an x86 OSArch) MKVToolNix_v65.0.0_ssApp.apz (x86 "Type 1" ssApp that runs on either an x64 or x86 OSArch) MKVToolNix_v65.0.0_x64+x86_ssApp.apz ("Type 2a" ssApp that only installs the OSArch version) and: MKVToolNix_v65.0.0_x64_ppApp.apz (x64 "Type 1" ppApp that only runs on an x64 OSArch) MKVToolNix_v65.0.0_x86_ppApp.apz (x86 "Type 1" ppApp that only runs on an x86 OSArch) MKVToolNix_v65.0.0_ppApp.apz (x86 "Type 1" ppApp that runs on either an x64 or x86 OSArch) MKVToolNix_v65.0.0_x64+x86_ppApp.apz ("Type 2a" ppApp that only installs the OSArch version using the DualArch-ish structures of a "Type 2b") MKVToolNix_v65.0.0_DualArch_ppApp.apz ("Type 2b" ppApp installs both OS versions but only installs the OSArch shortcuts) ALL ppApps, of which both x64 and x86 versions exist, including x64 "Type 1" ppApps, x86 "Type 1" ppApps, "Type 2a" ppApps, and "Type 2b" ppApps, should ALL be constructed as @Trouba suggests above, in the DualArch-ish structure of "Type 2b" ppApps using _x64 and/or _x86 folders, to make updates cleaner, minimizing the possibility of multiple instances ending up in both the ppApp root and the ppApp _x64/_x86 folders after an update. Also, if a DualArch version is ever made, if it doesn't already exist, the structure will already be there. If the above is an accurate representation, then that all sounds good to me. If I have misunderstood anything, please post corrections, or post alternate suggestions if you disagree with anything.
Yes, very good summary, BP. Succinct and accurate. It's funny though. You beat me to it about the Type 1 ppApps also using the SetupS DualArch type of structures: Though I was going to ask Trouba first if that's what he meant as he had never actually referenced Type 1 ppApps specifically. I had thought he'd meant only Type 2a; but then after his most recent post about it yesterday, it finally kind of clicked for me, "I wonder if that's what he was getting at?" LOL @Trouba, I was also going to ask if you have any templates or models you use to construct those ppApps? I had always started from scratch and making those DualArch type of shortcuts can be somewhat frustrating especially if you're like me and build apps only every once in a while ...
Yes. From the start of this discussion: So with this app as an example, under the shortcut section it has: Code: [EZ CD Audio Converter {#1}.lnk] Target=_x64\ezcd.exe StartIn=_x64 Flags=Is_x64 Comment=Rip audio CDs, convert audio files from one format to another, edit metadata of audio files, and burn CDs & DVDs. [EZ CD Audio Converter {#2}.lnk] Target=_x86\ezcd.exe StartIn=_x86 Flags=Is_x86 Comment=Rip audio CDs, convert audio files from one format to another, edit metadata of audio files, and burn CDs & DVDs. When, for example, I want to make a x64-only version of this ppApp (a x86 patch may not be available, etc.), I keep this structure intact in the ppApp.app file & I keep the "_x64" and "_x86" folders structure intact in the ppApp.7z (which is to say, I only provide the "_x64" folder in this example, but you could leave an empty "_x86" folder in there also if desired which could then be populated in a later x64+x86 version without having to create the _x86 folder, etc.). The ppApp.reg also makes use of dual-arch gated directives, which I also leave intact in said ppApp.reg file, whether I'm making a x64+x86, x64, or x86_64 (but the latter being unnamed/having no arch specified, meaning x86 version that runs on x64 OS as well) versions. In this case: Code: [HKEY_CURRENT_USER\Software\Poikosoft\EZ CD Audio Converter] #Is_x64# "path64"="%ppApps%\\EZ.CD.Audio.Converter\\_x64\\" #Is_x86# "path"="%ppApps%\\EZ.CD.Audio.Converter\\_x86\\" And this of course also goes for any dual-arch specific information in ppApp.cmd files, etc. This way, all the information regarding shortcut architectures, use of arch-specific gated directives, internal folder structure remain intact and available, whatever application that is available in 2 architectures you intend to make into a x64+x86, x64, or unspecified (x86_64) ppApp. Another benefit of which being that if you have a dual-arch 2a ppApp that includes both architectures (x64+x86), you can convert it into DualArch 2b with one click. So then it's all win-win. No information lost, but deployable in any of the above-mentioned fashions.
To note, some apps in the repos will have this method deployed by me already, but some will not. It was an unwritten rule I was trying to live by because it made sense to me, but that doesn't mean I utilized it in every case. For example, I made some x86 versions of EZ CD Audio in the past that did not have the internal folder structure _x64 and/or _x86, etc. So although the repos have apps like I'm proposing, it isn't exclusively so. Just a FYI, that not all ppApps that occur in 2 archs actually have this method included in the current repos. But that is the idea, to do it this way going forward. It should be easy enough, as there are already apps that can be used as templates, and just build from there. The way I personally do this, of course, is by recycling pertinent ppApp.app/.cmd/.reg files as I build the apps "manually". Fortunately, SetupS does not "intelligently" change the dual-arch structure of ppApp.app/.cmd/.reg files when saving and leaves all the info intact, whether you're making a "x64", "x64+x86", or undesignated (x86_64) version based on such a template.
Remember that "_x64+x86" will be the new naming identifier for all "Type 2a" Apps, if everyone agrees, combining your preference of _x64 before __x86 and Freezer's suggestion of using '+' instead of '-'. As to "_x86_64", were you just using that as a shortcut way to refer to them, or are you proposing using that instead of having no architecture designated as we are currently doing? If you are, then that seems to be the last thing we need to "vote" on. I would be OK either way, but I prefer the no architecture designated marking. I know they are different, but I would be more likely to confuse the "_x86_64" and "_x64+x86" at first glance, vs "_x64+x86" and "".
Yes, x64+x86 it is I'll go ahead and edit my above posts to avoid confusion. And yes, I was just saying "x86_64" to indicate "unnamed" or rather "unspecified" (having no arch indicator in the name of the pp/sssApp); in other words, a x86 app that runs on x64 as well. I am not proposing the use of "x86_64" in the name, no
For an example of a more tricked out version of a dual-arch 2a ppApp (x64+x86) with internal folders (and sub-folders) and multiple respective shortcuts, check out Macrorit.Disk.Suite.Technician_v2021.12.09_ppApp.
While we are settling on file naming conventions we want to use... It looks like we've now all agreed on what we will use regarding OS architecture. But what about OS version? Glenn began this discussion last October. I figure if we're going to implement any changes and, hopefully, eventually make the repos consistent with those changes, we might as well finalize what we need to do about OS version and do it all at the same time, rather than have to go through it all again later. Please review the page or two of discussion that began with Glenn's above post and let's begin this discussion again. TIA
The only issue there is that _Win11_ is synonymous with _x64_ now But we should probably still do "_v1.0_x64_Win11_ppApp" or something. PS: I'd like it if we could leave off the underscore after "Win" -- so Win11 rather than Win_11. PS2: Also, in what order: "...v1.0_x64_Win10-11_ppApp" or "...v1.0_Win10-11_x64_ppApp" ? I prefer the former (arch first, then Win version).
I was also thinking about Apps that no longer are supposed to work on Win7. I say supposed to for apps such as Calibre, where the latest versions are officially only approved to work on Win8+, but works fine for me in Win7.
Qbittorrent v4.4.x series is expected to be the last one that supports Qt5 and therefore Windows 7 and 8. Sometime after the summer of 2022. Worse the v5 series will be based on Qt6 and will be Windows 10+ (64-bit only). Confusing because Microsoft still offered an x86 (32-bit) OS with Windows 10. So these will need to be marked both as Architecture x64 (64-bit) only *AND* as OS NT10 only which currently includes Windows 11. This kind of sucks because I only recently discovered and implemented the really cool portable mode for it (qBittorrent). This had finally fixed the problem of updating the client and preserving its current settings and data which previously I had never quite got a satisfactory solution for. I had even briefly played with symbolic links to some moderate success. ::sigh::
Yep, some apps I use a lot like Topaz DeNoise and Gigapixel are seeing the same thing, a move to Qt6. When they moved to Qt6 some weeks ago, they quit working on Win7. Photoshop's CameraRaw plugin only works up to version 13.0 on Win7, all subsequent versions no longer work on Win7 (it's up to v14.2 now). Photoshop 2019 works best for me, on either Win7 or Win10-11, in part because later versions of Photoshop no longer recognize my older graphics cards and so I lose the enhanced features. Sidenote: I found out when running PS 2019 on Win11, I can add in the latest CameraRaw plugin 14.2 to it and it work inside PS 2019 (this won't work in Win7).
When we were discussing this last Oct/Nov, I think we agreed that the SetupS is already able to handle OS version correctly using the various gates. But I thought the original purpose of the discussion was more about enhancing the Filename so that it would be obvious to the user, looking in the repo, which OS the apps were meant for, without requiring them to download the app, open the app, and look in the .app or .ppg file to see if it applies to his OS or not. Had we agreed how we need to do that and I just didn't notice? LOL
Are you feeling ignored despite your contributions, bphlpt? You need to toughen up. Imagine actually making the apps, or whole OS's and not getting a beep. You got it good
Not at all T, just trying to get the conversation back on track. But I'll take your advice and wait patiently.
I don't think anything is particularly required of SetupS at this point, but if there is a change to it that's cool. ssWPI can filter via OS names which that is up to Glenn. Otherwise, I think most people see the logic of my proposals and I will be implementing them myself, but I don't expect anyone else to do this (especially if they use (current) SetupS/editor itself to make apps and would then have to rely on it to do the naming; since I have more control as I do them manually, it's not issue for me). I just appreciate knowing myself what's in an app package and making it easier/better to install over older apps as the structures will be the same (internal folders for ppApps). I think the only thing that has changed from my proposal is x64+x86 instead of x64-x86 and I'm fine with that -- thanks for the input
I agree. Renaming the .apz files does not affect SetupS. So it can be anything or as creative as we want. Especially to distinguish what's in its manifest (and hence what type of package it is). I can't speak for ssWPI but it might also rely on the Architecture and OS flags for its filtering though (I don't remember exactly). I also find it agreeable (and aesthetically pleasing) using "x64+x86" as a filename tag for Type 2a packages (both ssApps and ppApps). I was also considering an "_x86-Only" filename tag for those apps that only work on an x86 OSArch. Honestly, until Trouba pointed out examples of such x86-only apps, I never knew they even existed. So we'll have to keep that Architecture flag/filter after all. Speaking of, I've run some tests with an <Architecture> of "4 (x64+x86)" for a Type 2a package on the current release of SetupS and found that it interprets it as "0" (or omitted) "Any" which fortunately for us is also a Type 2a. So the potential problem of making a fundamental change like that to the SetupS Spec is rendered moot. Totally serendipitous it turned out that way. LOL So far this has only been about manually renaming the .apz file. Later I'll change ssEditor in a future update to facilitate these refinements in filenames, including adding "Architecture=4 (x64+x86)" for distinguishing x86 Type 1 packages from Type 2a ones. A work in progress, but I'm thinking of the Architecture box looking something like this: o x86 (Either Arch) o x86-only o x64-only o x64 and x86 (DualArch) o x64 or x86 (Single-Arch)
Would not _x86_ take care of that already? Or were you saying that _x86_ may not be clear enough, in that people might assume it's a x86 app that might run on x64 OS?
Yeah, that. A possible ambiguity to get rid of, I guess. Even though the "_x86" tag was hardly ever used, SetupS won't install such to an x64 OSArch; so it could be confusing.
Strictly speaking, though, _x64_ means _x64-Only_ as well. And to then not use it for x64, but only for x86, may be confusing in itself.
Trouba's point regarding consistency is very appropriate. So if I understand you, Freezer, instead of the current naming structure _x86 _x64 you would prefer _x86-Only _x64-Only is that correct? And then I assume instead of (nothing) you would probably prefer _x86, or what? That would be fine, or any combination of the various options, but frankly I would prefer keeping things the other way, with fewer changes to what the existing Apps are named. But as long as we know what the names mean I'm sure we can adapt.
Well, I didn't think there would be any ambiguity that an x64 app or game could actually run on an x86 (32-bit) OSArch... But in ssEditor Architecture options that is probably redundant to list it as "x64-only" LOL
If we do _x86-Only, does that mean we need to do _x86-Not-Only as well (to indicate 32-bit apps that run on 64-bit OS)? Because ___ (nothing) sure is a very short way of describing x86-that-also-runs-on-x64
