En réponse à quelques demandes d'utilisateurs, cette version apporte trois changements:

• Une nouvelle base de comparaison dans le menu à coté de l'icone de tri permet trier les fichiers par leur nom long logique, ce qui est pratique lorsqu'on a des noms de fichiers ou dossiers qui contiennent des nombres comme c'est souvent le cas pour les pistes d'albums.
  Avant, lorsqu'on avait une liste de fichiers nommés 1-1, 2-1, 5-1, 8-1, 8-2, 8-10, 10-1, 13-1, 20-1 et qu'on les triait avec le nom long comme base de comparaison, on se retrouvait avec une liste dans l'ordre lexicographique (1-1, 10-1, 13-1, 2-1, 20-1, 5-1, 8-1, 8-10, 8-2) ce qui n'est pas souvent ce qu'on voudrait.
  On pouvait s'en sortir en ajoutant des zéros à gauche des nombres pour avoir un tri correct (ex: 01-1, 02-1, 05-1, 08-01, 08-02, 08-10, 10-1, 13-1, 20-1) mais ceci pouvait s'avérer pénible.
  Avec cette nouvelle base de comparaison les fichiers sont maintenant mis dans l'ordre plus naturel de leurs nombres inclus, tel que celui qu'on retrouve dans l'explorateur de Windows.
• Un utilisateur avec un ancien processeur AMD n'arrivait plus a lancer DriveSort car le nouveau compilateur que j'utilise génère par défaut du code nécessitant un processeur supportant les instructions SSE2. Pour être compatible avec plus de machines, DriveSort a été recompilé pour ne pas nécessiter ces instructions dont il n'a pas spécialement besoin.
  Je n'ai pas de machine de ce type à ma disposition pour tester, mais en regardant rapidement le code désassemblé il ne semble plus y avoir d'instruction SSE dans le code généré, j'espère donc que cette version sera compatible avec plus de machines.
• Normalement des droits d'administrateur sont requis par Windows pour verrouiller un disque de manière exclusive et manipuler le système de fichier de la manière dont DriveSort à besoin.
  Un utilisateur m'a cependant indiqué avoir travaillé avec une ancienne version de DriveSort qui ne demandait pas de droits d'administrateur, et était bloqué par le controle de compte utilisateur car il ne disposait pas de droits administrateurs pour utiliser les nouvelles versions.
  Peut être que dans certaines situations des privilèges spéciaux peuvent aussi suffire, donc pour permettre aux utilisateurs privilégiés mais non administrateurs d'utiliser DriveSort, cette version ne demande plus les droits d'administrateur pour démarrer, mais seulement les droits les plus élevés dont l'utilisateur dispose.
  Pour les utilisateurs dont le compte dispose de droits d'administrateur ceci ne change rien, DriveSort tournera toujours entant qu'administrateur.
  Pour les utilisateurs normaux, l'absence de droits administrateur ne devrait maintenant plus bloquer le lancement de DriveSort, par contre l'absence des privilèges requis devrait toujours empêcher de verouiller les disques de manière exclusive, ce qui devrait se voir lors de l'ouverture d'un disque par un message d'erreur indiquant que l'accès est refusé.
  Mes quelques essais sur une VM de test sous Windows XP SP3 entant qu'Utilisateur, Utilisateur avec Pouvoir, ou membre du groupe de Sauvegarde et Restauration sont restés infructueux. Si quelqu'un arrive à ouvrir un disque avec DriveSort sans droits d'administrateur je suis curieux de savoir comment son compte est configuré (peut être avec secpol.msc?) et sous quelle version de Windows ceci est supporté, donc n'hésitez pas à me tenir au courant.

