Salut,

Je suis bien sous Windows 7 mais je n'ai plus VB6 :-p Donc je ne peux pas tester !

Cela étant, c'est l'API Win32 qui est appelée, donc normalement aucun problème.
Sauf au niveau de la gestion des droits que çà changera un peu (faudra surement lancer l'exe avec élévation pour que çà soit bon, vu que l'user lambda n'a pas les droits pour accéder à l'intégralité du registre).

@+

Comment tu compiles la source ? Parce que çà marche sans aucun problème (un certain nombre de gens ont déjà utilisé le code source sans soucis).

Bonjour à tous,

Premièrement désolé de ne pas être très présent, j'ai pas mal de boulot en ce moment :-p

Pour ce qui est de l'exception, elle concerne quel formulaire, et dans quelles circonstances ?
As-tu essayer de compiler tout le projet dans un premier temps (certaines forms ne sont pas affichables tant que les contrôles utilisateurs ne sont pas compilés) ?

Pour le driver KernelMemory, il est utilisé pour la récupération des noms des handles. Sous Window 7 32-bit aucun problème, mais en version 64-bit çà ne marche plus en effet. En fait le driver est compilé pour les systèmes 32-bit seulement... et ne pourra pas être utilisé sur une plateforme x64 vu qu'en 64-bit les drivers doivent être obligatoirement signés ! Ce qui n'est bien évidemment pas le cas pour ce driver.

Normalement dans la dernière version du programme, le driver n'est pas chargé sur les versions 64-bits, et le programme fonctionne sans problème sans, en mode dégradé (les handles ne sont pas tous listés et/ou leur nom de peut pas être récupéré).

EnableDebug et EnableShutdown normalement devrait passer sans pb, même si le résultat ne fonctionnera que si le compte est autorisé. Encore une fois, si le compte n'est pas admin, le programme fonctionne en mode dégradé (certaines fonctions et/ou informations pas disponibles).


Sinon je conseille de télécharger la dernière version dispo publiquement du code ici : http://downloads.sourceforge.net/project/yaprocmon/YAPM-beta/YAPM-2.4.1/YAPM-v2.4.1-source.zip
C'est normalement beaucoup plus à jour que le code de vbfrance ^^

@+ !

Salut à tous,

BruNews --> merci beaucoup pour le zip ! Je l'ai téléchargé et j'intégrerai dès que je trouverai un peu de temps (ce Week End normalement).


Galain --> Merci pour le retour sur NTFS !
Pour ce qui est de la passe "random", c'est effectivement à cause de l'OS 64-bit que cela ne fonctionne pas, vu que l'appel à la dll de Brunews retourne une adresse mémoire de taille 4 octets sur tous les OS (vu que le 64-bit n'est pas pris en compte). Donc adresse mémoire invalide sur OS 64-bit (qui attend 8 octets) = erreur lors de l'écriture.
Pour l'effacement du fichier, il faudrait effectivement l'implémenter afin d'enlever toute trace du fichier. Je l'ai pas fait simplement pour pouvoir effectuer mes tests plus simplement (sans avoir à recréer N fois mon fichier ^^). La trace dans la MFT est problématique en effet. Il faudrait éventuellement renommer le fichier avant suppression.

gillardg --> Effectivement, en 1 passe de 3 trois écritures (ou bien 3 passes en fonction de la terminologie ?) ce n'est pas suffisant. Du coup quand je mettrai à jour le code, j'ajouterai une option pour pouvoir choisir ses passes. Cà permettra de configurer le nombre, l'ordre, mais aussi la valeur à écrire (si d'aventure 0x55 et 0xAA n'étaient pas souhaités). J'essayerai de pondre quelque chose "d'un peu ouvert" au niveau de l'architecture du code, de sorte qu'il soit possible d'ajouter très facilement de nouveaux types de passes en implémentant un quelconque algorithme autre que valeur constante ou random...




Au passage j'ai pensé à un truc en lisant le commentaire de Brunews : de mémoire j'ai mal codé le calcul de la taille du buffer pour l'écriture Random(). Il se pourrait que j'ai mis une valeur en dur qui ne fonctionne pas au top avec des disques dont la taille des secteurs n'est pas 512... J'ai pas vérifié, c'est de mémoire, je regarderai en détail ce WE si je trouve le temps !

@+

Salut,

