Miscellaneous discussion (SetupS)

I wouldn't worry too much about it. Those filename "best practices" are just that: suggestions or recommendations not really any kind of rule or policy. But they are implemented in ssEditor, FYI, so one doesn't have to give it that much consideration.

Type 2a ("Any") installs only the folder (ether _x86 or _x64) corresponding to the target OSArch. Type 2b ("DualArch") installs both regardless of the target OSArch; but it'll only create the shortcuts meant for the target OSArch (as does Type 2a). And since they only generate the shortcuts for the target OSArch (hence the ones from the opposing OSArch are omitted), no renaming of shortcuts is necessary. Just think of how ssApps install and create shortcuts when they have both x86/x64 versions available in their installer packages. The similarity of which isn't lost on Type 2a ppApp packages and so didn't get an extra filename tag. (See next paragraph).

Well, both Type 2a & 2b are constructed exactly the same way -- they only differ in their Architecture flag: "Any" (for Type 2a) or "DualArch" (for Type 2b). And we needed a way to distinguish one from the other, as they both couldn't have the same filename, after all. Since "DualArch" was the oddball less conventional one (and still is!), it was decided that that one would be stuck with the extra moniker.

Indeed, the Type 2b "DualArch" option is exclusive to ppApps/ppGames. These work especially well for those who place ppApps on a separate drive or partition from their OS one. One can then swap out (or reinstall, or rebuild, etc.) their OSArch between a 32-bit one and a 64-bit one; and the ppApps (the DualArch ones, anyway) will be ready to go -- no need to reinstall those; just needing their shortcuts to be recreated.

Testers, Modders, and Multi-Booters preferred doing it that way, I suppose. Especially in the early days of x64 when those machines rarer (and more expensive). Plus, back then there was more instability and issues with x64. And x86, in addition to being more plentiful (and less expensive), were considered more reliable (both in hardware and software).

Now with Win11 being strictly x64, it seems x86 is on its way out. On the same machine x64 is slightly faster than x86 with both the OS and with Apps/Games. Even though the x86 OSArch version uses twice as many "CPU's" as its x64 counterpart, there's still overhead. And a x64 OSArch still has to emulate a 32-bit machine for any x86 Apps/Games -- granted a slight hit; but a hit nevertheless.

So it all depends on one's needs I guess.

 

I'd like reiterate. If it's not marked "DualArch" in the .app file it should not have -- and if using ssEditor, it won't have -- the "DualArch" tag in the filename of the app.

Plus, it doesn't have to be that complicated unless you really want it to be.

If it's an x64 dedicated app, no need to go the extra hurdles of a DualArch construction. Just make it as you would an ordinary ppApp and simply flag the Architecture as "x64".

Either way, it'll work just fine for us users.

 

I don't suppose there is. Even finding an actual 32-bit machine, one that still works, is rare these days.

But before Windows 11, one could still install a 32-bit OS on their x64 machine -- and of course many did exactly that for whatever their reasons were. And because there were those that chose that option, developers would have to create x86 counterparts as well. Now that Microsoft has taken that option away with Windows 11, developers are off the hook to continue to support x86 apps (and games).

You know. The Path of Least Resistance.

 

Let the x86 stuff fade into the oblivion, we should perhaps move all apps to a section for each and if anyone ever chooses the 32bit only path, they can. As for x64 naming, this can be removed if we make the server structure and local copies change. Why name a file when you will almost never need both the x86 and x64 versions for the same projects. AIO is not useful anymore.

These are all my opinions, but it's how I'd do it. Obsoletion is part of the software way. if someone is still using the old, then they would rarely reinstall a fresh system, they'd simply capture and image and restore that fresh.

 

I have kept vigil for 32-bit systems for a long time, especially since I know a few people who still use it. But, like Glenn said, they don't reinstall hardly ever, and one of them only restores -- despite me having made several up-to-date images for WIn7 32-bit for them!

LOL, when I just tried to type 32-bit but the fingers of my left hand hit the row of keys below and it spelled ew-bit -- which I think nicely sums up the sentiment in this thread

