I would like to raise a point for discussion.
It started on a different thread but it belongs here.
The current policy (Or at least the way I understand it) of PortableApps is to support applications if and only if they have 32 Bit version.
Lately, as in any progress, there are some great applications which are, to begin with, 64 Bit only.
I suggest that the policy will change to include applications which are 64 Bit only (With a warning for the user that those won't work on 32 Bit version).
Because the way I see it, this is not about Portable Applications which work anywhere but on having Portable Apps you need.
I for instance use PortableApps instead of installing, this keeps my system tidier and faster (I only install Office, besides that works only with Portable Application hence my system runs for years with no need for format).
This is the logic which leads me to the idea that PortableApps should just supply any application it can.
Moreover, for applications which have both 32 and 64 Bit versions, the user will be able to chose which one to install (Instead of both as currently done in some cases).
It won't change anything for those who wants 32 Bit applications.
It will only expands the number of applications in this great format and will let advanced user to configure things according to his thoughts and best understanding.
Thank You.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
Are you telling me you prefer 32 Bit programs on 64 Bit?
I don't see the logic here, really.
I know 32 Bit can run on any system, but really, we're in 2016.
It's like mentioning the size of a file / program as a limitation.
I don't think those two things are relevant in our days.
If iPhone runs 64 Bit only, we can expect PC's to do so.
[Mod JTH Note: This comment thread was moved from a discussion about a specific app and is more relevant here]
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.
Sometimes, the impossible can become possible, if you're awesome!
As I wrote above, I thought that would be your argument.
Personally, I don't think it is valid anymore.
I wonder what's the statistics, but I would guess less than 10% of the PC's are 32 Bit.
Probably even less in 2-3 years (I think soon enough MS would stop creating 32 Bit versions of its OS).
Usually, in life, I prefer being one step ahead, so I'd turn this framework into 64 Bit in default.
In the case of MarkDown Editor it means instead of using the best application out there we have 32 Bit application which looks like Windows 98 application.
By the way, according to the File Name it seems to be 32 Bit and 64 Bit application:
https://github.com/brrd/Abricotine/releases
The thing is, there's no reason to. Everywhere 64-bit makes sense, we use it. So we have a dozen or so apps that are dual mode. When it doesn't make sense, we don't. Remember, just because we're relatively well off and have a more modern PC, doesn't mean someone across the world does. This software caters to a lot of different people. Plus, in many cases, the 64-bit version of an app performs worse than the 32-bit version. In those cases, there is literally no reason to be using the 64-bit version at all.
Lastly, in the case of Abricotine-win32-x64.zip, that means it's the Windows build 64-bit only. Win32 refers to the OS type in this case, which means modern Windows as opposed to Win16 which means legacy Windows. It is not up to use that the developer is only releasing a 64-bit build. The tech they are using supports wither 32-bit or 64-bit builds. A 32-build would be a bit smaller, use quite a bit less RAM, and work on every modern Windows PC (both 32-bit and 64-bit). Plus it would likely perform exactly the same if not a bit faster. Feel free to request that the dev add a 32-bit build.
Side note: I played with the app a bit more and like it. If the developer can fix their issues with their 32-bit mode, it will be considered for inclusion.
Sometimes, the impossible can become possible, if you're awesome!
Totally agree with you, John. Most users in developing countries still have to accept that most Internet cafes still use Windows XP--maybe because the license cheaper when they bought it.
This program is 64 Bit Only.
So anyone with 32 Bit system has no chance using it.
What's the point in preventing it from 64 Bit users as well?
I can see the logic that if you have 32 and 64 Bit version make the 32 portable.
I don't agree with it because "Compatibility" is over rated (The Only PC OS X with growing user market share dropped any support for 32 Bit because they don't make sense in 2016) but there is a logic.
Preventing 64 Bit only program form 64 Bit users has no logic behind it.
OS X is the opposite situation. They're forcing the OS to be 64-bit only because they can because they control all the hardware. And it doesn't cause compatibility issues since all the old 32-bit apps work fine on a 64-bit OS.
The difference here is that while you and I know we are running 64-bit, the vast majority of users have no idea. And quite a few are running 32-bit on relatively modern machines. All those lower end tablets and laptops that were sold with just a bit of RAM... all 32-bit Windows. You can't even run 64-bit Windows on most of them.
That's why we don't release 64-bit only apps aside from a couple test versions to allow users to test certain things.
Sometimes, the impossible can become possible, if you're awesome!
No, Apple made that change for one reason, it is time to move to 64 Bit.
If Android and iOS are 64 Bit there is no reason for applications for Windows to be 32 Bit.
Now, the only reason Microsoft kept 32 Bit versions and support for 32 Bit applications on Windows was the agenda "Compatibility Above All".
Well now, when they are losing ground they understood this is the wrong policy to make progress.
Since most application here are pretty modern and are in 64 Bit it makes no sense to stick with "32 Bit Only".
It means that any modern application which starts development now and works by Microsoft Guidelines is out of the question as far as your policy.
Again, makes no sense and won't scale to the future.
Any new application which will be developed for Windows from this day and will probably have 64 Bit only version.
Moreover, I'm pretty sure we'll see more and more applications being 64 Bit only form now on (Adobe applications, MATLAB, etc...).
I see the logic to offer 32 Bit when you can.
I don't see the logic rejecting 64 Bit when there is only 64 Bit.
Nearly all apps including new apps are built for either 32-bit only or 32&64-bit. 64-bit only is exceedingly rare - and only used by very niche apps with small userbases - and will fail to work on maybe 10-20% or more of Windows machines. Case in point here is a very small app using very oddball tech (and a very old version of said tech for some reason) by a developer who is not a Windows developer, which is why the Windows builds suffer compared to the others.
Normal end users have NO IDEA whether they're running 32-bit or 64-bit. None at all. Don't assume because you or I do that everyone does. Everyone is not like us. Just because you have the tech and the money to have that tech doesn't mean everyone does. Lots of people have those low end laptops or older machines that upgraded from Windows 7 32-bit and remained 32-bit because that's the upgrade path. There's no reason to exclude them because '64-bit is the future'. We can - and do - easily serve both.
You have a hardline stance for 64-bit only. That's fine for you. But that does not serve us in our goals of making apps friendly and universal so everyone can use them. You or another dev are free to make a test version of this particular 64-bit only app and post in the forums and keep it up to date. It won't be released as official until the publisher is able to fix their build process. It's likely someone will assist them with it at some point.
Sometimes, the impossible can become possible, if you're awesome!
Could you show a newly developed application (Last 3-5 Years) which has no 64 Bit Support?
I can show you many which dropped 32 Bit support.
Your choices make no sense in real life.
There's is an easy test, publish 64 Bit Version and 32 Bit, let's see which is more popular.
I'm putting 1000$ in donation if the ratio will be below 60:40 for 64 Bit version.
Where both versions has the same exposure on the first page.
Users of Portable Apps are much more advanced than average.
Most of them use modern OS and prefer 64 Bit versions of the applications.
And your saying about 64 Bit versions being slower is just wrong, very wrong.
I gave you examples of application who drop support for 32 Bit.
Google Recommends 64 Bit Version (2014, today it is the default):
http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html
It is more secure!!!
You've already asked and the question has been answered. You may disagree with the answer, but your opinion on what is important doesn't make my opinion on what is important incorrect. We won't be abandoning users that run 32-bit Windows. That is a final answer on that point.
There are more users of 32-bit Windows than you think. Consider Steam... who has users that are *much, much* more technically savvy than average and have machines *much, much* more expensive and powerful than average... where a full 10% of the userbase is running 32-bit Windows. And that's on Steam as of 13 days ago. In the general population, the percent that run 32-bit is much higher.
64-bit apps only perform better than 32-bit apps for specific CPU-intensive things that require the larger register space. That and access to over 2GB of memory are the only real benefits to 64-bit apps vs 32-bit apps. This is very different from the move from 16-bit to 32-bit where there were big architecture changes along with it. 32-bit to 64-bit is much more subtle... and far more important for the OS (yay increased security and more RAM) than for the apps.
When CPU-intensive things are common, I package the 32-bit and 64-bit versions of an app. 7-Zip, for instance, it makes about a 9% difference in speed when compressing very large archives. That's about the largest difference you'll see in 32-bit vs 64-bit versions of an app. Most people won't compress archives big enough for them to take multiple minutes to finish... where the 9% would make a bigger difference... but some will. Browsers, on the other hand, generally have no difference in performance in day to day usage. Even on purely synthetic benchmarking tests, there's often only a marginal difference.
Here's a comparison from January on 32-bit vs 64-bit browsers: http://www.ghacks.net/2016/01/03/32-bit-vs-64-bit-browsers-which-version...
You'll note that the 64-bit versions of Firefox, Pale Moon, and Vivaldi all use more RAM and perform a bit slower than their 32-bit equivalents. Only Google Chrome has marginally better performance. But not really enough for an end user to notice when browsing. Most apps it makes no noticeable difference at all to the end users. Which is why the majority of apps are offered as 32-bit only. The majority of apps in our app directory have no 64-bit build available from the publisher at all.
It's worth noting that we currently ship Firefox as a 32+64-bit app in stable and beta and will soon for dev and nightly. Chrome as well (as noted 64-bit is a test at the moment). So for the small percentage of users that access a site or game that will make use of the few extra % of performance afforded a 64-bit browser, they'll have it.
If you wish to continue arguing this point, please create a new post in the forums. We've gone off topic enough in this thread.
Sometimes, the impossible can become possible, if you're awesome!
Toshiba Laptop Win 10 64 bit VM of 7 init 32bit
HP Stream 32 gb ssd WIn 10 32 bit
Lenovo Mix 64 gb ssd less than year old WIn 10 32 bit
HP Laptop Win 10 64bit
This is not counting a Win 7 Dell still usable running 32 bit ort he VM of Win 10 preview fast line which is 32 bit. ans an Asus netbook on XP still( Yes I plan to upgrade to 10 but will be 32 bit)
So effectively going only 64 bit Knocks me off of me down to two systems I can use and 6 I can not?
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
Again, I never suggested drop 32 Bit versions so I don't understand what's your point.
There is an application which is 64 Bit only (As most applications which will be developed from now on).
It won't run on your system anyway since you don't have 64 Bit system.
Yet, probably more 65% of Windows users have 64 Bit version and might would like this application.
Having a policy of "We only work with 32 Bit Applications" make no sense in a world were many programs are 64 Bit only.
Why not have applications which are 64 Bit only?
They are irrelevant for 32 Bit users to begin with so they can be part of the package with support for 64 Bit only.
Supporting 32 Bit only programs means that any new program which its development started in the last few month own't be supported.
Does it make sense?
Is this the 32 Bit Conversation Island?
A much more balanced policy would be we support all kind of applications.
When only 32 Bit version available, this is what served.
When both 32 Bit and 64 Bit versions are available we serve what the user chose (Let's say he can configure that).
When only 64 Bit version is available the user is served with that (Only if he uses 64 Bit Package of PortableApps let's say).
This policy would make much more sense in my opinion.
Any current 32 Bit user won't see any difference.
64 Bit users will enjoy the option of having 64 Bit only programs in their Portable form.
Due to fact I use one 500GB USB drive for all my files then move drive from machine to machine as needed so again some programs I would have would work on 2 of 8 machines and I would have to remember? IN reverse there is not a single 32 bit program that would not work on 64 bit .machines
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
Again,
I didn't ask to drop 32 Bit applications.
I asked to add support for people who wants only 64 Bit applications.
My suggestion is:
1. There will be 2 versions of PortableApps packages, one is 32 bit the other is 64 bit.
2. Applications which are available only as 32 Bit will be available only in the 32 Bit package.
3. Applications which are available both as 32 Bit and 64 Bit will be available on both packages.
4. Applications which are available only as 64 Bit will be available only on the 64 Bit package.
One could make it even smarter and more flexible.
For instance, there would be an option to "Prefer 64 Bit versions".
Then for any program I chose to install if there is 64 Bit version this is the only one which will be installed.
If only 32 bit available it will be installed.
Simple, very simple...
Unfortunately, the vast majority of Windows users overall have NO IDEA whether they are running 32-bit or 64-bit. Even among a more tech-savvy audience like ours, it's still 25-50%. Why? Because we don't just have super tech savvy users. We have all kinds of users. Including users who regularly use machines that are not their own and that they have no control over. Please stop assuming all users are like you. They are not. Again, you are not representative of all users. Nor am I. Nor is any single users. Once you stop assuming and getting upset with people for not having the same tech and needs that you do, it's much easier to see the bigger picture.
Expecting users to know whether they have 32-bit and 64-bit is a bad idea. Forcing users to use two different versions of an app depending on which machine they are on with separate sets of data is dumb. A lot of our users use both 32-bit and 64-bit as they move between home and school or home and work. Heck, even vf2nsr, one of our own developers, has a mix of 32-bit and 64-bit machines that he himself owns. As do I for that matter (ASUS T101 detachable, I sold the HP Stream 7).
So, we will not be doing separate apps. We will be doing one single app that runs on every machine, both 32-bit and 64-bit. That app will usually be 32-bit only because the vast majority of apps only provide a 32-bit build. Of apps that provide both, the majority see no performance improvement on 64-bit and will only be bundled as a 32-bit app. When there is a noticeable performance advantage that will affect the user's use of an app (7-Zip's 9% improvement for instance) or when an app requires both for drivers (like in PeerBlock or JkDefrag) we will provide a dual mode app that automatically runs the 32-bit or 64-bit version.
Again, this is the final answer on the subject. Your opinion may differ based on your needs or your friends'/colleagues' needs, but that does not make it correct. We serve the needs of a wide array of users many of whom are very different from you. Excluding a big chunk of them... even 10%... to meet your specific needs is simply not an option. There is no need to continue arguing the point as it is off topic in this app request thread and as you have a definitive and final answer on it.
Sometimes, the impossible can become possible, if you're awesome!
The fact that no PortableApps user has come in to support your argument for the inclusion of 64-bit only apps should perhaps tell you something.
Still, there is one solution to your request. If you really want this 64-bit only app converting to the PortableApps format then, instead of spending an endless amount of time pursuing an interminable back and forth argument, why not try investing the same amount of energy in learning how to make Windows apps portable and D.I.Y. A tunnel-visioned focus on arguing that someone else should do it for you, or that an organisation (PortableApps.com) should change it's established publication policy, simply because a tiny proportion of OpenSource/Freeware Windows apps are currently available as 64-bit only; and because you want this specific application is not productive. With specific regard to your suggestion of a "Simple, very simple... " alternative approach, perhaps you might like to sit in a darkened room for some time and calculate the production time that would be required, on the part of both the wider 'team' of volunteer developers who need to regularly maintain their apps; and the PortableApps Team in doubling up the production of releases and maintenance of updates where both formats are available. Perhaps you might also try to think constructively about who is going to resource (pay for) the additional costs involved, that you seem to be so keen to impose on an 'organisation' that is largely dependent on community donations to support its work.
And, before you get the impression that I'm some sort of Luddite, who is resistant to the take up 64-bit Operating Systems/Software, the only access I have to 32-bit OS's is when I use work-based or publicly accessible IT systems, which in my experience are mostly still using 32-bit versions of Windows. Personally, I have regular access to 3 different Macs and 2 Windows PCs, all running 64-bit Operating Systems, with a mix of 32 bit and 64bit apps. - Yes, some native Mac OS X Apps still run in 32-bit mode, or can be configured to run in either 32-bit or 64-bit Mode, even though all Macs are 64-bit; and the less knowledgeable seem to believe that Macs exclusively run 64-bit software. In more than 5 years of 64-bit OS usage, the only substantial advantage I have ever seen is in the amount of physical memory 64-bit systems can address and therefore their capacity to run more memory hungry apps at the same time without slowing down performance too significantly. Also, in my experience, the practical performance difference between 64-bit and 32 bit versions of the same apps on 64-bit systems in most real life scenarios, appears to be negligible/not noticeable; and where 64-bit only Windows apps have been released by developers it usually indicates that they simply no longer have access to a 32-bit version of the relevant OS to compile the application on rather than there being any perceived/stated performance advantage with 64-bit.
The way you wrote things is not fair as you suggest that unless someone does something by himself he can't suggest anything.
So I want argue with "Do it your self instead of write here...".
I did what I could and thought best for the project and regardless. I think it is OK to share my point of view.
Of course others can have other point of view and it is all OK.
I wish the site owner would share some data about how many times the applications are downloaded by a 64 Bit users and by 32 Bit users.
Since Chrome 64 which is hidden and you need to make efforts to download is more popular than 8% of the other 32 Bit application I conclude 64 Bit applications are preferred by many.
Moreover, in the case of Chrome, Google itself recommend it and says it is safer which is crucial.
This had already been fully discussed in another thread in addition to the posts you had made in the unrelated Firefox x64 thread making 3 separate topics where you were discussing this. I've combined everything into this single thread to keep it from bleeding elsewhere.
Let me address this point by point again here as a summary:
1. Most users have no idea if they are using 32-bit or 64-bit. Asking them to determine it is a bit silly, especially for our many non-technical users. Yes, we have lots of non-technical users.
2. Many users use multiple machines and use a mixture of 32-bit and 64-bit. Even many developers like vf2nsr and myself have both 32-bit and 64-bit machines. 6 out of his 8 machines are 32-bit.
3. Users of multiple machines of different types should not be forced to manage multiple versions of a given app with separate settings, preferences, bookmarks, etc. That defeats one of the primary features of our apps which is that they 'just work'.
4. Alleviating point 3 by releasing a 32-bit only package, a 64-bit only package, and a combined 32+64-bit package would be an inefficient use of our time and would cut into time for platform development, tool enhancement, and new app packaging.
5. The idea that there are lots of 64-bit only apps that the PortableApps.com community is missing out on is a straw man. This discussion arose out of a single app, Abricotine, which has a 64-bit Windows build but no 32-bit Windows build. The only reason this is currently the case is because the developer is not primarily a Windows developer (it's a cross platform app), the 32-bit Windows build they used to provide broke, and they don't currently know how to fix it. They have an open bug to address it.
6. Most 64-bit apps perform the same as their 32-bit counterparts with no noticeable improvement to the user at all. Many even perform worse. Most 64-bit web browsers are slower than 32-bit web browsers.
7. 64-bit apps consume more memory than their 32-bit counterparts.
8. The vast majority of Windows software is 32-bit only and doesn't even have a 64-bit build available. This is partially due to points 6 and 7 but also due to point 1, making things more confusing to the end user.
9. We already make available a dual mode 32+64-bit version of apps when it makes sense. Either when an app requires it in the case of drivers for the host OS (PeerBlock, JkDefrag, etc) or when there is a noticeable real-world improvement in speed due to an app being CPU-restrained (example: 7-Zip's 9% speed increase in compressing very large archives). These dual mode apps work on both 32-bit and 64-bit machines and use the same set of settings. They're often not even a full twice the size of a 32-bit only app due to the way we combine them and move shared files (translations, etc) between the two versions of the app in the same package. PeaZip, for example, has 16.6MB of files extra to make it dual mode despite the fact that a single mode version of the app would be 25.1MB.
Remember, PortableApps.com doesn't just serve you. Or users similar to you. We serve all kinds of users. We're not going to abandon a couple hundred thousand of our users because we should be thinking only about the future. That's not how we work and that's not the point of PortableApps.com. Our goal is to serve all of our users, many of whom are very different from you and have very different needs.
Lastly, I wanted to add one important note to point 5 since it seems to be what Drazick is most concerned about. If we are, in the future, in a situation where there are a bunch of good Windows apps being released as 64-bit-only, we'll re-examine this situation, even in spite of all the other above points. Right now, though, it's a bit of a moot point because there simply isn't much Windows 64-bit-only software at all - Abricotine's broken Windows 32-bit build notwithstanding - let alone a bunch of really great apps that make sense adding to our directory.
Sometimes, the impossible can become possible, if you're awesome!
John,
It's your project and you did amazing job.
But it seems you don't read what I write and keep coming with arguments which are irrelevant.
1. Make 32 Bit the Default. Unless the user does something actively with 100 warning before he can switch to 64 Bit.
This means you can stop with the argument "It won't work, people doesn't know, etc..." unless you know what you are doing and chose to be served with 64 Bit you'll be served with the default 32 Bit.
You know what, don't provide 64 Bit on the launcher, could you just provide as separate download as you do in Chrome.
The statistics of Chrome 64 Downloads shows there are many users who chose 64 Bit.
2. Stop with the argument you'd lose people to support 64 Bit.
It's this or that, you can let people chose, you only extend the choices. So this argument has no hold in reality.
3. Can you share statistics on the configurations people use with Portable Apps?
4. I don't want to go into the debate of which is better. Though you have contradicting arguments (Once you want less storage space, yet on the other you bundle 32 + 64 instead of only one). There is nothing inherently faster on 64 or 32 bit. Yet Intel and MS put much more emphasis on optimization in the 64 Bit path and this is their recommendation. Anyhow, you keep ignoring that the producers themselves suggest the usage of 64 Bit. Google states that Chrome 64 is much safe. If I want to be "Unfair" in my arguments, I would say, do you compromise the safety of your users?
Best thing, give the users to chose, let see what happens.
Anyhow, I appreciate and benefit your project and thank you for your efforts.
Thank You.
Your main and first point in your post was this:
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.
Sometimes, the impossible can become possible, if you're awesome!
I see the extra work and it is your decision if to put effort into it.
Again, if you read what I wrote, there would be no need for 32 + 64 Packages only one 32 and one 64.
Unless the user is doing something actively, he will get the 32 only package.
Since many applications here are pretty basic I guess for most, no need for 64 Bit.
Don't compare Chrome 64 vs Chrome 32.
They don't get the same exposure level and I guess some of the download numbers are people who use your launcher.
Think there are more users who made the extra effort to use 64 Bit given it is well hidden than the users of ~60% other applications you update and maintain.
For me it a justification to at least much effort in keeping Chrome 64 as separate than dealing with any other of those 60% products.
The question is simple, is there a real logic behind just saying no for 64 Bit only applications?
Is there a reason why not offer the user (In very well hidden and maybe after many "Do you understand..." alerts) 64 Bit only version?
Besides the extra work, which I agree is not something to oversee, you only gave the reasons:
1. Not working everywhere.
2. Might confuse the users.
Regarding '1', it is simple, make the default 32 Bit, make sure the user make extra effort to get 64 Bit.
Moreover, if we're talking about 64 Bit only applications (Not one as you wrote, Adobe won't support 32 Bit anymore, MATLAB is 64 bit only as well), well, they never worked on 32 Bit systems to begin with so users of 32 Bit Windows didn't loss anything, they didn't have it to begin with.
Regarding '2', it is easy to hide and make sure the user makes a lot of effort to chose 64 Bit version.
did you get many support emails for users who mistakenly downloaded Chrome 64 and didn't understand why it doesn't work for them on 32 Bit windows?
Can you share the numbers on that?
So those 2 arguments can be handled very well probably with no issues on your side.
Regarding the efforts, well it seems you have more demand for Chrome 64 Bit than many other applications you put effort into.
So it doesn't look like it will be a wasted effort.
Again, it is your project, I love it, I appreciate it.
I use it on all the applications besides Office on my computer.
Any choice you make I respect, yet those arguments above are not valid.
Thank You.
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.
Sometimes, the impossible can become possible, if you're awesome!
John,
Do you really read what I write?
Those who walks with USB and wants maximum compatibility won't notice the difference.
So I still don't understand your case.
My case is, on default, which 90% of your users won't change no change will happen for them.
For those who care and want 64 Bit and according to numbers (See Chrome 64 numbers, again, it is well hidden and still gets those numbers) there are more of them then for instance the users of:
1. Powder Toy Portable
2. Sylpheed Portable
3. MicroSIP Portable
4. Miranda IM Portable
5. AkelPad Portable
6. FocusWriter Portable
7. Krita Portable
8. SuperTuxCart Portable
9. OpenTTD Portable
10. CherryTree Portable
11. MediaInfo Portable
12. Transmission Portable
13. Password Safe Portable
14. FreeFileSync Portable
15. GnuCash Portable
16. Telegram Desktop Portable
17. Sigil Portable
18. Marble Portable
19. Miranda NG Portable
20. RedNotebook Portable
21. GPG Plugin Portable
22. Ghostscript Portable
23. Iron Portable
24. CuteMarkEd Portable
25. Battle for Wesnoth Portable
26. The Legend of Edgar Portable
27. Scribus Portable
28. VeraCrypt Portable
29. grepWin Portable
I could add much more.
So to conclude things, and please address those:
1. My suggestion won't hurt anyone or change the habits of anyone.
Unless the user will actively do something everything stays the same.
2. It means more works yet it seems the demand exceeds the demand to many other applications on the site hence it make sense to add it.
It is as simple as that.
So examples why it won't on the computer of Person A on home and Person B on work are irrelevant because I'm suggesting removing any capability of PortableApps package, I'm only asking to extend it to fit other users habit.
Thank You.
Having direct contact with Jendrik as well as being the portable apps developer of Rednoteboook there is no 64 bit version.
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
I've already addressed every point above. Your request is denied due to the multiple reasons outlined above. As stated over and over, this answer is final at present. You may disagree with all of us posting here, but that does not change the answer. There is no need to continue replying.
Sometimes, the impossible can become possible, if you're awesome!
@Drazick
at one point, you mentined real life.
So here just some facts. Well I am personally not a reference, but I have currently privately and in my family 21 PC, 3 of them are capable of 64bit and have therefore 64bit windows on it.
At work, technology company, dealing mainly with defense technology, we have the intranet with 64bit workstations, but there no portable apps would work.
All other PC or PC like devices I have to work with, have no 64bit capability. Just my testbenches and associated equipment have all 32bit windows or in some cases 32bit Linux on it. Some 20 devices.
At job no.2, humanitarian aid org. This may, we received new notebooks, w7 64b. But there are hundreds of machines in the field with 32bit, no way to replace them all. Much more 32b then 64b in operation just now.
And we are not end of the world here, kind of middle of europe.
So your real life observations are somehow distorted. You can not just think that all you have to hand to use should be standard for all the rest of the world. The world is bigger then you think. And also this rest of the world is interested on having things like portable apps probably.
Currently, on my usb stick, I do remove the 64 bit portion of the firefox for exmaple, as there is no real advantage for me to have both versions ready when the 32b does work well on most computers I am able to meet currently.
Otto Sykora
Basel, Switzerland
Tell you the truth, it seems no one reads what I'm writing.
My agenda is add 64 Bit version (As opposed to add 64 Bit versions and remove 32 Bit).
There is a big difference and in your case nothing will happen.
So what's the point you're raising?
We are reading your posts are you reading ours.
Plainly put you r AGENDA does not fit into the scheme or overall direction and goals of the Developers, owner, or the majority of the users of this application nor the applications it supports.
No means NO and Yes means Yes.
Perhaps your agenda needs to be taken elsewhere?
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
@Drazick
in post 25 you are listing number of programs you seem to suggest to become 'dual', meaning 32 and 64.
The use of it is that it takes simply double space on usb drive, on hard drive or on server. That is about all.
No practical use for it.
Since only minority will be able to even run the 64bit, the result will be bloatware just taking double space , double time to download. So pls understand that majority of the users do not want this. Other users do not want suffer just because one user has some strange exotic wishes.
Otto Sykora
Basel, Switzerland
I think you missed what I wrote there.
Moreover, you miss interpret my intention, hence I guess I was not clear enough.
First, the list I wrote is a list of programs maintained on PortableApps which are less popular than Google Chrome 64 (May I remind you that Google Chrome 64 Bit is deeply buried, probably would be much more popular if its exposure was better).
This is to show that more people want and use 64 Bit exclusive program than ~65% of the other programs on the site.
The conclusion I make from this is that if I spend time on something relative to the demand then creating 64 Bit versions of some product is more efficient than supporting some other programs.
Regarding your other saying which I never said.
I never wrote to bundle 32 Bit and 64 Bit together.
I asked to let the user whether to use 32 Bit (The default) or 64 Bit.
John said many users won't know the difference and I suggested to make 64 Bit as Opt In.
Namely the user will have to do something actively (And be warned about it) to have 64 Bit version.
Hence most users, unless doing something actively, won't see a difference (Not in size or compatibility).
I think bundling 32 and 64 But together is having the worse of both worlds.
So again, please read carefully my posting and suggestion.
John and others miss interpret it already and hence argued invalid arguments.
>This is to show that more people want and use 64 Bit exclusive program <
most people will not be able to use it anyway, as they have 32bit operating systems running. So this will be definitely very small minority currently. Their desire for 64bit apps is probably mostly pointless.
We have also small number of people who 'need' 500 hose power car, thought we are allowed to drive maximum 120km/h on a highway.
So even in case of 64bit, it is not that this small minority needs it, it is they want it. They will not be able to state the reason for such demand however.
This might change in few years, but currently to have apps for 64bit only would be a pain, as it would mean to search for a computer able to use it.
So be happy and use what does exist or check the development site here and 'make your own'
Otto Sykora
Basel, Switzerland