A few corrections and security enhancements are included in DriveSort v1.230:

• Some code related to command line usage which was included in the previous versions by mistake has been removed because it's not finished yet. It was producing weird validation messages when trying to use it and did nothing, so no big loss there.
• The drive selection dialog now refreshes more consistently when a drive arrives or is removed, even when Windows doesn't send a WM_DEVICECHANGE message for it. I've noticed this happens when mounting and unmounting TrueCrypt volumes while testing but it may also apply to other devices, so the drive selection dialog now both polls the drive letter mask and listens to WM_DEVICECHANGE messages as long as it is displayed to detect these changes.
• The version update dialog now offers you a way to skip a specific version without having to disable the periodic version check if you don't want to be reminded about one particular version. When a new version is available, you can now choose to open the download page, ignore the new version, or decide later when the next version check occurs (yes / no / cancel). If you chose No, the next time you'll be notified will be about the version after that one and offered the same choice.
• The HTTP user agent which DriveSort uses when checking the latest version changed from "DriveSort Updater" to "DriveSort/1.230" to better respect the RFC. This doesn't change much as the current version was already present in the version check URL, but it looks better on the wire.
• DriveSort now attempts to enable the following Windows security features and exploit mitigation policies for its process when its running on a Windows version which support them: DEP, ASLR, Stack protection, Control flow guard, Terminate on heap corruption or invalid handle use, Disable non-system font load, Disable legacy extension points, Prefere loading DLLs from system32, Avoid loading DLLs from current directory. I haven't noticed any issue with these enabled on either Windows 10.1709 which supports them all or Windows XP SP3 which I think only supports DEP. If you notice any incompatibility with Windows versions in between please mention it to me and I'll see what I can do.

I've also signed the DriveSort executables with some certificates I've generated myself so the file integrity can be checked easily in the Windows file properties dialog / digital signatures tab, although Windows will complain about trust issues because my certificates haven't been issued by a certificate authority it trusts. I've applied both an SHA1 and a SHA256 signature so older and newer versions of Windows each have something they understand.

User Account Control will still display the same orange warning as before when there was no signature when asking for administrator rights (which are required because DriveSort needs full access to disks to do its job). The warning is perfectly normal because my self-signed certificates are not trusted to be mine by Windows as I haven't paid any reputable certificate authority to verify the fact, so the signatures offer very little additional trustable information by themselves as they could have been added by someone else to a modified executable using a certificate which looks like mine. I may eventually purchase a verified code signing certificate from a Windows approved certificate authority, though they're a bit pricey for a pet project. For now if you want to check that the signatures were indeed mine, my certificates both have f63a19f489360788049e2f7945ce4381ce644777 as subject key identifier, the SHA1 signing certificate has 8272dfdaf3af740c6ead49dfb08dcc92a74c43f1 as thumbprint and the SHA256 signing certificate has f73185df917d9ae5382db34a5ad0edaa0417ff20 as thumbprint.

While I was testing how the signatures behaved, I was a bit surprised to see that the Windows UAC prompt displays the same warning message for an untrusted certificate whether the exe contents matches the signature or not though, I would have expected an invalid signature to trigger a red UAC error and prevent execution as it makes little sense to try to run a corrupted executable file, whether it's the signature or the code which is wrong.
The message displayed in the digital signature properties dialog from the file properties is more informative, and clearly distinguishes both cases:

When the signature certificate is not trusted but the signature matches the executable file contents.

When the executable has been tampered with regardless of whether the signature is trusted.

I've also displayed an SHA1 digest above some download links to allow more users to verify their downloads. It is mostly intended for those who don't want to install GPG4Win to verify the digital signatures of the downloads with my GPG public key. An SHA1 digest can be computed by a variety of programs such as 7Zip, sha1sum.

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, ...).