In response to some user needs, this version brings three changes:
A new comparison base in the menu next to the sort icon allows to sort files by their logical long name, which is useful when working with files or
folders which contain numbers as is often the case for music tracks.
Before, when sorting a list of files named 1-1, 2-1, 5-1, 8-1, 8-2, 8-10, 10-1, 13-1, 20-1 using the long name as comparison base, the list was sorted
lexicographically (1-1, 10-1, 13-1, 2-1, 20-1, 5-1, 8-1, 8-10, 8-2) which doesn't feel right.
By padding the numbers with zeroes on the left, it was possible to work around the issue to obtain the correct order (ex: 01-1, 02-1, 05-1, 08-01, 08-02, 08-10,
10-1, 13-1, 20-1) but that could become a chore.
With this new comparison base the files are now sorted in the more natural order of the numbers they include, as the Windows file Explorer does.
An user with an old AMD processor was no longer able to run DriveSort because the new compiler I'm using by default generates code which requires a processor
supporting the SSE2 instruction set. In order to be compatible with more machines, DriveSort is now compiled in a way which doesn't require these instructions
which it doesn't really need.
I don't have a non SSE2 machine at my disposal to test the compatiblity, but by having a quick look at the disassembled code there doesn't seem to be any more
SSE2 instructions in the generated code, so I hope this version will be compatible with more machines.
Usually administrator rights are required by Windows to lock a disk in exclusive mode and work with filesystems in the way DriveSort needs to.
An user nonetheless told me he managed to work with an older DriveSort version which didn't require administrator rights, and was now blocked from using the new
versions by the user account control because his account didn't have administrator rights.
There might be some situations where special priviledges might suffice, so in order to allow priviledged users without administrator rights to use DriveSort,
this version no longer requests administrator rights to start, but only the highest priviledges the user account has been granted.
For users whose account had administrator rights this changes nothing, DriveSort will still run as administrator.
For normal users, the lack of administrator rights should no longer prevent DriveSort from starting, but the absence of priviledges required by Windows should
still prevent exclusive disk locks, which should manifest itself as an error popup when opening a disk with an access denied message.
I've performed a few tests on a VM under Windows XP SP3 as User, Power User, or member of the Backup and Restore group, but without success.
If anyone manages to open a disk with DriveSort without administrator rights I'm interested to know how your user account is setup (maybe with secpol.msc?) and
under which Windows version this is supported, so don't hesitate to keep me posted.
Moreover, for more security DriveSort now attempts to enable for its process some more Windows security features and exploit mitigation policies on top of
those previously activated when they're available on the Windows version on which DriveSort runs. DriveSort now disables child process creation since it's not
supposed to run other programs, prevents the use of dynamic code since it doesn't generate any, disables the use of win32k.sys syscalls, and some other
extension points it doesn't use.
I could test this version on an up to date Windows 10 and a Windows XP SP3, but if you notice any compatibility issue don't hesitate to mention it to me.
I've changed the way news articles are published on the site in order to be able to offer permanent links to each article independently.
The link for a given article is on the small yellow cross on the left of the article title
For example for this article the permalink is https://www.anerty.net/news/20180323T0645Z.
I've added a source file exporter to jSAVF, which is available with a right click on objects of type *FILE with the PF attribute
and which contain source members (ex: QCBLLESRC, QCLLESRC, QCLESRC, QRPGLESRC, QSQLLESRC, ...).
This feature allows you to display in a spool or extract to files the contents of one or more source members of a physical file
inside an AS-400's SAVF.
Three export formats are available depending on what you plan to do with the sources: CSV, flat source file, and source file text.
The first two formats include all three source format fields: the source (SRCSEQ), the line modification date (SRCDAT) and the line
content (SRCDTA). The last format only includes the text from SRCDTA without trailing whitespace.
After handling this kind of object the data files will probably be the next to become exportable in a future version.
If you encounter any trouble displaying a source file inside a SAVF don't hesitate to tell me about it.
Update: Site and DriveSort 1.230
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,