I think pretty much all app makers that produce either office suites or graphics, video, and audio apps have 64-bit options, if not having moved over to 64-bit exclusively already. (For example: for office suites this was mainly due to spreadsheet's enhanced capabilities under 64-bit.)

@The Freezer: Ah yes, I had not considered the dual-boot (x64/x86) scenario for ppApps/Games and the DualArch function. This piece has now fallen into place with a distinct CLICK sound


@Glenn: If I understand you correctly you are proposing to:

1) make a repo with apps that are assumed to be 64-bit (if available) -- it has no arch mentioned in the name (but has x64 indicated in .app file for ssWPI?)
2) then, if an app is 32-bit but runs on 64-bit OS (and there is no 64-bit version of the app), it has no arch mentioned in the name (so looking at the app name there is no way to distinguish whether the app is 64-bit or 32-bit) (it has "Any" architecture indicated in the .app file)
3) no more AIO's, including VC Runtimes, Browsers, Office Suites (SoftMaker for example), no more ss/ppApp.reg files adjusted with gated directives for x64 and x86, etc.
4) no more _x64 and _x86 internal folders for ppApps. no more maintenance of .app files for dual-arch shortcut creation. no more "Any" unless an app is only made in 32-bit (that also runs on 64-bit OS)

Just making sure we understand all the implications here

The more I think about this, a voice in the back of my head keeps saying: "as you were" LOL However, I would appreciate not having to include 32-bit versions of apps like browsers, etc.

