Quantum computers will be accepted only by big players[Lords of this world].And only at command of their palms.Whit quantum computers human will be controled and hunted like hell and will be just like little pigs that are raised only for meat and to replace human[and extraterestrial,or intraterestrial ] organ.
No, the question regarding arch-specific apps was not rhetorical And we used to make arch-specific apps and I thought we could just revert to these (although not necessarily my preference) thereby eliminating the need for a change in naming convention. I'm glad this is getting some traction And yes, the x64-x86 (I'd prefer the x64 first for some reason) in the app name might be a good avenue to achieve this. You say we used to use that, but I honestly can't say I remember that very clearly at this point and I don't think I have any local apps anymore that reflect this. (Slight different topic, but I was reminded of another illustration of how various installers are labeled, namely: LibreOffice. They make a 32-bit suite that does run on x64 OS, and is therefore distinguished as follows: "x86_64" -- just FYI.) If we do indicate "x64-x86" in the name of the 2a apps, then we need to think about whether we want to retain/use the "_x64" and "_x86" internal folders for at least these dual-arch 2a ppApps.(If nothing else, for the purpose of being able to make single-arch apps of the same app (for example when x86 cracks aren't available) and still be able to overwrite / write to the same app folder. In other words: _x64 folder overwrites _x64 folder.) As to some of the finer points, honestly, I think only you understand the full history and implications of these so we defer to you entirely. As for x86-only apps, they do actually exist. iTunes is an example, the 32-bit version will not install on x64 OS. I had a folder sync software (SyncBack pro I think) and some others that actually won't work on x64 OS. Of these, some have this built into their installers only (like Win7/8/10/11 Manager apps), but then you can actually run the 32-bit app on x64 OS when extracted. Others, won't even run at all even when extracted and so the OS arch check runs deeper. Hell, some even have 32-bit files written to x64 Program Files location and released as "64-bit"! Some dual-arch 2a ppApps have the "32-bit-only" version included but you'd never know (I think WinSnap is an example of one), but these being dual-arch 2a apps of course aren't marked "_x86_" , plus it would only install the 32-bit version on 32-bit OS anyway... etc. It gets gnarly.
Indeed we need order in haos.Trouba as indeed a dilema...like all of us...at least me that i ask at some point TROUBA what it all about dualarch and stuff.
We do indeed need order from the chaos, @mircea. As Freezer said, there is no consistency among other App makers either when it comes to naming conventions for Apps. A few examples from ones I found listed at Wincert over just the last month are: Notepad++ 8.3 Dual x86x64 [Desatendido]Multi WinRAR™ Theme Pack V22.2 Multilingual [32-64 Bits] RuntimePack 23.01.22 Silent (x86/x64) Visual 2005-2022/C++ Redistributable x86/x64 [2022-01-22]by abbodi86 Java™ Runtime Environment 8.0 Update 321 [Desatendido- Dual x86 & x64 ] Adobe Components 20.01.2022 Desatendido Multi x86 & x64 Sumatra PDF 3.3 x64 - x32 Silent (Español) Daum PotPlayer 220109(1.7.21589)Stable x86x64 [Multilingual][Desatendido] 7-Zip 21.07(32/64 bit) [Silent] [Multilenguaje] These 10 Apps were provided by two different App posters, but there are 10 different ways the Apps are marked which I assume are all type 2a, and not DualArch, regardless of the Dual in the name?: Dual x86x64 [32-64 Bits] (x86/x64) x86/x64 Dual x86 & x64 x86 & x64 x64 - x32 x86x64 (32/64 bit) Admittedly, the differences are slight, but still... So the Apps at LastOS are a heck of a lot more consistent than that! I know that doesn't directly help us with the x86/2a issue, but I think it does tell us that we can't look elsewhere for examples of the "right" way to do things. We just have to decide the best way that meets our needs, and define what that way is ourselves. Glenn is correct that we will need to acknowledge the x64 only reality of Windows OS sooner than we, or at least I, would like to, even though I have only been running 64-bit OS for many years. I just don't like the idea of being "forced" to do so by MS. But even with that eventuality, Trouba's examples to the contrary notwithstanding, the vast majority of x86 Apps will run correctly, and sometimes better, on x64 OS. And as Freezer said, "the latest isn't necessarily the greatest." So I don't think that Glenn's original suggestion to "Let the x86 stuff fade into the oblivion," is the best way to handle things. As Trouba says, Freezer is the one with the most knowledge and understanding of the history and implications of the finer points of the implementation of the various naming conventions, so he is the one we should rely on as to how SetupS handles things and its inner workings. But I think that Trouba and Glenn have publicly released the most number of Apps, so their experience of creating the Apps, and their observations from examining the inner structure of Apps created by others, should not be discounted either. Trouba's examples show that Freezer's 1st idea of "Turn off the SetupS x64 block" could be even more of an inconvenience/problem than Freezer expected, in addition to the issues he raised himself about Legacy Apps and Apps in the wild.That also means that Freezer's 3rd idea might have issues as well, since it seems that there are still situations where _x86 needs to mean "installs on x86 OS and only x86 OS". From all of the above discussions, we seem to all acknowledge the problem and want to come up with a solution we can all live with and understand. Ghost, and Glenn in a way, have suggested splitting the repos into x86 and x64, so separating all 2a Apps. If the x64 OS only are marked _x64, the x86 OS only are marked _x86, and if it's not marked at all it means it's a x86 App that will work on both OS, then that will work. It will be easy to tell what is what. I think at some point that we have all agreed that that way would solve the naming problem. But it loses the DualArch 2a and 2b Apps. They would all have to be split. True, there aren't many DualArch 2b Apps , nor folks that take full advantage of them, but still. My opinions below are strictly from a user perspective, and they only address the external name of the App and not the internal folder structure nor the flags that SetupS reads nor how they are handled by either SetupS or ssWPI. Trouba, Glenn, and Freezer know WAY more about that than I do and are more qualified to address those aspects. This includes Freezer's statement (taken out of context, I know, but): Trouba has also already made several pertinent points about the Apps internal structures and how they can effect App installation or conversion. In the App name, in addition to _x86 meaning x86 OS only, and _x64 meaning x64 OS only, we can probably continue as Trouba and Freezer stated earlier: So all of this is consistent with all such Apps that are already in the repos and those Apps should be consistent with what Ghost and Glenn's preferences are as well. But I don't think we need to throw away either version of the DualArch Apps. The few 2b Apps are already consistent, AFAIK, so they're fine as they are. Leaving, as the only thing to be addressed, the need to settle on and implement a naming convention for the 2a Apps. It seems, from a user perspective, that adding some variation of x64-x86, as shown in the Wincert examples, should be something that we can understand, be a relatively minor change, and others should understand as well. It seems to me that that would also effect the fewest number of apps (at least it's only one type of App and it should only effect their external name?), so hopefully it will be the easiest to implement. Also, if as Freezer said, the 2a and 2b Apps are to eventually be depreciated, then not having to make changes to any of the other types of Apps is a plus. This would mean that Ghost and Glenn's preference will eventually come to pass. But not necessarily today. But if everyone agrees, if it is going to eventually be that way anyway, that it would be better to just bite the bullet and split 2a and 2b Apps up now, that's fine. I really am OK with either decision. As I see it, the only bad decision is no decision. There's just too much inconsistency and possibility of confusion as it is now.
In my mind, there are two main things to consider. 1) The history and design of SetupS as it is now. 2) The way the repo apps actually make use of this (historically, and practically). As to point 2, this is (one of) my view(s): Given that we don't have many people with different methods uploading apps, efforts at consistency would be much easier to implement. Since there are quite a few dual-arch 2a-style ppApps in the repo already (specifically: ones utilizing _x64 and _x86 internal folder structure), I think it would be best to use these as a basis to create new/updated versions of these apps. So even if, say, Glenn would like to update a ppApp that would fit the above description but would only want to make the x64 version of it, he could just use the already existing version of the app, retain the _x64 internal folder, but leave off the x86 version and indicate x64 in the .app file (and _x64_ in the name). This way, installing that app on x64 OS would simply overwrite the _x64 folder on any given x64 OS install that already had the (previous version of) the app installed, and update the app without conflict. Then, next time, I might update the same ppApp but also update the _x86 version inside the app, in which case I would undo the x64 indicator in the .app file and the "_x64_" designation in the app's name. This is one way I thought of doing this. Further: It is true that making dual-arch 2a ppApps will only get their x86 versions of the app installed and used on x86 OS, which, admittedly very few people run now. The added value of still making dual-arch 2a ppApps is that it is very easy to convert these to actual DualArch 2b ppApps, as noted earlier. Still, the 32-bit apps provided in the dual-arch packages (either 2a or 2b) would normally only get utilized when a 32-bit OS is being used. So I can definitely understand the reaction "let's just get rid of x86 apps where possible." The solution for this view would then be to not combine architectures of apps into one ppApp or ssApp: - No architecture designated in the name of the ss/ppApp would signify: 32-bit app that also runs on x64 OS. (If desired, we could indicate "_x86_64" in the name like LibreOffice does.) - "_x64_" designated in the app name signifies: 64-bit app that only runs on x64 OS. - "_x86_" designated in the app name signifies: 32-bit app that only runs on x86 OS. This would of course imply getting rid of _x64 and _x86 internal folder structures. There really is something to say for this approach. In the end, I'm willing to do whatever everyone thinks best.
For updating the Apps, the description of your '(one of) my view(s)' seems pretty straight forward and makes sense. I like it and it seems to be a clean way of making the 2a Apps, as long as the external App naming can be agreed upon. Under 'Further', it seems the only way to force the x86 part of a 2a App to install on a x64 OS would be to either convert it as you explained earlier and add the shortcuts as appropriate, or add some kind of optional installation switch. While that would not work for simple double-clicked installs, requiring a command line switch to implement the option doesn't seem too big of an installation inconvenience, since it's use would be extremely rare, and it's kind of consistent with the implementation of runtimes and MS office products that have various install switches available. This whole situation can be safely ignored if the likelihood of it being needed is deemed too remote to be worth bothering. The only thing I disagree with in the rest of your post is the possibility of making "_x86_64" mean a 32-bit App that also runs on x64 OS. While functionally accurate, the only way I see that working is if all combined Apps, both 2a and 2b, are completely done away with. Otherwise, I think confusion is very likely. But in that case, if combined apps are eliminated, I don't really see the necessity to have the "_x86_64" marking when it could be implied by having no architecture designated. While always specifying the architecture, and not implying anything, could seem to be advantageous regarding clarity, if enough other app makers have adapted the 2a structure and have similar markings to "_x86_64" for those Apps, then the possiblity of other folks being confused will still exist. [If we care about that.] Bottom line, the creation of combined Apps has caused confusion that will probably continue for many years. It's beginning to sound like we might be leaning toward splitting up the combined Apps, even if it means giving up their advantages, both for solving the naming conundrum, and because of the way it appears that future App distribution is headed. But, as you say, I'm also willing go along with whatever everyone thinks is best. I truly see advantages to both approaches., which Is why I originally refrained from commenting very much on this subject.
As stated the only reason I suggested to split and seperate them to 2 repositories is due to the 32 bit versions no longer being updated, by the developers or by myself. My solution, let's have 3 repositories. x86, x64 and dual. The internal method of dual is unimportant, the fact is we handle that during testing and if we see a logical reason to include shortcuts for both x86 and x64 on the one is we do. The only reason I update x86 apps now if for playing with LivePE's as these are the only size sensitive situations I need to. I can see how some people will find uses for x86 only apps, but not really a use for dual, EXCEPT if the run dual OS's from the one ppApps folder. Which I've never come across or did myself. The goal is to have an OS that works with little user interaction on setup. Stable and not take up excess size where possible. Dual arch are known to increase the size of the installers and the installed version and I just can't justify making them except where I see a use case (livePE or known bugs). So although this is my input, I am only suggesting we split the repo as it doesn't take long to check each one for updates and I work in each folder when I build. I could see a use case where we seperate the local versions too though, so maybe think about ssWPI supporting ppAppsInstalls_x86 and ppAppsInstalls_x64 (same for ssApps and Live). This would enable you to know what your getting. As for making dual arch, I try not to do it myself, so you can change this however you who do feel will speed you up.
My only comment about separate repositories, is that I hope you are not saying that the App names will be identical, it will just depend on which repo it is in as to whether it is a, x86, x64, or DualArch version. I would be sure to copy it into the wrong folder and be screwed. As long as the Apps are uniquely and logically named so you can tell at a glance which version it is, then I won't care how many repos they are spread over. But then, if they are all uniquely named, then why are we putting them in different repos? I'm afraid I'm missing the point.
This is moore about "team work" in the App development.Somoane must take initiative and disscouse whit all the communitise about these changes....Its a long way....
So, the thing about separate repositories is that it will have an implied dampening effect on app creation where it comes to dual-arch or x86 apps, in that you then have to separate the methods of app creation, which then means twice or thrice the work, which will result in the additional architecture just not being created and/or included because the app maker in most cases will already be doing the work on the x64 version for sure. Which, yes, in a way sharpens the point that x64 apps are mostly what is used and therefore should be mostly what is created. However: x64, x86, and DualArch repos would not be the way to go about this in my opinion: If what is desired is making a x64 and x86_64 only repo (apps that run on x64 OS), then one may as well include x86-only apps in that repo also, since there are so few of theose. And then you might as well include DualArch (2b) also, since there's even fewer of those. In short, the system we currently have in place. "The goal is to have an OS that works with little user interaction on setup." <-- Yes, but having a handful of x86-only apps (or even fewer DualArch apps) in the repo won't make it any harder to achieve this. (I think you may be conflating dual-arch 2a apps with "DualArch" 2b apps here, not sure.) Perhaps we should look at it differently, and ask what would be that hard about adding a certain naming convention; and, for ppApps: what would be so hard or confounding about adhering to an internal folder structure of _x64 and _x86 folders for these (even if at times only making the x64 apps but keeping that structural standard intact for compatibility with dual-arch 2a apps of which they would then be a sub-set).
Recently I found OTVDM which does allow 16-bit software to run on x64 Windows seamlessly just like NTVDM did for x86 Windows. I've made it into a ppGame (engine) along the same vein in the likes of DOSBox, Altirra, ScummVM, etc. Now we don't really need a 16-bit filename tag anymore; but I may end up using it anyway because OTVDM (or Win31DOSBox) is still required to play on an x64 OSArch. OTVDM_v0.8.1_x64_ppGame.pgz Examples of what I have using the above: Microsoft.Entertainment.Pack_c1990_16bit_ppGame.pgz Microsoft.Arcade_c1993_16bit_ppGame.pgz Microsoft.Return.of.Arcade_c1996_16bit_ppGame.pgz Enjoy!
So without modifying SetupS (merely some "creative" renaming), here's an app that still has both architectures available and some possibilities it presents: MKVToolNix_v65.0.0_x86-x64_ssApp.apz ("Type 2a" ssApp) MKVToolNix_v65.0.0_x86-x64_ppApp.apz ("Type 2a" ppApp using the DualArch-ish structures of a "Type 2b") 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. Unfortunately this might imply that it only runs on an x86 OSArch). or: MKVToolNix_v65.0.0_ppApp.apz (as Trouba has suggested that the "_x86" tag be dropped for x86 "Type 1" since it runs on either OSArch). That last one would be the only package without an OSArch filename tag as there would no longer be any ambiguity.
I was thinking since "x86-x64" looks a lot like "x86_64" which is sometimes used to indicate x86 that also runs on x64 OS, if we indicate dual-architecture in the name, it should probably be "x64-x86" -- even more so because x64 is preferred going forward so it should get the order preference (and prevent the possible confusion with x86_64 as mentioned above). What do you guys think?
It can be anything at this point. The filename is transparent to SetupS. (I just don't know for sure if that's the case with ssWPI, though). But such things will matter during apz builds with ssEditor outside of manually renaming them post-build. I just haven't quite yet figured out how to go about that properly -- or easily. I was considering -- and still am, actually -- of using "_x86+x64" for a package containing installers for both OSArches. The plus sign "+" has traditionally stood for logical "OR" and is a valid character that can be used in filenames. Unlike the logical "AND" which can be either "x" (already used by OSArch) or the asterisk "*" (which cannot be used in a filename). Could also be "_x64+x86", I guess.
I had inadvertently neglected a couple more possibilities with those previous MKVToolNix examples. The developer had originally provided individual installers for 32-bit & 64-bit rather than a combined ("Type 2a") one. So using the magic of SetupS, the single "Type 2a" ssApp package, "MKVToolNix_v65.0.0_x86-x64_ssApp.apz" was constructed from those like so: Code: <Assembly> "mkvtoolnix-32-bit-65.0.0-setup.exe" /S #Is_x86# "mkvtoolnix-64-bit-65.0.0-setup.exe" /S #Is_x64# Here's the other two as separate "Type 1" ssApp packages (versus the "Type 1" ppApp's): MKVToolNix_v65.0.0_x64_ssApp.apz (x64 "Type 1" ssApp that only runs on an x64 OSArch) MKVToolNix_v65.0.0_ssApp.apz (x86 "Type 1" ssApp counterpart that runs on either an x86 or x64 OSArch)
On the subject of DualArch ppApps... PortableApps.com had a different way of handling DualArch. Their apps would typically be run from a USB drive on computer(s) that could be (at the time) of either OSArch. So they would use a launcher (x86) that determines which OSArch-app to run. For example, there would be a "CCleanerPortable.exe" that would launch "CCleaner.exe" versus "CCleaner64.exe" depending on the OSArch. Since their typical use case was from a (smaller capacity) USB drive, all the app files would be contained in the same folder to save space. The problem with such a scheme is that even though the app doesn't care what the filename was that launched it, the support files like .dll's and so forth would have to be for the x86 app. The SetupS-method fixes that by isolating the two apps into separate (internal) OSArch folders. Then merely generating the appropriate OSArch shortcut(s) for the ppApp. Even though the nature and philosophy of a ppApp differs somewhat from that of a PortableApps.com one; I believe we have several DualArch ppApps that are actually using that launcher method from PortableApps.com.
Yes, we do have a few of those. More recent iterations of CCleaner ppApp have this, in part because CCleaner Portable (the one Avast provides) contains both archs in one folder to begin with. CrystalDiskMark/Info are another example of this.
Could also be "_x64&x86", as far as a valid Windows file name, but I think the "+" looks better. I like "our way" better, too; it seems to be a cleaner approach. But your comment was just that -- a comment, right? You aren't suggesting we should re-do those apps "our way", if that would even be easily possible, are you?
Well, the thing is we have in large part been following "our way". Many dual-arch 2a ppApps have this internal folder division, which is what I brought up at the onset of this discussion. So I brought up whether or not we should standardize this, given that this is already true for a lot of apps. Speaking for myself, I did this almost wherever possible. So this is not an academic point at all, it is what has been in practice in the repos already -- just not by everyone and for every app, and sometimes for different reasons it hasn't been (like exe architectures being in the same folder from the app manuf because they draw on common resources in said folder, etc.). So, if there is only x64 available for a particular app, there is no benefit to providing an internal "_x64" folder. But when x64 and x86 versions of an app are available, it may serve us to include these in _x64 and _x86 folders -- EVEN IF we at times only make the 64-bit version (in this case we'd just provide the _x64 internal folder in the ppApp.7z). This way, when installing a x64-specific version of said ppApp, it will install it in the same folder as installing the same but dual-arch 2a version of that ppApp would do. If you don't put the x64 version of said ppApp (of which there is also a x86 version of that program), it will install the x64 version in root of the ppApp dir, while next time it may install the x64 version inside a _x64 folder. So the reason I brought this up is so that you can easily overwrite an existing install of a ppApp on any OS arch and it simply overwrite the app, not just create a disparate versions of it. Another benefit of this is that you can leave the dual-arch shortcut structure (and any arch-specific info in ppApp.cmd and ppApp.reg files, etc.), so that when you decide to make a dual-arch version of the same, the structure is already there. I'm not sure everyone really understands the benefits in a practical sense, but I think you only realize that when you make the apps.
I'd considered that also ("&" for logical "AND"). But in my mind, Type 2a is x86 "OR" x64; Type 2b is x86 "AND" x64. Fortunately, we already have a tag for Type 2b: "DualArch". No, I think they are fine as they are. It'd be too impractical otherwise. For example converting it into a Type 2a would be too much work. Easy enough I suppose converting to a Type 1. Regardless, a new version would require starting over again; especially if it's not sourced from before (such as from PortableApps.com).