De plus, pour plus de sécurité DriveSort tente maintenant d'activer pour son processus quelques fonctions de sécurité et politiques d'aténuation d'attaques en plus de celles précédement activées lorsqu'elles sont disponibles sur la version de Windows sur laquel il tourne. DriveSort désactive maintenant la création de processus fils vu qu'il n'est pas sensé lancer un autre programme, désactive l'usage de code dynamique vu qu'il n'en génère pas, désactive l'utilisation d'appels systèmes de win32k.sys, plus quelques autres points d'extensions dont il ne se sert pas.
J'ai pu tester cette version sur un Windows 10 à jour et un Windows XP SP3, mais si vous constatez un problème de compatibilité avec cette version n'hésitez pas à me le signaler.

J'ai modifié la manière dont les actualités du site sont publiées de manière à proposer des liens permanents sur chaque article indépendemment. Le lien associé à un article d'actualité est sur la petite croix jaune à gauche du titre de l'article
Par exemple pour cet article le lien permanent est https://www.anerty.net/news/20180323T0645Z.

Lorsqu'un article est traduit, on peut aussi directement accéder à une de ses traductions en sélectionnant d'abord le drapeau de son choix puis en accédant au lien sur la croix à gauche de l'article. Par exemple pour cet article, le lien permanent à une traduction particulière est:
- Pour la version française: https://www.anerty.net/news/20180323T0645Z?lang=fr.
- Pour la version anglaise: https://www.anerty.net/news/20180323T0645Z?lang=en.

J'ai ajouté un exporteur de fichiers sources à jSAVF, accessible par bouton droit sur les objets de type *FILE avec attribut PF contenant des membres sources (ex: QCBLLESRC, QCLLESRC, QCLESRC, QRPGLESRC, QSQLLESRC, ...).

Celui ci permet d'afficher dans un spool ou d'extraire dans des fichiers le contenu d'un ou plusieurs membres d'un fichier physique source contenu dans un SAVF de l'AS-400. Trois formats d'export sont possibles: CSV, fichier source à plat, et texte du fichier source selon l'usage qu'on veut en faire. Les deux premiers formats incluent les trois champs du format source: le numéro de ligne (SRCSEQ) la date de modification de la ligne (SRCDAT) et le contenu de la ligne (SRCDTA). Le dernier n'inclut que le texte de SRCDTA sans les espaces en fin de ligne.

Après ce type d'objet, les fichiers de données seront probablement les suivants à être exportables dans une prochaine version.

Si vous rencontrez des problèmes pour afficher un fichier source inclus dans un SAVF n'hésitez pas à me contacter.

Quelques corrections et améliorations liées a la sécurité sont inclues dans DriveSort v1.230:

• Du code supportant à moitié un usage en ligne de commande inclu par erreur dans la version précédente a été supprimé vu qu'il n'est pas encore prêt. Lorsqu'on essayait de s'en servir il produisait des messages incompréhensibles liés à la validation et ne faisait rien, donc pas une grosse perte.
• Le dialogue de sélection de disque se tient mieux à jour lorsqu'un disque apparait ou disparait, même quand Windows n'envoie pas de message WM_DEVICECHANGE pour l'occasion. J'ai remarqué que ceci se produit lorsqu'on monte ou démonte des volumes TrueCrypt pendant des tests mais c'est peut être possible avec d'autres périphériques, donc maintenant tant qu'il est affiché le dialogue de selection de disque utilise à la fois un polling sur le masque des lettres de lecteurs et l'écoute du message WM_DEVICECHANGE pour détecter les changements.
• Le dialogue de notification de nouvelle version offre maintenant un moyen d'ignorer une version sans avoir à désactiver les vérifications periodiques de version si vous ne souhaitez pas recevoir de rappel pour une version particulière. Lorsqu'une nouvelle version est disponible, vous pouvez donc maintenant choisir d'ouvrir la page de téléchargement, d'ignorer la nouvelle version, ou de décider la prochaine fois que la version sera vérifiée (oui / non / annuler). Si vous choisissez Non, la prochaine notification sera à propos de la version suivant celle ignorée, et proposera le même choix.
• L'user agent HTTP que DriveSort utilise lorsqu'il vérifie la dernière version a changé de "DriveSort Updater" à "DriveSort/1.230" pour mieux respecter la RFC. Ceci ne change pas grand chose vu que la version était déjà présente dans l'URL de vérification de version, mais ça à une meilleure tête sur le réseau.
• DriveSort tente maintenant d'activer pour son processus les fonctions de sécurité Windows et les politiques d'aténuation d'attaques suivantes lorsqu'il tourne sur une version de Windows qui les supporte: Prévention de l'exécution des données, Randomisation des images, Protection de la pile, Protection du flux de controle, Valider l'intégrité de la heap et de l'utilisation des handles, Bloque les polices non approuvées, Désactiver les points d'extension, Prefere les DLLs de system32, Evite les DLLs du dossier courant. Je n'ai pas remarqué de problème sur Windows 10.1709 qui les permet tous ou sur Windows XP SP3 qui à ma connaissance ne propose que DEP. Si vous remarquez des incompatibilités avec d'autres versions de Windows merci de m'en informer et je verrai ce que je peux faire.