One point of view worth considering is with those type of changes, we lose a lot of information (naming, dual-arch structures (folders, gated directives for arch, dual shortcuts, etc.). None of this adds anything in size. What we gain is dropping things Where it comes to app sizes and extra work, we get to drop 32-bit apps like versions of browsers.

 

As for Win11's move to 64-bit-only: I don't think this stimulates the end of making 32-bit-only apps, since those that are still made that way are made for specific use/systems. Since Windows will continue to run 32-bit apps (that aren't 32-bit-only), I don't see the app makers are being specifically stimulated to make 64-bit apps either, which is why many apps that don't require a lot of system resources are still 32-bit.

Example: MP3Tag; it's a 32-bit app that runs on 64-bit OS. It does not use system resources heavily, so if they add a x64 version it would only be to appease users (and I doubt that would happen any time soon). So an app maker like that is presented with the following: "I now make a 32-bit app that runs on 32-bit and 64-bit OS. If I make an additional 64-bit version, I add to my work. If I make a 64-bit version to replace the x86 versions, I lose support for x86 OS. There is indication 32-bit will not run on Windows any time soon. Hence, no change." This makes sense to me.

So if we make a x64-only version of Firefox ssApp or ppApp, and we don't indicate _x64_ in the name, and yet the size is about the same as a x86 version would be, we'd only have the *location* of where the .apz is located to make assumptions as to its architecture. Like I said above, we only lose information in that scenario. ssWPI, if used, would have some useful sorting there (to just not show the x64 apps when installing on 32-bit OS, etc.).

So, some changes seem arbitrary. Which in itself could be an argument for keeping things as they currently are, as the historical method is itself replete with arbitrariness -- but an arbitrariness we're used to and are already informed by

 

Not being an appmaker like you guys, take this with a big grain of salt, but overall it seems like leaving things the way they are is less work, less confusing (if possible), with (a few) benefits, and not much detriment. So overall, a win. To me, if we were starting from scratch today, then scrapping x86 would make a whole lot more sense. But then, I am a "if it ain't broke..." kind of guy.

 

Perhaps we should *at this juncture* approach it this way:

- Is there anything particularly wrong with retaining the _x64/_x86 folder structure inside ppApp.7z (for apps that already have this in place), and/or the dual-arch shortcut structure being present in the .app file? I say: no.
- Is there any particular thing gained by taking out "_x64_" from the app name? Or taking out dual-arch shortcut entries in relevant and/or already-made dual-arch apps? I say: no.

When retaining the _x64/_x86 folder structure (for the apps that already have that, or for which dual-arch versions are available, etc.) we could just leave off the x86 versions for apps we don't want to provide dual-arch versions anymore (extra work, extra size, etc.) and thus adding _x64_ to the name. Yes, this is what I had already been doing with certain apps, especially cracked/underwarez ones as those are dependent on available cracks for 2 architectures, as mentioned above somewhere.

To me it was more about: is it worth making changes at this point? Had I known the exact purpose of "DualArch" at the time (as pertaining to 2b only and exactly what all that entails), I probably wouldn't even have brought it up

The other reason I brought it up was because I was seeking a way to distinguish when I, for example, made an warez ppApp that only has a x86 crack. Ift the x86 version of that app runs on x64 OS, if I made only the x86 version, there would be no _x86_ or _x64_ in the name, and so from the name you wouldn't be able to distinguish whether it was a dual-arch ppApp (not "DualArch" or 2b) or x86 version of the app. Again, there seem to be no good way to cover all those scenarios in the name, unless perhaps "_x86-only" vs "_x86_". For which I think there's little desire among us at this point

 

Well I know that old OS's require the old names, the only benefit from doing this is the file names are shorter, that is all. so lets stick with more functionality and options and stay away from the modern approach of simplification on the front end to lost features on the back end and even less choice to our users.

I will probably only ever offer x64 apps now as I can't test x86 apps (without doing up a VM) and I don't use them - even WINE supports x64 https://www.winehq.org/announce/1.2 (Raspberry Pi's offer x64) - Yes I know WINE is up to a much higher version, but that just means it's had x64 for a while (https://www.winehq.org/news/), I just don't see a case where my own personal efforts will require a x86 app if a x64 is available. If they aren't I don't have anything against them (YET), I do know that 32 bit apps will be hacked/targeted out of existence way before 64 bit ones are as they can never be as secure on the hardware level.
Anyway I don't have strong opinions on all this either, so if we leave the choice and/or separate the repository or not I don't mind. Like I said the only benefits are size, file name length and the build time/testing is reduced.

 

I think even the app developers are confused. They are all still listing their new releases as x64/64-bit even if the app has gone exclusively x64 going-forward. And any x86/32-bit listings are relegated to an older/previous version archive, etc. Even so, the various references to x86 or 32-bit apps probably means such things are going to be around at least a little while longer.

I'm in agreement with BP and inclined to not muddy the waters on something that seems to be working okay as is. I would also like to re-stress what I had said earlier that one can skip all the complications of a DualArch structure & construction by simply making the ppApps the traditional way. As with ssApps that usually meant separate ppApp packages each for x86 & x64 with the latter getting the "_x64" filename tag (which is done automatically with ssEditor when the Architecture is marked as "x64").

Personally, I still use these x86 apps on a regular if not a daily basis. For me, the latest isn't necessarily the greatest.

Microsoft Office 2003 (particularly its Picture Manager)
Universal Media Server
Beyond Compare
eMule
Malwarebytes Anti-Malware
Microsoft Broadband Networking Utility
DeskSave
Radmin Server & Viewer
Nero
MediaHuman YouTube Downloader
Elaborate Bytes VirtualCloneDrive
UltraISO Premium
Rufus
IcoFX
AIMP3
Nikon Transfer - this and the driver for my Razer mouse (32-bit) are the only ones not in an ssApp/ppApp form
​

There may be others but that's all I could think of right now.

​

 

When I planned to combine Browser apps into dual-arch packages not all that long ago (it started with browsers, but later extended to everything available in 2 archs), everyone was in agreement to combine x86 and x64 (with internal _x64/_x86 folders) whereas the recommendation now is (at least from Freezer) to separate them again Which is fine with me, but that's how all that got started in the first place.

So when it is said, "I agree, let's just keep it the way it is," but in the same paragraph it is said, "let's just do separate arch apps" ---> the latter is actually a change and reverting to the way we used to do it, not the way it is currently being done for the majority of apps which is dual-arch where it applies.

To be clear: most relevant apps in the repos that aren't marked with _x64_ and are available in 2 architectures, were made into dual-arch apps. I know, because that's what I have been doing for years

So, are we separating apps again into arch-specific versions? For some larger apps we had kept doing this (like Stellarium ppApp and such due to size of combined arch versions). It is fine with me to do it that way going forward. But that would be a change is all I'm saying

 

I say keep both 86/64 packaged together if they are under a certain size (to be determined by you), Then make separate packs if they are larger then said size (to be determined by you)

 

Yeah, this is what I had been doing up to now.

 

So to summarize the recent discussion, somewhat in jest:

- Things are good as they are, even if no one actually knows what it is that is good or what the nature of this goodness is or what the actual status is regarding pp/ssApps that could be considered good.
- We should not discuss app-making strategies because "the latest isn't the greatest" - but the app that isn't the latest now was the latest then (then was the now, then) and there is no reason to get stuck at any particular point in time other than sheer random, unsubstantiated preference. Apparently, new apps are only fixing what got broken in recent changes to the app, not older versions of the app, and only the chosen few know how to divinize which app version it was that was actual improvement only sans the bugs. Also, we don't like added features to anything beyond said random, unsubstantiated preferred versions we have chosen at some point because that is just pretentious. I bring this up because this has actually come up several times in the past when we were discussing app-making, and it is, of course, not pertinent to it.
- Yes, there is currently no distinction in the name of an app between a x86 app that can run on both x64 and x86 OS & a dual-arch app that installs either a x64 or x86 app depending on OS arch. This apparently cannot be remedied, but we can have the "_DualArch_" distinction in the name for dual-arch apps that have both their x64 and x86 versions installed on any OS for the extremely rare case in which one would install 32-bit and 64-bit OS in a dual-boot scenario but doesn't want to bother with installing these -- at most -- ten apps post-install on the x86 OS (using the already provided dual-arch (2a) apps that yet can't carry the fact they also contain x86 versions inside in their names, so how would you know to use those???--kinda thing).
- The latter being another way of saying: unless you use ssWPI you don't know what you're dealing with with an app. So if ssWPI can read the relevant info from the .app file, shouldn't it be included in some way in the app name when you don't use ssWPI? Or is the dual-arch app [2a] that doesn't install both archs to any and every OS not to be distinguished as such by name?



Additional notes:

- "I will probably only ever offer x64 apps now as I can't test x86 apps" <-- you are talking about x86-only apps, which would not be included in a dual-arch package [2a] (not "DualArch" as SetupS uses it...[2b]) but would instead get made into an app with _x86_ in the name and designated as x86 in the .app file.

- Yes, apps will get more x64-heavy as we go along. If they are x64-only, it will be indicated in the app name. This has been so always, whether using SetupS or doing it manually. This is not a discussion point even if it was brought up as though it was one.

 

Yes.



I was just going to reply one word as to contrast the post you did, but I didn't want you to think I didn't notice the detail you put into it. I can only say a lot of hot air and unnecessary discussions, but I know it's impossible to put the time into LastOS for me as I have been living with 8 kids from 6 to 16 who are all fussy eaters. So I really do want to say more, but there is a rental shortage in Tasmania and we have less than 8 weeks left on our lease before we are kicked out for renovations, with the fact I have applied for over 80 houses since early September and none have been successful. My old home was due to settle on the first but they lawyers lost my signed mortgage forms and my ex went on a 5 day hike the day that happened so I never knew they had lost it as they only sent her a text. So I have to cut my story short as I am driving north for 3 hours with 6 of the kids today to look at 3 house inspections.

Sorry to waste more time if you read all the above. But this is my life right now and it is a day out of many... School goes back next week.

 

I was indeed trying to put a coal back into the discussion, but "hot air" has enough negative connotation to forego any desire for discussions, so if that's what you wanted to achieve: "Yes." LOL

I literally asked: "So, are we separating apps again into arch-specific versions?" And no one replied.

This has now reached the "whatever" stage in my mind. But I guess all you guys were already there.

 

I was not trying to ignore this discussion, but as someone who is much more of a consumer of the apps instead of a provider, I didn't think my opinion should have the weight of that of the creators.

But I do believe that I understand what the problems are, even if I don't know the best way to solve them. Trouba has stated the problems clearly, and it'is not necessary to repeat the problems/questions, but just to prove that I'm paying attention :

1) How should an x86 app that works on both OS vs a 2a app be marked to distinguish them at a glance, or should they?

