Download link for x64 software versions

[taotra]

I'd like to propose the following suggestion:

If there are direct software download links on PFC, then there should be an additional link if there are separate x64 versions available. Many of us have now migrated to Windows 7 (mostly by default) and that tends to be x64.

A good example are the Nirsoft programs. The download link points to the standard 32-bit versions, but by now many x64 versions are available (FileTypesMan, CurrPorts, ShellExView, etc.). However, you only know about it if you actually go to the website.

[Emka]

Don't some entries already at least mention that x64 versions are available?

[guinness]

Updated: FileTypesMan, CurrPorts & ShellExView. Thanks.

From what I can tell users are updating the entries when an x64 bit download is available too. Obviously this is going to be a long process, so for now I would recommend that users with less than 50 forum posts, to post that there is a x64 version available. Of course those with over 50 forum posts can edit the entry directly.

However, you only know about it if you actually go to the website.

I would expect most people/users to visit the developers website and not rely just of the recommendation of TPFC (sorry TPFC )

[taotra]

Thanks, guinness,

By the way, here's a link to all the Nirsoft x64 programs:

http://www.nirsoft.net/x64_download_package.html

[guinness]

Thanks. I will have a look at this later.

[Andrew Lee]

I would expect most people/users to visit the developers website and not rely just of the recommendation of TPFC (sorry TPFC )

Actually, that's what I expect too!

I think in the early days of TPFC, they was only one link to the app home page i.e. it didn't even have a download link. After too many queries of "how do I download this?", I added the download link, but I am still incredulous that people don't even bother to visit the app home page to find out more about the app that they are going to use!

Anyway, I am still struggling with how to add the 64-bitness info without too much clutter and overload.

There are potentially three alternatives:

1) Add it to the description, as it is now.

2) Add a flag to the sys requirements field that indicates "x64 available" eg:

System Requirements: WinXP / Vista / Win7 / x64 available

3) The entire kitchen sink. That means:

* x32 (x64 compatible)
* WinXP-64
* Vista-64
* Win7-64

plus whatever else I have missed.

Which one?

[JohnTHaller]

I think it may make more sense to only indicate when an x64 version is required on 64-bit Windows. Some utilities are like this. In general, there's no real performance benefit to using the 64-bit version of a given app, so most major apps are 32-bit only and will be for some time. The exceptions are CPU-intensive apps (7-Zip, photoshop, video processing, etc). In those cases, it can be a nice addition, but if you go 64-bit, chances are your app won't work outside your home PC as only 46% of Windows 7 installs are 64 bit, only 11% of Vista and virtually no Windows XP.

That's why I decided to stick with 32-bit for PortableApps.com for now, to ensure everything runs everywhere. Except for apps that require both versions to work everywhere (like JkDefrag/MyDefrag) or apps where there is a decent performance boost without a huge size increase (7-Zip, which gets a ~10% performance boost with some operations at a cost of an additional 2.8MB). In those cases, the PA.c package include both the 32-bit and 64-bit versions and the launcher automatically picks the right one. It even does some neat tricks like moving support files (translations/help) back and forth between 32-bit and 64-bit folders to keep size of the app down.

More details are here: http://portableapps.com/node/24371

[m^(2)]

I think it may make more sense to only indicate when an x64 version is required on 64-bit Windows. Some utilities are like this. In general, there's no real performance benefit to using the 64-bit version of a given app, so most major apps are 32-bit only and will be for some time. The exceptions are CPU-intensive apps (7-Zip, photoshop, video processing, etc).

There are many more cases really. Wow64 redirection crap makes using x64 highly desirable for many programs and somewhat desirable for almost all of them. Ones that use drivers need it too. And obviously, memory intensive ones too.

[SYSTEM]

@m^(2)

http://www.portablefreeware.com/forums/ ... 280#p23280

And I'm still wary about putting .NET apps here - because I *believe* there are too many cases when their portability is insufficient, yet no indication is clear enough, some people will always miss it's drawback. I believe that the PFC database would be better w/out because even a noob that's tired and in a hurry will always get full quality product, one that always works as expected (except for bugs...but they are devs' stuff). Yet I'm not as much against putting .NET apps here as I was before because I see that it's popularity increased, so problems will be somewhat less common.

