I would love to see 7-Zip embraced more strongly also at the system level by the likes of Microsoft, etc.
In my opinion, there is a good opportunity to fill in a couple of badly missing features across not just 7-Zip, but also other archiving formats and ISO images:
1) Support Authenticode digital signatures. This would be like the CAB archival format already supports, and similar to executable file signing by Microsoft and open source tools (signcode, osslsigncode, etc.) Must support multiple signatures from the beginning (e.g. dual SHA-1 and SHA-256).
2) Do a custom format for ISO images, e.g. .7iso. Yes, it sort of can be already done (just pack an ISO in a .7z), but IMHO it needs to be a radically simple low-level wrap where one archive = one ISO image. Only in this way will image creation, burning and mounting tools support it with the same simplicity as ISO images are recognized and supported now. What you add by this is compression and integrity check, which .iso alone lacks. And signing, per 1).
Lastly, right now a common usability problem that is not being dealt with in an optimal way is that of incomplete downloads. There should be a standard documented procedure whereby, based on some data at the beginning of the archive, a specific error message can be given to the user if the file is not just "corrupt", but too short.
This synergy of relatively small enhancements has IMHO the potential to be disruptive, especially if we add some good "marketing" with the right developers and companies.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
iso is not a compressed format; a supposed "7iso" wouldn't be mount-able since there is no "on the fly" extraction. You'd need to unpack the iso to a disk (which would be slow due to extraction time + I/O) or into memory (imagine having to have 25GB of memory for blu-ray iso). I don't think this is easily possible or implementable without either ruining compression ratio (small blocksize to allow extration of just required files) or the performance (because you'd have to do what I stated above).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would love to see 7-Zip embraced more strongly also at the system level by the likes of Microsoft, etc.
In my opinion, there is a good opportunity to fill in a couple of badly missing features across not just 7-Zip, but also other archiving formats and ISO images:
1) Support Authenticode digital signatures. This would be like the CAB archival format already supports, and similar to executable file signing by Microsoft and open source tools (signcode, osslsigncode, etc.) Must support multiple signatures from the beginning (e.g. dual SHA-1 and SHA-256).
2) Do a custom format for ISO images, e.g. .7iso. Yes, it sort of can be already done (just pack an ISO in a .7z), but IMHO it needs to be a radically simple low-level wrap where one archive = one ISO image. Only in this way will image creation, burning and mounting tools support it with the same simplicity as ISO images are recognized and supported now. What you add by this is compression and integrity check, which .iso alone lacks. And signing, per 1).
Lastly, right now a common usability problem that is not being dealt with in an optimal way is that of incomplete downloads. There should be a standard documented procedure whereby, based on some data at the beginning of the archive, a specific error message can be given to the user if the file is not just "corrupt", but too short.
This synergy of relatively small enhancements has IMHO the potential to be disruptive, especially if we add some good "marketing" with the right developers and companies.
iso is not a compressed format; a supposed "7iso" wouldn't be mount-able since there is no "on the fly" extraction. You'd need to unpack the iso to a disk (which would be slow due to extraction time + I/O) or into memory (imagine having to have 25GB of memory for blu-ray iso). I don't think this is easily possible or implementable without either ruining compression ratio (small blocksize to allow extration of just required files) or the performance (because you'd have to do what I stated above).