2) The 2a apps are the ones that could be kept together in a single app, or "do separate arch apps". Splitting them would solve the labeling problem as I see it, but if we keep some of them together, separating them at some arbitrary size point, then the labeling issue is back. So do we have to choose one way or the other, or not? Keeping some of them together is perfectly fine and very convenient at times, but how to label the 2a apps? Personally, since app storage and install size isn't really much of an issue these days, I might vote to always keep them together -- less apps to keep up with that way. I'm really OK either way, I just prefer consistency, either all together or all separate arch. But then I am a HUGE fan of consistency. At the very least, have them marked so I can tell what they are, and at this point, they're not.

And a follow on question, because of my desire for consistency:

3) Should the repo be edited to correct mis-marked apps (x86 that works on both, 2a, and DualArch), or just do them right going forward?

 

You're right, BP, it was about consistency to me as well. But I don't think x86 apps that can also run on x64 OS should receive extra labeling, I think those are okay as is. (Because the x86-only ones do receive labeling.) Or else, there would be an option to do something like "x86-64" in the name but I think that has a different connotation.

It was the x64 & x86 combined apps (2a) that, if not labeled, can't be distinguished from the x86 apps that can run on x64 OS. But since the "DualArch" moniker was already being used for the (IMO rare) occurrence of using (2b) apps, it's not clear to me how to label the dual-arch 2a apps if that is indeed found to be desirable by more people than me, hence I brought it up.

