64 Bit Applications support

The whole point of portable apps is that they run everywhere and the user doesn't need to know what system they're running on. A 64-bit Windows app won't work at all on a machine running 32-bit Windows even if the CPU is 64-bit. *All* our apps work on Windows regardless of whether it's a 32-bit or 64-bit system. That way when you walk into a hotel business center that's running an older Windows Vista 32-bit machine, your apps work. Or if you happen to have one of the inexpensive modern Windows tablets or convertibles with only a 1-2GB of RAM (all of which are running a 32-bit version of Windows 8.1 or 10 because it requires less memory), your apps work when you sync them with OneDrive. Plus, PortableApps.com is global and runs in 57 different languages. Lots of people use it on their own older and less expensive hardware.

So, what about an app where the 64-bit one runs much faster? Even though, contrary to popular belief, most 32-bit apps outperform their 64-bit equivalents, some apps do get a worthwhile performance boost from x64. When compressing a large archive using 7-Zip, for example, the 64-bit version can net you a nearly 10% speed improvement. Since this is something some users will encounter, 7-Zip Portable is what we call a "dual mode" app. It includes the 32-bit and 64-bit versions and runs the correct one for the current machine automatically. And they share settings, so you can use your app the same way everywhere and don't need to worry about what kind of machine it is. If you're curious about when this is done, it's outlined here: https://portableapps.com/node/24371

The bottom line is that to consider Abricotine for inclusion, there must be a 32-bit version of it. Otherwise it would randomly (to the user) not work for quite a few users.

Your main and first point in your post was this:

Lately, as in any progress, there are some great applications which are, to begin with, 64 Bit only.

As pointed out, this is a straw man argument. It was an issue for one specific app due to a bug preventing their 32-bit build from working owing to the fact that the lone developer isn't primarily a Windows developer. They have an open bug to fix it.

As to your other points that you keep raising:

1. You're thinking platform only. A large percentage (but not majority) of our users do not use the platform. So this will need separate download buttons for 32-bit, 64-bit, and 32+64-bit on the website, which is messy and confusing. Plus, as stated multiple times, it's a lot of additional work. Work to produce 3 separate packages for each app and work to support 3 separate packages. Work that would take away from time of building new apps or adding platform features. Work I don't have time for and would not get paid for. For no real benefit. I'm unsure why you continuously ignore this point in each of your posts.

2. We support 64-bit. We don't support 64-bit-only apps because, despite your claim, it's not a reality outside a couple odd edge cases where a developer is having issues with a broken 32-bit build as pointed out. As already stated, if there were a bunch of great apps we wanted to include, we'd revisit this. Add to that the fact that it would be confusing to users. Again, a large percentage of users don't use the platform and would use the website. Even if we have a huge warning that says an app is 64-bit only, we'd still get confused users asking why it's not working.

3. The PortableApps.com Platform does not report stats back and Google Analytics does not break down 32-bit vs 64-bit browsers or operating systems. The app you mentioned specifically, Google Chrome, sees 4.4% of its downloads as the 64-bit-only version. This is a similar setup to what you are suggesting above which would mean a user having to dig in and make a specific selection to allow 64-bit only apps, only it's labeled as "Advanced Apps" in the platform currently. On the website, the 64-bit version is moved down the page so as not to confuse users who don't know whether they need 32-bit or 64-bit. So, we already have a case study of what you are proposing. As mentioned, Google Chrome 64 will be going away shortly in favor of a dual mode 32+64-bit version. It's only dependent on the installer and updater getting support for two 'live' downloads for a single installer/app.