That's all good and well, besides the fact that sometimes pure portable applications doing what you want don't exist. Or maybe the managed alternatives are better. I say the users should have the right to choose based on their perceived trade-off between portability and functionality. You could put a big red warning saying "not completely portable" or some such, but ignoring .NET applications altogether is burying your hand in the sand.

Yes, there are many ways to do it, yet each can be missed. I thought about a modal Click-Ok-To-Continue window with a huge red exclamation mark as the strongest assurance that user noticed the warning, yet people often click OK w/out reading. The only solution that works for all is to avoid problematic content. It does reduce database content and my opinion that it's better is not very strong, even though I never found a .NET app w/out a better unmanaged equivalent.

Do you think download links of 64-bit binaries need a similar warning? .NET is much more common than 64-bit versions of Windows.

[m^(2)]

@m^(2)

http://www.portablefreeware.com/forums/ ... 280#p23280

That's all good and well, besides the fact that sometimes pure portable applications doing what you want don't exist. Or maybe the managed alternatives are better. I say the users should have the right to choose based on their perceived trade-off between portability and functionality. You could put a big red warning saying "not completely portable" or some such, but ignoring .NET applications altogether is burying your head in the sand.

Yes, there are many ways to do it, yet each can be missed. I thought about a modal Click-Ok-To-Continue window with a huge red exclamation mark as the strongest assurance that user noticed the warning, yet people often click OK w/out reading. The only solution that works for all is to avoid problematic content. It does reduce database content and my opinion that it's better is not very strong, even though I never found a .NET app w/out a better unmanaged equivalent.

Do you think download links of 64-bit binaries need a similar warning? .NET is much more common than 64-bit versions of Windows.