Anyway, my attempts at shaking the wagon were probably a bit over the top, but I guess it is entirely acceptable that the status quo remain, as it already has for so long. For people involved with apps, they will most of the time be able to see if the non-marked 2a apps are dual-arch or not from their size

 

Trouba, I think you said that you started combining 2a apps into a single installer with the browsers, but I'll just throw this out there as something else to consider.

In the past, I forget now exactly why, I have installed both x86 and x64 versions of the same browser for testing purposes on a 64 bit OS. (I think maybe to test extensions?) With the combined 2a apps, I can't remember for sure, but I don't think there is an easy way to "force" the installation of the x86 version on a 64 bit OS, is there? So to test such a situation for any 2a app, it would be handy to have the versions separate, unless some kind of installation option "switch" could be added? Like I said, I'm not sure at the moment what circumstances this would legitimately be useful for, but it is a thought I had. I also realize this flies in the face of what I said about liking the versions to be packaged together, but...

I guess this is just another complication in the decision matrix of the best way to handle this situation, not to mention how to mark them.

 

At the time the idea of combining architectures into one app came up, it was indeed about browsers and we had that discussion about whether x64 browsers were fully matured or if we would still need x86 ones for extensions, etc. I believe the consensus at the time was that virtually everyone was using x64 browsers by then and to therefore go ahead and do the combined dual-arch 2a apps.

If you wanted to convert a dual-arch 2a app into a 2b ("DualArch") one, all you'd have to do is Edit the .app/.apz file (right-click -> "Edit") and change it to "DualArch" and save it with "_DualArch_" in the name (at least this is how it has been named before). Then, when you install the app it will install both x64 and x86 versions. This way you can just make an additional copy of the app that is "DualArch". So, to construe it in this way, in making dual-arch 2a apps the way I have been, I was also basically making "DualArch" apps minus a little edit.

Since dual-arch 2a apps are so easily converted, and "DualArch" (2b) used so little (there are currently two apps degisnated "DualArch" in the public repo, less than .5%), it would be handy to be able to know if an app is indeed a dual-arch 2a app (being able to recognize it in the name) if indeed you wanted to convert it.

So that leads back again to the original issue, which is that there is no good way to recognize whether an app contains both architectures inside when this is not indicated in the name. The only thing you could deduce it from would be the app's size (shaky method) or looking inside.

 

I'm assuming nobody has any objections to me moving all these postings here.

It seemed more appropriate as Trouba and BP have raised some valid concerns over the issue of OSArch ambiguity related to "x86 Type 1" versus "Type 2a".

They wouldn't be alone, either. The inconsistency is widespread amongst the developers of various apps. Some release separate Type 1 installers for each OSArch; and others have Type 2a-ish installers combining the two. All with various ways of naming them as well.

 

Not sure where to begin though. So apologies in advance for my non-linear rambling...

When Trouba asked: "So, are we separating apps again into arch-specific versions?" And no one replied. I don't think anyone was necessarily being rude. Nobody knew what or how to answer that, myself included. The question was almost rhetorical.