J'ai aussi signé les executables de DriveSort avec des certificates que j'ai généré de manière à permettre la vérification simple de leur intégrité a l'aide du dialogue de propriétés de fichier Windows et de son onglet signatures digitales, bien que Windows va se plaindre de problème d'approbation car mes certificats n'ont pas été émis par une autorité de certification approuvée. J'ai appliqué une signature SHA1 et une signature SHA256 pour que les anciennes et nouvelles versions de Windows aie chacune quelque chose de compréhensible.

Le contrôle de compte d'utilisateur va afficher le même avertissement orange qu'avant lorsque DriveSort n'était pas signé lors de la demande de droits administrateur (qui sont nécéssaires car DriveSort a besoin d'un accès disque complet pour faire son travail). L'avertissement est parfaitement normal vu que Windows n'a aucune garantie que mon certificat auto-signé m'apartient bien vu que je n'ai pas payé une autorité de certification réputée pour le vérifier, donc la signature offre en pratique peu d'information de confiance en plus vu qu'elle aurait pu être ajoutée par quelqu'un sur un exécutable modifié en utilisant un certificat qui ressemble au mien. A terme j'acheterai peut être un certificat de signature de code à une des autorités de certification approuvées par Windows, mais c'est un peu cher pour un petit projet perso. Pour le moment si vous voulez vérifier que les signatures sont bien les miennes, mes certificats ont tous les deux f63a19f489360788049e2f7945ce4381ce644777 comme identificateur de la clef, le certificat de signature SHA1 a pour empreinte numérique 8272dfdaf3af740c6ead49dfb08dcc92a74c43f1 et le certificat de signature SHA256 a pour empreinte numérique f73185df917d9ae5382db34a5ad0edaa0417ff20.

Pendant que je testais comment les signatures se comportaient, j'ai été un peu surpris de découvrir que le contrôle de compte affiche le même avertissement pour un certificat non approuvé que le contenu de l'exécutable corresponde à la signature ou non, j'aurais supposé qu'une signature invalide aurait déclenché le message d'erreur rouge du contrôle de compte et empeché l'exécution vu qu'il semble dangereux de lancer un exécutable corrompu, que ce soit parceque la signature ou le code qu'elle signe qui soit erroné.
Le message affiché dans les détails de la signature numérique du dialogue des propriétés du fichier est plus précis, et distingue clairement les deux cas:

Lorsque le certificat ayant produit la signature n'est pas approuvé mais que la signature correspond bien au contenu du fichier exécutable.

Lorsque l'exécutable a été modifié, peut importe que le certificat soir approuvé ou non.

J'ai aussi affiché un hash SHA1 au dessus de certains liens de téléchargement pour permettre à plus d'utilisateurs de vérifier leurs téléchargements. C'est surtout à l'intention d'utilisateurs qui ne souhaiteraient pas installer GPG4Win pour vérifier les signatures numériques des téléchargements avec ma clef publique GPG. Un hash SHA1 peut être calculé par de nombreux programmes tels 7Zip, sha1sum.