Version .Net à jour ici : http://www.vbfrance.com/codes/UTILITAIRE-SANITIZATION-DISQUES-DURS-FICHIERS-SUPPRESSION-DONNEES-CONFIDENTIELLES_51792.aspx

@+

Yep, et ce qui était codé en X j*h avec VB6, maintenant c'est fait en quelques minutes avec .Net ;)

Sinon j'ai pas encore regardé les nouveautés de vb2010 concernant le parallélisme, j'irai voir çà !

@+

@VIOLENT_KEN : je suis content que tu es changé d'avis, tu est quand meme passé de "pas de .Net pour moi... a quoi bon migrer vers un language encore plus lent que le VB6 ? Aucun intérêt..." à
"Heureux de voir cette source en .Net, le langage de l'avenir (et avec en plus le meilleur IDE de l'univers : Visual Studio 2008) !!!" ... cela est juste une petit boutade ;-) ... on a beaucoup echangé sur le sujet a l'epoque ... et je suis ravie que tu t'es un peu plus "ouvert" et que finalement tu rejoind ce que je disait à l'epoque...



Héhé oui j'ai bien changé d'avis depuis il est vrai ;-)
Faut dire que depuis l'époque où j'avais dit çà, j'ai pu étudier quelques notions (super) importantes en informatique :  réutilisabilité, généricité, flexibilité, obsolescence...etc.

S'il reste vrai que sur les machines de l'époque (par exemple un bon vieux P4 ^^) certains codes d'algorithmie pure restent légèrement plus rapide en VB6 qu'en VB.Net, VB.Net permet bien évidemment des gains de temps monstrueux dans le développement, grâce aux centaines de librairies accessibles et grâce aux bénéfices de la POO.
Et si VB6 est certes plus rapide sur certains bouts de code, c'est évidemment complètement négligeable au vu des pertes de temps nécessaires pour réinventer la roue à chaque fois, alors que les classes du .Net implémentent déjà des milliers d'objets extrêmement utiles et assez optimisés (namespace System.Collections, System.IO...etc.).

Et même pour la vitesse d'exécution, VB.Net se débrouille très bien, et au vu des architectures actuelles (multicore, large quantité de RAM) et au vu de la gestion désatreuse du multi-threading en VB6, il serait kamikaze aujourd'hui d'espérer avoir de meilleures performances en VB6 qu'en .Net.

A partir de là, l'un des seuls arguments en faveur du VB6 s'écroule...

Et on peut ajouter des centaines d'arguments en faveur du .Net par rapport au VB6 : l'IDE qui est 10x plus stable et plus productif, la gestion des exceptions, la propreté du code, la gestion des handlers/delegates/events, la surcharge des opérateurs, la gestion du subclassing, de vrais constructeurs/destructeurs, le garbage collector, la POO (héritage, meilleures interfaces...), l'équivalence à C# (compilé en CIL) pour la réutilisabilité, support natif des architectures x64, 2x plus de code documenté disponible sur le net...
Je m'arrête là, il y a trop de points positifs !


Et c'est sans compter toutes les innovations des versions > 2.0 : LINQ, WCF, WPF...etc.

Bref, .Net çà innove et c'est vraiment, vraiment meilleur que VB6.


Donc à l'époque il faut avouer que je disais une conn*rie, probablement à cause d'une certaine réticence à tourner le dos au langage qui m'était le plus familier ;-) Certainement aussi une méconnaissance de notions fondamentales en développement logiciel (cf. plus haut).

Mais depuis que le fais du .Net (VB ou C#), je ne touche plus au VB6 du tout (sauf exceptions pour récupérer du vieux code à convertir en .Net).



Bref, t'avais raison ;)
@+

10/10 bien sur

Salut,

excellent travail !

Mais quelle est la licence de ce code ? Sans infos de licence on pourrait penser que c'est du public domain, mais pourrais-tu confirmer ? Si ce n'est pas public domain, c'est compatible GPL3 ?

Merci
@+

Brunews parle de l'API Win32.

Pour inclure çà dans du VB.Net faut utiliser le namespace
System.Runtime.InteropServices

et déclarer la fonction comme décrit ici : http://www.pinvoke.net/default.aspx/kernel32/CreateFile.html


Sinon CreateFile c'est bien, mais çà ne permet pas de savoir quel process a ouvert le fichier. Pour connaitre le process, pas le choix, faut énumérer les handles ouverts sur le système et déterminer, en fonction du nom du fichier, quel est le handle concerné pour avoir son ProcessId associé.
@+