My original thinking that probably lead to that question was that certainly going forward, as we're heading into an era of x64-exclusive apps, there will naturally be x64-specific versions; but obviously no x86-specific ones unless it's an older version still made available by the developers. So not really separate arch-specific versions, per se. More likely there will be a return to Type 1 installers especially for new versions of x64-exclusive apps and perhaps separate x86-specific ones for older versions. Combined installers such as Type 2a ssApps will be obsolete because there will not be an x86 counterpart. Ditto with Type 2b, "DualArch" ppApps. Though Type 2a ppApps could still be constructed, it'd largely be impractical to continue to do so.

Which kind of leads into that naming ambiguity with "x86 Type 1" versus "Type 2a"... if Type 2a (and 2b) apps are to eventually be depreciated then that naming ambiguity will also eventually become moot. But for the time being the ambiguity is still relevant.

First of all, I think it's pretty cool that early on, when developers didn't offer a Type 2a installer (just Type 1 installers), we could make Type 2a ssApps out of the two available Type 1 installers with the use of gated directives -- Is_x86, Is_x64, etc.

But also early on there were no Type 2a installing of ppApps. At the time, ppApps were only available as Type 1 -- separate arch-specific versions, if you will. Then came the development of the Type 2b installer, so called "DualArch", which was totally unique to ppApps (and still is). Though the installing of ppApps via Type 2b "DualArch" would prove to be less common, this breakthrough ultimately paved the way for Type 2a installing of ppApps.

As a consequence the file-naming convention with regards to OSArch tended to follow this path. The standard Type 1 installers typically used something like "(x86)" and "(x64)" in their filenames. And the standard Type 2a installers would use something like "(x86-x64)" in their filenames if they used anything at all. For a time there was a SetupS <Architecture> tag for these but it was rarely used. In hindsight it might've been practical to not have depreciated that tag and used it for the "Any" OSArch instead.

But that means we could've also really used an x86 one as well -- one that was non-exclusive anyway. As it turns out the current x86-only tag was (and is) almost never used. I mean, has anyone ever heard of an x86 app or game that did NOT work on an x64 OSArch? If it was being used at all, it was being used for 16-bit Windows games. (16-bit does not work on an x64 OSArch). Also in hindsight, those 16-bit games -- I guess there was not much interest in 16-bit apps -- would instead better benefit from a 16-bit filename tag. That would free up the x86 tag as non-exclusive so it could be installed to an x64 OSArch as well.

Something else, I don't think ssWPI has the ability to differentiate an "x86 Type 1" from a "Type 2a", does it?

None of this addresses the naming ambiguity, of course. But I've got some ideas:

1. Turn off the SetupS x64 block for installing apps with the x86 <Architecture> tag as I believe it serves no purpose anymore. This is so that an app marked as x86 can still be installed to an x64 OSArch. This might be the most problematic to implement because of all the legacy apps in the repos and elsewhere that would need their <Architecture> tag revised; plus any older versions of SetupS still out in wild that would continue to block x86 installs on x64 systems.

2. Reinstate the x86-x64 tag for the "Any" OSArch (Type 2a). This is less problematic to implement because the changes would be only to ssEditor when building apps or games. But probably should be implemented at the same time as #1 above as it would be too impractical do it otherwise.

3. There should be no problem renaming future (and existing) apps to add the "_x86" tag to "x86 Type 1" and the "_x86-x64" tag for the "Type 2a" ones. As long as their Architecture is still listed as "Any", that is. This is the least problematic and easiest to implement. Will require our standards and documentation revised to reflect this though.

 

LOL, "IBM" ...

But as far as I can tell there's nothing on the horizon for 128-bit processors on any kind of device (desktops/notebooks, tablets, phones, etc). Wikipedia reports there are currently no mainstream general-purpose processors built to operate on 128-bit integers or addresses, and PC Magazine says a 128-bit processor may never occur because there is no practical reason for doubling the basic register size and that for all practical purposes only a few more bits beyond 32 were all that was needed. Plus, one of the reasons for migrating from 32-bit to 64-bit computers was memory (RAM) addressing; however, a 64-bit register could reach 18 quintillion bytes of RAM, roughly a million times more than the largest computers today.

Though some graphic cards and GPU's are 128-bit but that's only on their internal buses I believe.

Me? I'm still waiting for quantum computers.