4. Nothing in my arguments is contradictory. We have a set of goals, some of which are at odds with each other, that we must balance in a way to ensure users get the best experience. What you're thinking of is that we want to keep apps as small as possible without impacting features, performance, or antivirus false positives. As an example of these goals being at odds: The latter of those three is why we no longer use the AppCompactor (which uses UPX) on production releases. Yes, it saves a good amount of space for users with smaller portable drives or limited cloud folder space, but it causes frequent false positives with a few popular free antivirus engines. Which affects users' ability to use the apps. So, it was removed. We want apps to perform as well as they can, so with apps that require 32-bit or 64-bit specific versions for a given OS due to drives like PeerBlock or JkDefrag or that have a large performance boost like 7-Zip (only 9% but that's about as large as you get with 32-bit vs 64-bit), we include both packages in one. Even when including both packages, we still try to save space by determining what files are shared between the two versions (locale files, help files, bundled 3rd party utilities, etc) and including a single copy of those and moving them between 32-bit and 64-bit to save space without affecting features, performance, or antivirus false positives. That way we are able to provide the advantage of the 64-bit version of the app to 64-bit Windows users in the rare scenarios where the 64-bit build has an advantage while still keeping the size as small as possible. It's a rather simple set of guidelines that apply to all apps. And it's why it doesn't make sense to even think about the 64-bit builds for the handful of apps we do but don't already bundle since they provide no benefit to the user.

Intel and Microsoft push 64-bit at the operating system level because there are real tangible benefits there including accessing more than 3.5GB of RAM and better security. At the app level, Microsoft is making no such push to get developers to build 64-bit-only apps. Doing so would mean excluding 25% or more Windows users for no good reason, which is a rather big impact on the bottom line. 32-bit apps and 64-bit apps perform identically for the user and the end user can not tell which are which without going into Task Manager and looking for the process (something 99% of users will never do). For a very small percentage of apps, there is a tangible benefit for 64-bit. For those apps, we already provide them. So, you already have the performance you're looking for.

In the end, the only thing you seem to be missing from what you want is that you don't want the 32-bit versions of the apps taking up space on your drive. At some point in the future, the platform will be able to have an option to delete them on install to save space. I'm unsure when this feature will be available and it won't work for all apps. The launchers must be specifically coded to handle it.

So, for the last time, no, we will not be packaging 64-bit-only apps at this time. Please understand that this is the definitive and final answer at this time. Remember, we have very different users with very different needs and balance them in a way that is as beneficial as possible for as many as possible and doesn't overwhelm us with build, support, and maintenance tasks.

We need 32+64-bit combined apps for the large percentage of users that use PortableApps.com on a removable drive or synced cloud drive and move between both 32-bit and 64-bit apps. That way, they get the the benefits of the right version on each PC and get to use the same set of settings. Read that last part again because it's important for the users. The same set of settings. Not managing a 32-bit version of an app and a 64-bit version and having to manually manage settings if they're one of the many people (for example: everyone commenting in this thread except you) who use both 32-bit and 64-bit Windows. Plus, if they use 32-bit Windows only now and later upgrade to a new PC and move their apps over, they suddenly get the benefits of the 64-bit apps without needing to manually copy settings between the 32-bit versions and the 64-bit versions. These are very common, simple scenarios that happen for users all the time in the real world every day right now.

So, that's the proven, definitive, real-world, affecting-users-today reason that we do combined apps and will not do 64-bit only apps just to save a few MBs in install space. What you are asking for would affect all of those users. Remember, most users are nothing like you.

Next, the extra effort is not negligible and would involve 3 separate app packs instead of 1. Or, at least 2. Even if we did separate packs only and completely broke the ability to move around, keep your settings, and get the benefits of 64-bit when they apply without having to move settings, it would still be at least double the number of packages for me to maintain at the distribution level. Double the number to ensure work. Double the number to digitally sign. Double the number to maintain in the updater database. Double the number to link to and update the links of on the app web pages. Double the number to support when users have issues. This is a significant amount of extra work for no benefit to the end users. So, a dismissive "I see the extra work and it is your decision if to put effort into it." doesn't address it. Not even close. And it's certainly not worth releasing fewer new apps and having less platform updates.

Finally, we've already shown that your claim of excluding all these wonderful 64-bit-only apps is a straw man argument. We're not excluding anything. There is no huge cache of amazing 64-bit-only Windows apps that are being left out in the cold. There was one single app that you wanted that at present is not available as a 32-bit package due to the fact that the build process is broken and the developer isn't experienced enough on Windows to fix it themselves. That's it. It doesn't matter what Adobe or MATLAB are doing in the future because they have nothing at all to do with PortableApps.com. Their apps are designed to lock to specific hardware with all kinds of DRM and will never be portable (unless you count shifty hacked versions that include who-knows-what from random blogs hosted on random file-sharing sites in countries without modern copyright laws). And I already very clearly stated that if this situation were to change... and a bunch of good, real apps that could work with our platform were 64-bit-only - we would revisit the policy. Essentially, I'm agreeing with you. If your argument were reality, we'd be doing it. If Adobe called up and wanted to do a portable version of 64-bit-only Photoshop, we'd do it. But the situation you are claiming does not currently exist. So, please stop arguing it.

Please go back and read the responses from everyone else. You're alone here in this debate for a reason. I implore you to try to understand why what you are asking for does not make sense and the small read-world benefit of saving a few MBs of download/install space is overshadowed by the cost of huge inconveniences to the user, additional complexity in managing settings and moving between PCs for the user, and adding a ton of additional cost to build, maintenance, and support on our end.

Please note that this will be my last response on the matter for now. I've fully explained the logic behind the policies and why they make sense. If you disagree, that's fine. But the matter is closed at present.