Well, I don't know, I didn't give it much thought because as soon as my thoughts get to how have MS fucked up the 64 bit transition, anger makes me stay at this topic.
Really, the only way I see portable x64 software now is with a launcher that has both x86 and x86-64 and chooses the right one at startup. Every other option is bad. But it's on devs' heads (WTF not MS devs' only?), not database maintainers. So yeah, I think it's gonna cause a lot of troubles too, even more than .NET. So yeah, I think that a big red warning or, better, a question 'Do you really want it? Read the consequences here. [x] Don't prompt me again.' would be good.

BTW the 'You may embed only 3 quotes within each other.' forum message is very annoying.
And I just found that in the post you quoted I wrote 'hand in the sand'. Dammit.

ADDED: thanks for bringing my quote from the other place. These 2 cases are so close...yet they were not close at all in my head.

[JohnTHaller]

Really, the only way I see portable x64 software now is with a launcher that has both x86 and x86-64 and chooses the right one at startup. Every other option is bad. But it's on devs' heads (WTF not MS devs' only?), not database maintainers. So yeah, I think it's gonna cause a lot of troubles too, even more than .NET. So yeah, I think that a big red warning or, better, a question 'Do you really want it? Read the consequences here. [x] Don't prompt me again.' would be good.

I'd agree on having dual packages being the best option. Whenever there is an app that requires both, we'll be building it that way at PortableApps.com, so if you find an app that requires that, just let us know and we'll build it that way with one of our dual-mode launchers. Even the PortableApps.com Launcher (which is configurable entirely via INI and requires no coding) is getting dual mode x86/x64 support in version 2.1 which should drop this week, so you'll even be able to do it yourself for your own apps pretty easily.

For apps where it's a matter of a performance boost, we'll evaluate them on a case by case basis (performance boost vs. install size increase to have both versions). We do move stuff like help files, translations, etc back and forth between the x86 and x64 versions to save space, but even with that, some apps the install size increase just isn't worth the small performance increase.

For non-PAF apps in the PFC database, you could have an (x64 download) link next to the standard one where appropriate and do a warning as m^2 suggested (with a 'don't show this again' option for logged in users', of course). As for dual mode apps (x86 and x64) like we do with 7-Zip and JkDefrag, I'm not sure if a change to the listing itself is needed or just a simple mention in the description is sufficient. For now, I just mentioned it in the description of 7-Zip Portable here on PFC.

[webfork]

At least for the next year or two, I don't think we need a new link or a new category and here's why:

1. Our audience isn't focused on speed. I can't remember a thread that concerned trying to draw extra speed out of a software or computer, a common topic on computer software forums like this one. Because 32-bit is far more portable, it should remain our focus.
2. The benefit is minimal. As has already been stated, only a small percentage of applications really use and benefit from 64-bit. Processor-heavy applications do not comprise the PFWC database and plug-in based software like Microsoft's own office suite has had problems with 64-bit.
3. 64-bit does not yet dominate the Windows operating system. Even when they come into the majority, most internet cafe / public computers will likely remain 32-bit, so it deserves our focus.

In summary: few machines, few users here on the site, and few applications really needing 64-bit means that this issue is low priority. I'd say a note on the entry about 64-bit availability is all that's necessary. As 64-bit ONLY applications start to appear, we can list a warning in the "requirements" section of an entry.

This is not my preference -- I want x64 everything. Its just the current state of technology.

[m^(2)]

At least for the next year or two, I don't think we need a new link or a new category and here's why:

1. Our audience isn't focused on speed. I can't remember a thread that concerned trying to draw extra speed out of a software or computer, a common topic on computer software forums like this one. Because 32-bit is far more portable, it should remain our focus.
2. The benefit is minimal. As has already been stated, only a small percentage of applications really use and benefit from 64-bit. Processor-heavy applications do not comprise the PFWC database and plug-in based software like Microsoft's own office suite has had problems with 64-bit.
3. 64-bit does not yet dominate the Windows operating system. Even when they come into the majority, most internet cafe / public computers will likely remain 32-bit, so it deserves our focus.

In summary: few machines, few users here on the site, and few applications really needing 64-bit means that this issue is low priority. I'd say a note on the entry about 64-bit availability is all that's necessary. As 64-bit ONLY applications start to appear, we can list a warning in the "requirements" section of an entry.

This is not my preference -- I want x64 everything. Its just the current state of technology.

I don't agree with performance being neglected here. It's certainly not a top focus, but a quick search brings 994 matches for 'speed' or 'performance' or 'fast'
Some are repetitions (that is: quotations), but it's still a rather big number, for comparison 'portability' gives 674 matches. I'd rather try 'portable', but the forum disallows it as a common word.

Also, you seem to have missed my points - Wow64 and memory. When running x86 on x86-64 system the following happens:
All tools that concentrate on file systems (managers, indexers, analysers etc.) are hugely crippled.
Registry manipulation apps are close to useless.
All programs that let you select a file or directory for whatever reason, misrepresent directory structure when doing so.

And memory - 7-zip needs circa 575 GB of RAM to process a BluRay image with the largest dictionary that makes sense. For practically everybody this is unachievable, but up to this point bit helps. And the x86 version is limited to 2-3 GB. And I remember seeing quite a few threads regarding various size reductions in here...

[webfork]

you seem to have missed my points - Wow64 and memory. When running x86 on x86-64 system the following happens:
All tools that concentrate on file systems (managers, indexers, analysers etc.) are hugely crippled.
Registry manipulation apps are close to useless.
All programs that let you select a file or directory for whatever reason, misrepresent directory structure when doing so.

I was under the very wrong impression that most 32-bit applications would run normally on a x64 system. I've heard about driver issues and a few x64 incompatibilities, but I had no idea Microsoft, in your words,

fucked up the 64 bit transition

... so badly. The only Microsoft answer to this seems to only be "run Virtual PC," a very non-portable solution.

The fundamental assumption of my argument of why we should focus on 32-bit was compatibility. Since that's obviously not true, I'd have to say a category of either x64-capable applications or compatible apps would make sense.

[JohnTHaller]

I was under the very wrong impression that most 32-bit applications would run normally on a x64 system.

Most 32-bit applications work perfectly fine on an x64 system. The only exceptions are file managers that are 64-bit unaware (which generally won't have a 64-bit version either), things that require drivers (which are few and far between - think disk defragmenters or network analysis tools - and generally not portable anyway and, when they are, require admin rights and separate drivers for 32 vs 64... which we package together at PortableApps.com), and similar programs.

All other regular software (browsers, office suites, IM, graphics, video players, audio players, photo editors, games, development tools, etc etc) work just fine with the 32-bit version running on 64-bit Windows.

I run 64-bit Windows and have virtually no 64-bit apps. All my apps work just fine.