New color theme for the site.

I was starting to get tired of the old violet-blue colors of old so I've decided to change the visual theme to a dark orange one which should be easy on the eye.

I've re-rendered some images from their 3D models with the new palette, and took the opportunity to make the home page layout a bit more compatible with small screens found on phones / tablets. I hope I haven't missed anything blue in a deep recess of the site, if you see anything which looks funny don't hesitate to mention it to me.

A DriveSort user reported that he couldn't sort his 2TB drive, which is an interesting effect of Moore law applied to storage given this program was initially created to sort 128MB-256MB USB keys.

After investigation, when the size of a FAT-32 partition to sort is larger than a few hundred gigabytes the Windows file system drivers become more reluctant to allow application to directly write to disk since volumes of such size exceed the Microsoft recommandations concerning FAT-32 format and many programs do not support such excesses.

When this happens the direct reads from disk are still possible for all existing programs, but when a program wishes to write directly to parts of the disk reserved to the file system it needs to take some additional measures to tell Windows that it's capable of handling FAT-32 formats which exceed the recommanded limits.

I've updated DriveSort to let it correctly handle these large volumes by:

• Disabling buffering when opening the disk (FILE_FLAG_NO_BUFFERING)
• Using an operation which lets read-write boundary checks be delegated to the device driver instead of letting the FAT file system driver do it (FSCTL_ALLOW_EXTENDED_DASD_IO)
• Aligning the read and write buffers on memory addresses which are a multiple of the sector size by using VirtualAlloc instead of standard allocations

These improvements also apply to the backup and restore features available in the contextual menu in the volume tree of the disk open dialog, so it is now possible to work with volumes of the maximum possible size for FAT-32 (2TB) without issue.

My old build toolchain for DriveSort was very out of date (VC++6) so I've had to migrate DriveSort sources to be compatible with VisualStudio 2017, but I'm still targetting the oldest Windows version supported by this tool chain (Windows XP).

For DriveSort to work on old Windows versions it may thus be necessary to install the new Visual C++ redistributables (vc_redist.x86.exe in The latest supported Visual C++ downloads, [ Direct Download link ]).

Indeed programs compiled with this Visual C++ version require some DLLs to be present and they are not systematically provided by Windows Update (mfc140u.dll, and the Universal C Runtime DLLs named api-ms-win-crt-*.dll), according to Microsoft the VCRedist package seems to do what's necessary to install all these wherever it should go.

If you encouter some issue while trying to run DriveSort on your Windows don't hesitate to mail me.

While testing jSAVF with a SAVF found on the net, I noticed a bug in my LZ1 (*HIGH) unpacking routine which sometimes mangled the extracted data or made the unpacking fail. This update fixes the issue and a few minor ones (fixed the version check URL, cleanup of unpacking temporary files, ...).

I've recently been asked about jSAVF, so I thought finally getting around to publishing the latest version might help. The code in this version is a bit more recent than the one in v1.28, but I haven't touched it in about 7 years except for some finishing touches for this release.

This version brings a lot of change, amongst which the support of the more modern SAVF compression algorithms TERSE (*MEDIUM) and LZ1 (*HIGH) together with the previously supported SNA (*LOW / *YES), and some user interface and performance improvements. I'm now considering finishing the physical file export to CSV, or the debugging sources included in *PGM objects.