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é.
@+

bidouille007 => Salut, si c'est bien çà, mais il faut regarder les handles ouverts de type "fichier" (file).

Par contre pour éviter l'erreur "fichier occupé par un autre processus", il faudrait fermer le handle ouvert par le process, mais çà risque d'impacter sur son comportement.

@+

Salut Galain !

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) !!!

Comme pour ta source VB6, BRAVO pour celle ci, c'est vraiment une mine d'informations sur les filesystems assez impressionnante (très rare d'avoir des sources si complètes sur vbfrance).
Bref, 10/10 bien évidemment.



Je vois que c'est ta première source .Net, si tu veux je peux citer quelques (très) modestes conseils pour le codage d'une application vb.net assez conséquente et pointue comme celle ci l'est :


- mettre "Option Strict On" en tête de chaque fichier. Cà permet d'éviter à VB de réaliser des casts automatiquement notamment (ainsi que certains autres concepts comme le late binding...etc.). C'est vraiment pénible comme opération pour tous les fichiers (au passage c'est possible de le faire pour tous les fichiers directement dans les propriétés du projet : Compiler -> Option Strict à On) ==> dans ton projet çà va générer plusieurs centaines d'erreurs...
Mais une fois toutes ces erreurs (triviales pour 99% d'entre elles) corrigées, le code sera beaucoup plus cohérent au niveau du typage des fichiers (par exemple un UInt32 sera stocké dans un UInt32 uniquement et pas casté violemment dans un Int32 signé).
Et le compilateur rejettera parfois des erreurs de codage, à juste titre, qui seraient passées et auraient faussé l'exécution en Option Strict Off.


- utiliser des déclarations P/Invoke via l'espace de nom System.Runtime.Interop (à importer en début de fichier) pour les appels aux fonctions de l'API Win32. Par exemple :
Public Declare Function FindClose Lib "kernel32.dll" (ByVal hFindFile As Int32) As Int32 (déclarations VB6 vieillote)
va devenir en VB.Net :
<DllImport("kernel32.dll")> _
Public Shared Function FindClose(ByVal hFindFile As IntPtr) As Boolean
End Function

Il existe un site excellent pour récupérer les déclarations des fonctions de Win32 pour .Net : http://www.pinvoke.net/. Ne pas hésiter à en abuser !! (gaffe quand même pour les fonctions assez peu utilisées, des fois il y a des erreurs -__-)


- penser aux versions 64-bits de Windows dès le début. Perso j'avais fait l'erreur de coder pour du x86 only dans mon projet, ben quand les utilisateurs ont réclamé du x64 j'ai miséré à tout changer.... :)Plus tôt c'est fait, mieux c'est !
Concrètement, prendre en compte les versions 64-bits çà se traduit principalement par le fait que les adresses mémoires sont codées sur 8 octets en x64 (=64 bits) et 4 seulement en x86 (=32 bits). Bref, il faut utiliser le type IntPtr à tous les endroits où une adresse mémoire est représentée.
Par exemple pour la déclarations FindClose ci-dessus, on utiliser un IntPtr pour le handle (les handles dans Windows sont toujours codés avec 8 octets en x64) sur le fichier en paramètre (et pas le Int32 de la vieille déclaration VB6, qui du coup fonctionnera pas en x64 natif).
Du coup quand le programme (le même, compilé une seule fois et utilisable à la fois en x86 et en x64) sera utilisé sur x86, IntPtr prendra 4 octets, et sur x64 IntPtr prendra 8 octets. Mais comme IntPtr.Size sera déterminé automatiquement par le framework AVANT le démarrage de l'application, il n'y aura aucun changement de code à faire ! FindClose prendra automatiquement un paramètre de bonne taille suivant l'architecture 32 ou 64 bits de l'OS.
Bref, pour savoir si c'est du Int32 ou du IntPtr, faut regarder sur MSDN et convertir les déclarations C en VB.Net. Un DWORD c'est 4 octets donc Int32, un HANDLE c'est 4 ou 8 suivant l'architecture donc c'est IntPtr... etc. Ou bien utiliser http://www.pinvoke.net/, mais malheureusement certaines (très peu) déclarations sont fausses et donc à vérifier sur MSDN.


- On trouve souvent des exemples de code uniquement en C# sur internet, pas en VB.net. Il existe donc des outils de conversion automatiques (très très très efficaces !!) pour répondre à ce besoin : http://www.developerfusion.com/tools/convert/csharp-to-vb/
Cà permet de faire VB->C# ou bien C#->VB.


- Penser à utiliser la programmation objet, c'est à dire l'utilisation de classes réutilisables (et héritables si possible). Cela se traduit par exemple par l'abandon complet de la notion de "module", au profit de classes avec membres statiques.
Ainsi, le module2 deviendra la classe cEcran, et aura comme squelette :

Option Strict On
Public Class cEcran
    Public Shared Function SetResolution(ByVal Width As Int32, ByVal Height As Int32, ByVal BitsPerPixel As Int16) As Boolean
        ...
Return XXX
    End Function
End Class
Appelé par cEcran.SetResolution.

De même, les structures (hors structures pour l'API Win32) doivent être délaissées au profit des classes.
De même, les variables publiques n'existent plus, remplacées par attributs privés + properties (RO, WO ou RW).


Sinon attention au DoEvents, si jamais l'application passe au multithreading dans le futur, çà risque de poser problèmes (cette instruction est à bannir en multithreadé).
Sinon on part du principe que y aura pas de multithreading dans le futur de l'application, on peut alors augmenter les performances en utilisant :

For X as integer = 0 to 1000000
if (x mod 1000)=0 then
Application.DoEvents()
end if
next

plutôt que :

For X as integer = 0 to 1000000
Application.DoEvents()
next

Pour l'utilisateur çà changera pas grand chose niveau réponse de l'application aux requêtes, mais le CPU sera ravi !!!


Sinon us_30 a rassemblé les principales différences entre VB6 et VB.Net (pour les types de variables) dans son tuto, assez pratique : http://www.vbfrance.com/tutoriaux/GRANDEUR-DECADENCE-VB2008_891.aspx



Voilà, j'espère que c'est constructif et assez compréhensible, en tout cas MERCI pour cette source et cet EXCELLENT travail de recherche sur les filesystems !

Au passage, çà marche pour moi sur Windows Seven Pro 32bits pour NTFS (de ce que j'ai pu tester).
@+

v2.4.0

Nombreuses corrections de bugs et ajout de nouvelles fonctions, dont la fonctionnalité "System Snapshot" qui permet de favoriser l'assistance à distance :
- création d'un snapshot du système
- transmission du fichier snapshot sur le poste de quelqu'un d'autre
- navigation à travers l'IHM de YAPM dans le premier système de manière transparente (comme si c'était YAPM qui tournait sur un système local)

@+

Bonjour,

aucune demande particulière n'est à faire, vous pouvez utiliser l'OCX directement.

Il faut seulement respecter la licence apposée à ce projet (GNU LGPL) (voir le fichier licence.txt dans le *.zip, ou ici http://fr.wikipedia.org/wiki/Licence_publique_générale_limitée_GNU)

Donc en gros, il est possible d'utiliser sans problèmes ce code dans un projet propriétaire sans avoir à rendre tout le code source du projet propriétaire sous licence libre (et heureusement d'ailleurs !)

Pour simplifier, si vous réutilisez ces controles sous LGPL dans votre logiciel, les restrictions seront :
- conserver le copyright du fichier OCX
- conserver la licence LGPL du fichier OCX et la fournir avec le fichier OCX

Rien ne changera pour votre logiciel de maintenance (grâce au "L" de LGPL ^_^)

@+

v2.2.1

- Utilisation du remoting pour le remote monitoring
- Optimisations considérables dans tous les sens
- Compatibilité 64-bits (mais pas complète)
- Tonnes de nouvelles fonctionnalités
- ...etc.

Cf. yaprocmon.sourceforge.net pour les détails.
@+

En réalité cette fonction n'est pas définie pour certaines valeurs de x, et comme ce n'est pas géré dans le programme, les fonctions permettant de réaliser les calculs d'exponentielle foirent et renvoient des valeurs bidons...

Si on visualise la courbe entre x=[0...3] et y=[0..100], le résultat sera correct.

Cela étant, cette source date un max et est surement très très loin d'être optimale :-) Donc y aurait certainement des milliards de corrections à y apporter...

@+

Salut,

j'ai ENFIN réussi à convertir entièrement ce code pour qu'il soit utilisable indifférement sur un OS 32-bits ou 64-bits. Enfin, côté .Net, parce que le driver en 64-bits je l'ai pas, je connais pas assez le C pour m'y attaquer pour le moment.
Bref, j'arrive à faire fonctionner ce code pour qu'il fonctionne parfaitement aussi bien sur 32 que sur 64 bits, mais la récupération du Name des objets de type File ne fonctionne que sur 32-bits (car pas de driver 64-bits).

Comme toutes les structures changent en 64-bits (pointeurs sur 8 octets), le code diffère pas mal (allocations mémoire différentes, utilisation de IntPtr qui implique de ne plus utiliser des offsets en dur...etc).


Pour info, ce code est vraiment très très utile, puisqu'il permet d'obtenir des tonnes d'infos sur le système (possibilité d'énumérer les processus via les handles de csrss, possibilité d'énumérer les jobs en cours après récupération du ObjectTypeNumber de "Job"...).

Bref si quelqu'un veut la version qui fonctionne sur x64, contactez moi (je poste pas là parce que tout le code est refait)
@+