64-bit software has been in the news a bit more lately as the number of people using a 64-bit version of Windows has been increasing. Windows 7 has seen a 46% install rate of the 64-bit version compared to only 11% under Vista (and less on Windows XP). As a result, many people have been wondering how 64-bit software fits into the concept of portable software. We've had a few discussions in the forums amongst the development staff and users and come to what we think are the right conclusions. And, since we just released our first hybrid 32-bit/64-bit app that didn't necessarily need to be (see: 7-Zip Portable), I thought it would make sense to get our conclusions all down in one place for those that are interested.
Read on for all the details... | Subscribe to John T. Haller's blog
Wait, what *is* 64-bit software?
If you know the answer, feel free to skip ahead. If you're confused, don't worry, most people don't know what it is either. When people say something is 32-bit or 64-bit, they're referring to the smallest unit of information that can be processed on a machine (the bit, a 1 or a 0) and how many are dealt with at the same time within the PC and operating system. Basically, how software is working with data internally. A compiled piece of software is written to work with one or the other, but not both. And there are PCs out there that are either 32-bit or 64-bit and have either 32-bit or 64-bit Windows on them. (f you're curious what you have, just right-click on Computer in your Start Menu and click Properties (in Windows Vista or 7). Look for the System Type line.
Most software, however, is 32-bit. Why? Because 64-bit versions of Windows have a feature called Windows 32-bit on Windows 64-bit (WOW64) that allows them to run 32-bit versions of software in addition to 64-bit software. 32-bit versions of Windows, on the other hand, can't run 64-bit versions of software, even if the CPU in the PC is a 64-bit CPU. So, because of this, most popular software like Firefox, Pidgin, OpenOffice.org, Microsoft Office and others are distributed only as 32-bit versions for Windows.
64-Bit Portable Software: The Pros and the Cons
Like anything, 64-bit software has its pros and its cons. With portable software needing to move from PC to PC, these become a bit more pronounced. Keep in mind that we're not talking about 32-bit vs 64-bit OSes (64-bit pros like larger system memory and No eXecute bits don't really apply here) and that we're mainly concerned with the apps that most folks use. Let's run through them:
Pros of 64-bit Portable Apps
- Performance Increase - A few 64-bit applications that have been compiled to take advantage of 64-bit integers and the additional registers available will yield a performance increase. This performance increase is most pronounced in CPU-limited apps like CAD, audio and video encoding, compression, etc. Note that most software will see no noticeable increase in performance.
Cons of 64-bit Portable Apps
- Compatibility Issues - As mentioned above, 64-bit software can only run on a 64-bit OS running on a PC with a 64-bit CPU. A 32-bit version of Windows can not run 64-bit software, even if the CPU is 64-bit-capable. That means that if a given portable app is just the 64-bit version, it won't work on most PCs you encounter as the vast majority of PCs are running 32-bit Windows. Nearly all 32-bit applications will run just fine on a 64-bit OS, though.
- Larger Install Size - If you include both the 32-bit and 64-bit versions of a given app in the portable package, you wind up doubling the install-size of an app. This is an issue due to the fact that many people run portable software on their USB flash drives, so space may be at a premium.
- Larger Memory Footprint - 64-bit software will take up more RAM than its 32-bit equivalent due to the way information is stored.
- Plugin Issues - If an app is 64-bit, then any plugins it uses must also be 64-bit. This not only makes software more complicated for users, but you'll often find that a given plugin simply isn't available in a 64-bit variety.
The cons would seem to far outweigh the pros, so the answer should be simple: stick to 32-bit apps. There are always exceptions to the rule, though.
Exception 1: Some Apps Require The 64-bit Version on 64-bit Windows
Some software - particularly system tools - requires that the 32-bit version for 32-bit Windows and the 64-bit for 64-bit. A perfect example of this is JkDefrag Portable. This defrag software interfaces with the OS in a specific way and has separate builds for 32-bit and 64-bit Windows. Rather than having users need to worry about which version is which as they move PCs, we custom built a GUI and launcher that automatically launch the appropriate version for the current PC. That way, the user uses it just like any other app and, as we try to do with everything, it just works.
Exception 2: Some Apps Get A Good Performance Increase Without Becoming Huge
Some software does get a tangible speed improvement as a 64-bit app while at the same time not winding up with an excessively large install size. The perfect example of this is the newly-updated 7-Zip Portable release. This new release incorporates both the 32-bit and 64-bit versions of 7-Zip in a single package and automatically launches the appropriate one, just like with JkDefrag. Since 7-Zip uses the same localization files for both versions, we're able to keep just one copy. So, we end up with an app with all the functionality we want, but still clocks in at about 5mb installed. 7-Zip can see a 5% or even up to 10% performance boost when running the 64-bit version vs the 32-bit version. And working to compress large files is often measured in minutes, not seconds, so, the extra work on our end and couple extra MBs on the user's end makes sense as it can save users time in the long run.
The Best Approach For The Future
So, what's the best answer for portable app users? After much discussion, we've decided that, as a general rule, doing 32-bit-only portable software is the best approach for nearly all apps and nearly all users. They have low overhead, and they just work on every PC you come across everywhere you go.
When we encounter the rare exception like JkDefrag (which requires both versions) or 7-Zip (which benefits from both versions without a big install-size hit), we'll do one of our special hybrid versions so that the right version runs on the right PC. Apps like JkDefrag which normally require different versions will be one version that just works everywhere. And apps like 7-Zip will work everywhere and give you a little performance boost when you happen to be on 64-bit Windows. And it all just works with a single packaged portable app. The user doesn't need to change anything, and it works everywhere.
As always, we look forward to talking with the broader community on this. Other ideas and suggestions are welcome!
I hope everyone enjoys the bit of extra oompf that comes with the new 7-Zip update.
Until next time...
- John T. Haller's blog
- Log in or register to post comments
For some reason, when this was originally posted, comments weren't properly enabled. I've enabled them now. Sorry for the mix-up.
32 bit and 64 bit.
You seem to left out the fact that even though 32 bit is less in size and memory usage, that it loads the Syswow files into memory also to run and translate the 32bit to 64bit. Therefore to me, it is like running java platform on top of windows, where as, the handshake will slow it down because of the interpretations involved and more memory is being used than just the 32bit programming running. People need to understand that the Syswow files on a 64bit DVD OS for Windows setup actually is about 1 GByte more, thus when these files are installed that alone put a larger footprint on your harddrive and thus these files are also loaded into memory when you run 32bit.. Another thing is that 32bit programs only access 4 Gbytes of RAM and unless it is made aware of larger ram for usage will end up slowing your computer down by running too many apps that are 32bit even is you have 16 Gbytes Ram, 12 GBytes will not be used by the OS.
Niche, Syswow, 4GB, Very Old Topic
The case of running a portable app from a DVD you are describing is quite niche and, unfortunately, not one we support any longer. Some of our original apps like Firefox may still run from a read-only optical drive, but as optical drives are being phased out in consumer PCs, we no longer test for nor support this setup. Syswow is shared, so 32-bit apps don't encounter a penalty beyond the first one. The vast majority of our apps (and the vast majority of Windows apps in general) aren't even available in 64-bit builds, so most apps that most users are using are 32-bit. All of that is moot anyway, because the portable launcher (FirefoxPortable.exe or similar) is a 32-bit EXE for every single app, so the Syswow is already being loaded for you launching that app. Even if you're running a 64-bit build of Firefox or Chrome, it's running a 32-bit EXE first to launch it.
As for the 4GB memory limit, that's something we already allow for. For the less than 1% of apps this affects, they're done as a dual mode 32-bit and 64-bit and on a 64-bit machine with 64-bit Windows, it runs the 64-bit EXE. So every app that could come into a memory crunch is already running at 64-bit.
Lastly, this is a 6 year old topic, so some of the data in the main post has obviously changed and some of the comments may no longer be relevant.
"When we encounter the rare exception like JkDefrag (which requires both versions) or 7-Zip (which benefits from both versions without a big install-size hit), we'll do one of our special hybrid versions so that the right version runs on the right PC."
IMHO, this is the best way. Because, as you said, there are programs that would be too large to contain both 32 and 64bit versions, and there are, also, those who do not greatly improve performance when used in 64 bits. So the best way is to do as you said and create hybrid versions of applications that "worthwhile".
Keep the good work!
The only real thing 64-bit
The only real thing 64-bit support is needed for on 64-bit systems is drivers, some apps use 'em (usually for maintenance) and such apps don't tend to be very portable.
So most apps don't need to be 64-bit. The main gain from using 64-bit apps when you don't need to is that they can make use of more than 2gb of memory, but this usually isn't a problem for most apps or most users.
So, I definitely think most portable apps should be 32-bit only and even for drivers you might be able to get away with just the 64-bit driver with the 32-bit app (I believe most programs that utilize a driver will do this already... OpenVPN takes this approach) so you just need the two versions of only the driver.
By these rules a 64-bit version of 7-Zip isn't really needed since the only component it has that needs 64-bit AFAIK is the shell extension which we wouldn't include anyway. But if it does give a performance boost I suppose that could help; it could have optimizations for 64-bit and being it is computationally expensive (when compressing files) that would be a good case for it.
In general, we'll only do the 32-bit version. But with 7-Zip, we were looking at adding under 3MB (and soon a bit less) to the install size but getting ~10% performance boost when compressing many files. And, as some users will be using 7-Zip to deal with large files like backups and the like, it made sense since a 10% performance boost can wind up being a good chunk of time for large files compressed to the max.
Why fuss x86 vs x64? Explorer++ auto-detects the right version!
Instead of debating 32-bit vs 64-bit, why not make the 32-bit Q-Dir portable apps launcher (eg Q-DirPortable.exe) auto-detect the 32 vs 64 bit nature of the OS and launch the matching Q-Dir exe? The newly released Portable App rev of Explorer++ does this:
32-bit and 64-bit versions combined into a single automatic package
I'm very appreciative of your Q-Dir Portable App dev effort (Q-Dir is my main explorer tool) but I prefer for whatever reason to run the 64-bit rev when I'm on a 64-bit OS. I hope your Portable App Q-Dir will auto-detect 32/64 in a later version so I can use it, thanks!
We only go through the process of this when there is either a requirement or a measurable performance gain. Because it does increase the size of the install (unnecessarily in most apps) and does introduce "one more thing that could go wrong". We packaged Explorer++ this way because the 32-bit version doesn't work quite right with all the Control Panel displaying when run on 64-bit Windows. That plus the combined version is only 2.5MB.
I did not package Q-Dir nor am I involved in its creation... it's just a dev test not an official release. If Q-Dir needs this for similar reasons, ask the dev in the dev test topic. It should also be noted that an online installer (as Q-Dir Portable is right now due to it being freeware and needing permission for repackaging) *can't* download and install a 32-bit and 64-bit version of an app, it can only do one download.
Online installer + 32/64-bit = fail. Talk to the Q-Dir dev?
Hi, I'm the Q-Dir Portable dev.
As John said, an online installer can't download multiple files, and Q-Dir's 32-bit and 64-bit builds are separate downloads. The only way I could package both the 32-bit and 64-bit builds would be via an offline installer, and the Q-Dir dev hasn't responded to my e-mail requesting permission for this.
I would be more than happy to create a 32/64 package, but as I said, I need permission. If you want to get in touch with the Q-Dir dev and ask, maybe we could make some progress. IMHO, a user making a request is a bit different, and perhaps more powerful, than another dev making the same request.
P. S. We should probably take this conversation into the Q-Dir Portable beta thread, since we're off-topic here.
Looking for a portable Launcher 32/64 bit autodetect
I am Looking for a portable program launcher/starter which auto-detects the operating system 32/64 bit than automatically starts the right path for the software.
Like the starter of PortableApps, but with configuration for the path and optional icon select.
if 64 bit : run software in folder App(optional)/64bit/example.exe
if 32 bit : run software in folder App(optional)/32bit/example.exe
Does anybody have an idea ? Where can i Download a starter like this ?
If you're developing a portable app, you should take a look on the PortableApps.com Launcher; this part of the docs show how to handle 64-bit apps.
Although I don't know, it is important that the settings for a 64bit and 32bit application should be compatible.
The RAM footprint is less important than the speedgain.
The user may choose to optionally install a 64bit version as well, maybe exclusively through the updater?
The argument of space on USB flashdrive is important but keep in mind that we also have to look ahead. Flash size increases when prices per GB fall. An option for 64 bit should be optional.
Having the infrastructure for handling 32bit and optional 64 bit in place will smooth the transition when more apps require or desire 64 bit.
At some time in the future you eventually run against the 64bit wall anyway. Making the platform aware and support both versions will eventually be a good thing.
Personally I don't feel the need for 64 bit but understand it might be wise to add premelary support early.
So 32-bit software should (mostly) run OK on Win7-64?
I'm asking this because I'm getting a new machine at work, and I run portable apps for a huge chunk of my daily tasks (web, email, etc.) and need to be VERY sure before going to my boss and saying 64 is OK.
Thanks in advance.
As outlined above, in almost
As outlined above, in almost all cases, 32-bit software will run fine on a 64-bit OS. It is only rare cases like JKDefrag where you must use a matching version.
Most PCs are 64-bit Now
Most new PCs are 64-bit now. And they're all running 32-bit versions of Firefox, LibreOffice, Piding, etc. 32-bit apps work just fine on 64-bit Windows (but 64-bit apps won't run on 32-bit Windows). There are a few rare exceptions that require a 64-bit version on 64-bit Windows, generally system level apps. For stuff like that, we include both the 32 and 64-bit version of the app and have the launcher automatically use the right one. So your PortableApps.com stuff works on every PC.
I'm uninstalling my PortableApps.com PeaZip and using their own 64-bit release until the program is released here in accordance with PortableApps.com own policy, that is, being a similar program to 7-Zip, PeaZip will also benefit from the 64-bit performance. I'm counting on you guys! Keep up the good work!
I wrote the above but then I checked with more detail. I was fooled because the main executable of PeaZip 64-bit is still 32-bit, unlike 7-Zip's 64-bit version which is all 64. Now that I've looked into this with more detail, I know that the 7-Zip engine is the only part of PeaZip that is actually 64-bit, and the current PortableApps.com PeaZip release IS using the 7-Zip 64-bit component! So all is as it should be!
Keep up the good work!
64-bit vs 32-bit Development
I'm setting up a portable development system for myself. There is a real need to have either available for development apps.
understand where we are for 64bit
(sorry if there are more recent topics, I did not find them ...)
I would like to understand how Papps launchers work with 64bit versions (when there are both versions in the package)
- Is the P-apps-launcher doing it?
(Does the launcher choose the one it launches based on the computer on it is, or does it always choose the default 32?)
- Is this a choice made during the packaging of the app? (and allways launch the \ PortableApps \ XxxxPortable \ App \ Xxxx32.exe or 64 when we launch the \ PortableApps \ XxxxPortable.exe)
I would like to know more
The launchers are all 32-bit so they run everywhere and they make the determination on what is run on each PC. So they determine if Windows is 32-bit or 64-bit and then launch the appropriate version of the app if both are bundled. This could be App\Firefox\firefox.exe vs App\Firefox64\firefox.exe or running DiskMark32.exe vs DiskMark64.exe. Some apps even contain 4 different versions for 32-bit modern Windows (Windows Vista and up), 32-bit legacy Windows (2000/XP), 64-bit modern, and 64-bit legacy.
Note that by launcher I'm referring to AppNamePortable.exe, not the PortableApps.com Platform. Though the PortableApps.com Platform does some 32-bit vs 64-bit stuff internally (mainly backup-related).
thank you for the
thank you for the clarifications :- )