It’s a long time we don’t write anything in this blog and the last time we wrote about the CZIP 4 technology, which would have been the foundation for a total revolution in our product development. And we did it: the CZIP 4 library is the core of CZIP X, the encryption tool we released two years ago for Windows 10, macOS, Android and Linux – the iOS version probably will be developed when we will see how to make a convergence with the macOS version, as long as Apple will persist in building only ARM-based devices.
CZIP X is performing very well but we felt that the Windows 10 version was starting to look “old” on newer Win10 builds: in fact, the curent release was forked from the original UWP version that was originally conceived to worked mainly on Windows Mobile devices. We had a lot of constraints to observe and this forced us to make a desktop version that we felt not-so-nice as we wanted.
When Microsoft announced that we wouldn’t be able to develop for W10 Mobile anymore, we kind of smiled because we were seeing the chance to redesign our utility the way we love to design our apps; however, we were busy to develop and launch other versions like the Android one, which took a lot of time reach the “ready for release” stage because we wanted to make it ready for the upcoming Android 11 (and when released, we were ready to update our code with few changes).
The basic features set is in every version we released until today and two months ago, while building the new ZipGenius X as an UWP application that will get to other platforms through the Uno Platform project. We’ll talk about ZG later in a new post.
So what are we doing right now? We’re making a better CZIP X for Windows 10. We could just say that we’re making a better desktop version but it’s not entirely true, because we are going further than simply touching the user interace; in fact, we are also working under the hood in order to fix what was wrong with the app and what is causing the application to stop working in certain circumstances. We investigated and found that we need to rework the app in these areas:
In order to address these issues we put a series of checks and warnings that will inform users if they have enough free space on main storage (for the temporary file) and on the destination storage (for the final .czx file); also we put an error message that appears if encryption/decryption fails when trying to operate on FAT32-formatted media and files are larger than 4 GB.
For issue #3 we built a system of auto-tutorials that run at the first run of each section and then they dismiss by themselves.
We also found that our user base is largely using Windows on laptops: this details convinced us to make CZIP check the battery level at startup and just before encrypting or decrypting files, because our app perform tasks that are often CPU-intensive and this translates into an high level of energy requested; if someone tries to encrypt or decrypt large archives with low levels of energy available in the battery, the task could be abruptly aborted with unexpected consequences for the files handled through the app. Or simply, it would be a waste of time. For some reason, when we were developing CZIP for Windows 10 Mobile, we didn’t put this battery check…
Under the hood we did a lot of changes.
We slightly modified the core CZIP4 library to work better, alas the encryption/decryption tasks now are fully multithreaded and they make the app more fluid when busy with the main tasks; also, the core library now can tell the progress of the task and that allowed us to make the progress dialog more informative – this will be implemented in Android and Linux versions very soon.
Talking about performances, we modified the code of encryption and decryption tasks in order to adapt to the size of data that will be processed. The current versions of CZIP X all use a small buffer to process chunks of data. It is 1 Megabyte for any size of data to process. While it is good enough to create or decrypt small archives (let’s say up to 500 GB), that is not good for larger archives because they will be processed 1 MB at a time. We considered that this buffer could be increased for archives larger than 1 GB and than 4 GB, as much as it could be decreased for archives smaller then 4 MB. This feature is called autobuffer and it is particularly useful for desktop version of CZIP X, so we are discussing if it could be added to the Android version, too.
A truly new feature we added is the support to IPFS, the InterPlanetary File System, the decentralized file storage that uses a peer-to-peer technology to make files available from everywhere without relying on a web server. Uploading files to IPFS also makes files permanent and avoids duplication because IPFS is content-based so the address to reach a file is the file’s hash, no matter what its filename is; if you upload a file named as an already existing file but with different content, the newer one won’t overwrite the previous because the latter will have its own address.
The next release of the application will allow users to upload encrypted archives to IPFS together with an attestation of existence of the same file: while this attestation could prove the existence of the archive at a definite moment in time, making it a legally valid proof, you could still use any blockchain-based notarization service to notarize the attestation of existence.
We fixed a nasty bug. If you were trying to decrypt an archive by scanning a QR code stored in a .PNG image file, the app was doing… nothing. It was just allowing user to scan the QR code through the device camera but the “Acquire from .PNG file” option was purely fake. We fixed it and now you can read QR codes from .PNG files.
Oh… And visually the app has changed very much: we started using WinUI 2.x and adopted the Fluent design of Microsoft to make our app a true Windows 10 app. Just compare the screenshots to see how much it changed.
You can support the development of useful tools and application through a donation. Choose how to donate.