I can again backup using 32 bit php. And restore from 32 bit php archives.
If I am on a 64 bit system, it will create in 64 bit php, and restore 32 and 64 bit archives.
As I will be running mixed 32 and 64 bit versions on one of my Windows servers, it would be nice if there was a little indication/flag in a backup as to which version it was created?
This is not really possible because it would require being able to read the backup's header. This is not possible when the backup archive is stored remotely. If we instead required a new field in the database it would only work on backups taken with a newer version of Akeeba Backup.
Moreover, it would be incredibly misleading because the JPA 1.2 archive format was also created in 64-bit versions of PHP in prior versions of Akeeba Backup. Marking it as a 32-bit version would confuse our clients and create a torrent of support requests. Marking the JPA version instead would be confusing for everybody, including you, as it might be confused with the software version, again leading to a torrent of support.
Furthermore, in most practical cases we can just make it so that the archive extraction on 32-bit versions of PHP skips over the 64-bit additional archive headers of a JPA 1.3 backup archive. For the vast majority of backup archives (with individual files under 2GiB in size) the user would know, or need to know, the difference. The 32-bit-only JPA 1.2 archives can already extract just fine on 64-bit versions of PHP. For the uses cases with individual files over 2GiB, please do remember that the 32-bit-only JPA 1.2 format did not (and could not) work; the backup archives were broken. Therefore, nothing is lost on pure 32-bit installations.
Finally, the number of 32-bit installations is infinitesimal to begin with.
With these facts in minds, marking archives in any way in the Manage Backups page would be an anti-feature which would lead to unnecessary confusion and a high number of support requests about a non-issue which is best handled under the scenes. The ONLY correct solution is to allow 32-bit versions of PHP to extract JPA 1.3 backup archives by skipping over their additional 64-bit-only headers.
With regards the x86/x64 nomenclature I was using, the terms x86 and x64 are used to distinguish between versions on the download page
PHP for Windows only runs on the x86 ISA because Windows itself is currently only supported on the x86 ISA by PHP.
Yes, technically speaking, there's an ARM-based build for Windows 10 and 11. However, that build is OEM-only (you cannot download it if you are not a hardware manufacturer with a special contract with Microsoft), therefore it cannot be currently used as a build target for PHP in a continuous integration environment or a build farm. Hence PHP's download page only showing 32-bit and 64-bit builds for the x86 ISA.
Once Windows on ARM becomes a stable thing, if that ever happens, and PHP starts supporting it expect that page (and PECL Windows build listings) to change.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!