ACCÈS DIRECT DISQUES ET PARTITIONS VB NET

Commentaire de yvesyves le 12/03/2008 17:29:30

voila la note

Commentaire de Jeanoot le 12/03/2008 17:53:08

J'ai oublié la note

Commentaire de Galain le 21/04/2008 17:50:30

Une erreur a été découverte dans le système de fichiers NTFS. cela concerne le cas d'un enregistrement NTFS qui possède un attribut ATTRIBUT_LIST qui est non résident. Ce cas n'avait pas été traité et cela faussait les affichages dans les feuilles traitant le système NTFS. Cette correction est déjà faite dans le projet similaire en VB 6.0 et sera bientôt faite dans le projet VB net. Bonne prog à tous et A+

Commentaire de Galain le 18/06/2008 22:50:23

La source connait de gros problèmes avec Windows Vista. Sous Xp elle fonctionne nickel néanmoins. Je cherche les solutions

Commentaire de Galain le 28/06/2008 15:28:43

J'ai réussi à lire les secteurs cdrom et dvdrom sous Vista. Les cd audio fonctionnent aussi correctement. Quelqu'un peut-il me confirmer que sous Windows Xp le projet fonctionne correctement pour les CDROMS (audio et data) et DVDROMS (vidéo ou data) ?
Bien le bonjour à tous et bonne prog

Commentaire de Galain le 25/07/2008 18:16:00

Salut AYBE81

Sous Vista j'arrive à lire les disquettes Fat 12, les disques durs FAT 16 et 32, les disques durs NTFS,les clefs USB Fat 16 ou 32 et même les cdroms et dvdroms

Une memory card doit apparaître dans les disques physiques comme les clefs USB

Attention on ne peut pas modifier un secteur ( l'écriture n'est pas programmée)

donne moi plus de précisions en cas de problème

A +

Commentaire de aybe81 le 25/07/2008 21:02:20

J'ai oublié de préciser,
cela fonctionne seulement en mode Administrateur,

Entre temps j'ai cherché un peu sur le net,

Ce projet en Delphi fonctionne nickel sous Vista, sans avoir à élever les privilèges :
http://sourceforge.net/projects/directdisk/

Celui-ci aussi mais plante à la fin de la MMC :
http://www.roadkil.net/program.php?ProgramID=12

Sinon ces gars-là proposent un SDK (payant :-( qui résout les problèmes d'accès au disque directement, sous Vista :
http://www.eldos.com/rawdisk/download.php

En espèrant que ça puisse t'aider ... :-)

@+

Commentaire de Galain le 26/07/2008 00:12:22

Salut Aybe81

Ce projet en Delphi fonctionne nickel sous Vista, sans avoir à élever les privilèges :
http://sourceforge.net/projects/directdisk/

Il n'a aucun mal à fonctionner car la seule chose qu'il fait est de lire et écrire dans des secteurs soit de partitions soit de lecteurs physiques.
Mon projet le fait aussi mais explore en plus les partitions,les systèmes de fichiers,etc...

A mon avis ta carte MMC est une "partition RAW" non reconnue par mon projet : peux-tu me confirmer ?

A + et bonne prog  

Commentaire de aybe81 le 26/07/2008 12:43:55

salut Galain,

La MMC est bien au format RAW, propriétaire à la CDJ1000.
En fait ça sert stocker les points CUE de chaque morceau,
afin de pouvoir se caler dessus directement.

Ton soft fonctionne lorsque je le lance en tant qu'Admin,
et effectivement je ne peux y accèder qu'en mode physique
étant donné que c'est un format propriétaire.

Et je précise, autant l'accès Physique ou Logique nécessite des privilèges,
ce qui m'intéressait dans ce projet Delphi, c'est qu'il n'à pas besoin d'être admin.

Dans l'idéal il faudrait pouvoir dumper sans privilèges,
(Sachant que c'est uniquement pour lire/écrire une MMC, pas un disque système)

Pour te répondre, oui ça fonctionne correctement, mais en mode admin. uniquement.

Je vais regarder plus en détail,

@+

Commentaire de aybe81 le 26/07/2008 20:33:16

Ou également, une partition (NTFS ou FAT) peut devenir un partition RAW suite à de mauvais drivers installés ou une erreur de données.

Voilà sinon concernant ton programme, ça marche sans problèmes,

J'ai commencé à m'attaquer un peu à CreateFile voir ce qu'il était possible mais à vrai dire il était un peu tard ...

En fait dans mon logiciel, l'utilisateur n'est pas nécessairement l'admin., ce qui complique un peu les choses.

Je vais continuer à regarder un peu ton prog. et si je trouve une amélioration concernant les privilèges je te fais signe.

(Dans l'idéal, je souhaiterais convertir ton programme en une classe autonome, ré-utilisable)

ok @ bientôt

Commentaire de Galain le 30/08/2009 16:20:38

Merci Boutemine pour la note

Commentaire de Galain le 30/08/2009 16:40:24

Salut Boutemine
Qu'appelles-tu "organiser un peu le code selon le style OOP" ?
Je ne vois pas du tout ce que cela veut dire
Et merci encore

Commentaire de Galain le 30/08/2009 17:13:56

Ok : je vois ce que tu veux dire
Je referais certainement une mise à jour en recodant tout cela dans des structures plus compréhensibles
A l'origine la source était en VB 6.0 et j'ai repris la même structure pour le passage de la source en VB Net

Commentaire de Galain le 29/10/2009 07:03:34

Salut Willi
un petit cours très rapide
En NTFS chaque fichier se voit attribué un enregistrement de type File. Dans cet enregistrement sont stockés ce que l'on appelle les attributs du fichiers. NTFS est semblable à une base de données.
Parmi ces attributs celui qui nous intéresse est l'attribut DATA.Un enregistrement ayant une taille limitée (4 koctets) 2 cas peuvent se présenter
- les données du fichiers peuvent tenir dans l'enregistrement : l'attribut DATA sera résident
- les données ne peuvent être contenues dans l'enregistrement : l'attribut DATA sera non résident.Pour trouver les données du fichier on définit une runlist. Cette runlist n'est que le chainage des clusters utilisés par les données du fichiers. C'est à comparer avec le chainage des clusters en FAT

D'autres attributs que DATA peuvent être résidents ou non résidents
La runlist travaille avec les VCN (Virtual Cluster Number) c'est à dire que l'on connait le premier bloc de clusters et, si le fichier est fragmenté, les autres blocs seront désignés par l'offset par rapport au bloc précédent.

Je vais rechercher sur le Net l'URL d'un cours sur NTFS et te l'indiquerai
A+  

Commentaire de Galain le 29/10/2009 18:56:01

Salut willi
J'ai dit une enregistrement MFt avait une taille limitée mais il faut comprendre que tous les enregistrements ont tous la même taille. Le cas le plus fréquent est de 1024 octets (1 Ko). Si les attributs de l'enregistrement font que l'enregistrement est trop petit on se sert des attributs non résidents.
Un fichier texte de 20 octets aura l'attribut DATA résident alors qu'un fichier texte de 15 Ko aura ses données (attribut DATA) non résident.
-ATTRIBUT_LIST permet pour un enregistrement donné d'avoir des enregistrements complémentaires car dans ce cas un seul enregistrement n'est pas suffisant por contenir tous les attributs. Certains attributs sont contenus dans l'entrée MFT principale alors que les enregistrement complémentaires sont contenus dans l'ATTRIBUT_LIST de l'enregistrement principal. Si on veut ATTRIBUT_LIST est une série de pointeurs pour les enregistrements complémentaires.
-EA_INFORMATION : Attribut plus utilisé à ma connaissance
-INDEX_ROOT et INDEX_ALLOCATION : ces attributs sont spécifiques aux répertoires. Si le répertoire contient peut de fichiers ou de sous-répertoires ceux-ci sont contenus dans l'attribut INDEX_ROOT. Si l'attribut INDEX_ROOT n'est pas suffisant on utilise en plus l'attribut INDEX_ALLOCATION qui contient une Runlist ( même principe que pour l'attribut DATA ) Qui contient la liste des clusters où aller chercher les index des sous-répertoires et fichiers de ce même répertoire.

Pour trouver l'offset de départ d'un fichier il est obligatoire de lire les informations dans l'enregistrement de ce même fichier dans la MFT.
Si le fichier a ses DATA résidentes les données du fichier sont dans l'attribut DATA de l'enregistrement . Dans le cas de DATA non résidentes il faut passer par le runlist pour trouver les clusters contenant les données du fichier

Pour les répertoires c'est les attributs INDEX_ROOT ( et INDEX_ALLOCATION si nécessaire) qui permettent de retrouver le contenu du répertoire.

Je peux te dire que je me suis souvent arraché les cheveux et friser la migraine pour arriver au résultat que permet cette source.
Je t'enverrai l'adresse d'un site expliquant NTFS mais c'est en anglais
A ta disposition et A+    

Commentaire de Galain le 29/10/2009 21:06:58

Salut Willi
Peux-tu m'envoyer un message en privé avec ton adresse de messagerie. Ainsi je pourrais t'envoyer la documentation qui m'a servi à créer ce projet. Je n'ai plus le site mais j'ai gardé en téléchargement toute la doc sur clef USB
a ton service et a+

Commentaire de Willi le 01/11/2009 16:59:35 administrateur CS

PI: Pour éviter de désactiver l'UAC, executez Visual Studio en tant qu'Administrateur (clic droit sur vs puis Executer en tant qu'Admin). (sous Seven)

++

Commentaire de aybe81 le 01/11/2009 22:43:40

J'ai utilisé un peu le soft, et c'est vrai que c'est bordelique !
J'ai pu extraire la partie qui m'intéresse (RAW) mais bon, idéalement il devrait être refait.

Je veux bien participer à une récriture complète en C#.
On pourrait le récrire assez rapidement, à plusieurs.

Galain, fais-moi signe si ça te chauffe.

@+

Commentaire de aybe81 le 01/11/2009 23:00:28

Pour changer cette ligne : Réglages UAC dans les propriétés du projet.

Commentaire de Galain le 01/11/2009 23:16:45

Merci AYBE81 pour ce commentaire : c'est vrai que c'est bordelique
rien ne t'empèche de le réécrire en C# : c'est du open source
Oui cela me chaufferait bien mais C# je ne connais point
comment tu désactives Clickonce ?

Commentaire de aybe81 le 02/11/2009 00:55:19

Ok,
En fait il est pas si long que ça, quand j'ai regardé il y 1 an ca me paraissait gros, mais en fait c'est parce qu'il est mal conçu. Maintenant bon, c'est une simple traduction de VB6 c'est normal. Le gros problème c'est que les forms sont vraiments dégeulasses avec plein d'assignations directes, et finalement les modules ne remplissent pas vraiment leur role de module. Mélange français/anglais etc ...

Pour ClickOnce, propriétés du projet, onglet Securité ;-)

Je pense le mieux à faire, tu connais mieux les choses à améliorer dedans, ca serait bien de faire une petite liste.

Idéalement ca serait bien de bosser à plusieurs, sur 1 projet.

Si je le recommence, ca sera en C#, WPF, et multi-langues.
Je commencerais par récrire le système, après l'UI.

Maintenant si on bosse à plusieurs faudra se répartir les tâches.

Voila,

C'est drôle parce que j'ai le même parcours que toi, excepté pour le ZX81, je faisais du VB.Net mais j'ai totalement laché depuis C#. La syntaxe est en verité très simple, aujourd'hui je vois VB avec une syntaxe plutôt lourde et moins efficace.

Tu vas rire, mais en lisant le code je vois des $ ... Je me demande, qu'est-ce que c'est ? Ca m'a pris 30 sec. avant de me souvenir que c'est une chaine de caractères X-)

Aujourd'hui je bosse sur un logiciel de mix audio en C#, alors VB ça me parait très loin !

Commentaire de aybe81 le 02/11/2009 21:15:40

C'était pas mon intention, tu as simplement porté ce code vers .NET, ce n'est pas toi qui a mal conçu ce soft à la base.

Desolé pour cette confusion.

Je vais le refaire en C#, bon maintenant ca va pas prendre 2 jours car j'ai du boulot par ailleurs ...

Je te tiens au courant de l'avancée dès que j'ai quelque chose de pas mal.

@+

Commentaire de aybe81 le 02/11/2009 22:30:40

Ok, j'avais compris que tu avais repris ce soft. (Je viens de commencer, je suis sur la première fenêtre :-)

a+

Commentaire de aybe81 le 03/11/2009 00:45:19

Je vais avoir besoin de vous car vous avez certainement glané pas mal d'infos sur les systèmes de fichiers.

@+

Commentaire de aybe81 le 04/11/2009 01:32:21

J'ai fini la detection des partitions, j'ai une vue complète de chaque paramètre,
il faudrait que je fasse des DataTemplate car il y a 51 colonnes.

Sinon j'ai regardé un peu, en gros il faut la même UI pour les deux types de disque.

Maintenant l'écriture directe sur le disque ca sera un chapitre à part ... je suis moyennement chaud à moins d'être familier avec ... Mais bon qui dit lecture, dit ecriture !

Commentaire de aybe81 le 04/11/2009 20:20:12

Salut tout le monde,

Bon j'ai avancé un peu en C#, je vais m'attaquer à l'affichage du contenu des DD ....

En regardant le code VB, il y a qq declarations incorrectes.
Par exemple, CreateFileA

Public Declare Function CreateFile Lib "kernel32" Alias "CreateFileA" (ByVal lpFileName As String, _
                                                                           ByVal dwDesiredAccess As Int32, _
                                                                           ByVal dwShareMode As Int32, _
                                                                           ByVal lpSecurityAttributes As IntPtr, _
                                                                           ByVal dwCreationDisposition As Int32, _
                                                                           ByVal dwFlagsAndAttributes As Int32, _
                                                                           ByVal hTemplateFile As IntPtr) As IntPtr
  
Tous les Int32 doivent être des entiers non signés, si tu veux, ca va fonctionner tant que tu recois une valeur entre -2147483648 et 2147483647, alors qu'avec un UInteger, cela va de 0 à 4294967294.

Je t'invite utiliser cet excellent outil P/Invoke Interop Assistant, qui te donnera en un clic de souris, la bonne signature, et en VB !

Exemple : (CreateFileA)

<System.Runtime.InteropServices.StructLayoutAttribute(System.Runtime.InteropServices.LayoutKind.Sequential)>  _
Public Structure SECURITY_ATTRIBUTES
    
    '''DWORD->unsigned int
    Public nLength As UInteger
    
    '''LPVOID->void*
    Public lpSecurityDescriptor As System.IntPtr
    
    '''BOOL->int
    <System.Runtime.InteropServices.MarshalAsAttribute(System.Runtime.InteropServices.UnmanagedType.Bool)>  _
    Public bInheritHandle As Boolean
End Structure

Partial Public Class NativeMethods
    
    '''Return Type: HANDLE->void*
    '''lpFileName: LPCSTR->CHAR*
    '''dwDesiredAccess: DWORD->unsigned int
    '''dwShareMode: DWORD->unsigned int
    '''lpSecurityAttributes: LPSECURITY_ATTRIBUTES->_SECURITY_ATTRIBUTES*
    '''dwCreationDisposition: DWORD->unsigned int
    '''dwFlagsAndAttributes: DWORD->unsigned int
    '''hTemplateFile: HANDLE->void*
    <System.Runtime.InteropServices.DllImportAttribute("kernel32.dll", EntryPoint:="CreateFileA")>  _
    Public Shared Function CreateFileA(<System.Runtime.InteropServices.InAttribute(), System.Runtime.InteropServices.MarshalAsAttribute(System.Runtime.InteropServices.UnmanagedType.LPStr)> ByVal lpFileName As String, ByVal dwDesiredAccess As UInteger, ByVal dwShareMode As UInteger, <System.Runtime.InteropServices.InAttribute()> ByVal lpSecurityAttributes As System.IntPtr, ByVal dwCreationDisposition As UInteger, ByVal dwFlagsAndAttributes As UInteger, <System.Runtime.InteropServices.InAttribute()> ByVal hTemplateFile As System.IntPtr) As System.IntPtr
    End Function
End Class

Lorsque tu le lances,
- tu vas dans l'onglet SigImp Search,
- chosis VB,
- dans name, tapes le nom de la fonction.

http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?ReleaseId=14120

Par ailleurs, il est important de mettre certaines de ces fonctions externes dans la classe NativeMethods.

Pour ceux qui veulent les détails http://msdn.microsoft.com/en-us/library/ms182161%28VS.80%29.aspx

Si c'est du charabia pour toi, n'hesites pas surtout !

Bonne prog, a+ :-)

Commentaire de aybe81 le 04/11/2009 22:09:18

J'ai oublié,

Bien évidemment cela fonctionne toujours en enlevant les attributs que j'ai mentionnés :-)

Commentaire de aybe81 le 05/11/2009 15:48:21

Public Declare Function si c'est pas du Pinvoke, c'est quoi alors ?
lol :-)

Je vous tiens au jus, allez, a la prochaine !

Commentaire de Galain le 07/11/2009 01:25:18

Salut Willi
Ah l'Update Sequence : ce fut ma bête noire avant que je comprenne
Que signifie pour toi le mot "fix" ? Car là je ne comprends pas ta question

Maintenant le rôle de l'Update Sequence : généralement un enregistrement MFT est de 1024 octets soit 2 secteurs.Les 2 derniers véritables octets de chacun de ces secteurs sont remplacés par l'Update Sequence Number ( ce sont 2 octets choisis automatiquement par NTFS qui remplaceront les 2 derniers octets des 2 secteurs contenant l'enregistrements). Le tableau de l'Update Sequence Number contient dans ce cas 4 octets et les 2 premiers sont les véritables octets du premier secteur et les 2 derniers sont les véritables octets du second secteur)
Comme dans l'entête de l'enregistrement on a les 2 octets de l'Update Sequence Number NTFS vérifie que ces 2 octets sont bien identiques aux 2 derniers octets de chacun des 2 secteurs et si c'est le cas l'enregistremnt est correct
Pour lire un enregistrement NTFS il faut
- lire tout l'enregistrement ( 2secteurs dans notre cas)
- Trouver l'Update Sequence Number
- Vérifier que les 2 derniers octets de chacun des deux secteurs correspondent à cet Update Sequence Number
- Si oui remplacer les 2 derniers octets du premier secteur par les 2 premiers octets du tableau de l'Update Sequence Number puis remplacer les 2 derniers octets du second secteur par les 2 derniers octets de ce même tableau
Quand j'ai compris cela le test de corruption me servait à vérifier si ce que je disais était correct : maintenant ce test pourrait être supprimé si on le désires

En résumé les 2 derniers octets de chacun des secteurs de l'enregistremment ne sont pas les vraies data de l'enregistrement. Ces vrais octets sont contenus dans le tableau de l'Update Sequence Number et sont remplacés par les 2 octets de l'Update Sequence Number de façon identique sur les 2 secteurs
J'ai du regarder un exemple sur ma source pour ne pas te raconter de bétises.
J'espère que je réponds à ta demande le plus clairement possible
Bonne prog et A+  

Commentaire de Galain le 08/11/2009 22:28:20

Aybe81 avait dit : Ce projet en Delphi fonctionne nickel sous Vista, sans avoir à élever les privilèges :
http://sourceforge.net/projects/directdisk/
Ce n'est plus le cas sous Windows Seven : je regarde pourquoi

Commentaire de Willi le 08/11/2009 23:34:43 administrateur CS

Je ne pense pas que le fait de passer en Delphi changera quelque chose ! Du code c'est du code. En .net ou vb6 tu peux le faire également reste à connaitre la ou les subtilités pour autoriser l'écriture de données brutes sur un volume.
J'ai regardé la source delphi de DirectDisk, le bouton Write fait appel à une méthode writesector(,) que je n'ai pas retrouvé dans les sources.
Si tu retrouves cette méthode alors je dirais que tu n'as qu'à la copier en vb !

Commentaire de aybe81 le 09/11/2009 22:54:41

La lecture seulement fonctionnait, pas l'écriture.

Commentaire de Galain le 09/11/2009 23:12:41

Salut Aybe81
Merci pour ces précieuses informations : on abandonne donc définitivement toute écriture sur le disque pour ce projet
A+ et bonne prog

Commentaire de violent_ken le 23/11/2009 22:18:20

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

Commentaire de aserf le 03/05/2010 09:41:13

Bonjour,

J'ai trouver votre source tres interessante,
effectivment si vous la reprogrammer un jour je vous conseil de fair des class, cela rendra le code plus "lisible". Mais une migration de vb6 vers vb.net n'est pas toujours facile ...

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

a++
seb

Commentaire de aserf le 03/05/2010 11:39:20

Salut,

et tu vas voir que en vb2010 c encors mieux,
tu as le paralellisme completement integrer (je veux pas dir que l'on ne pouvais pas le fair avant), mais maintenant en une ligne de code ... et la pour les gros traitement c vraiment mieux !!

Chez nous on est passer de plusieur 10 ene de ligne de code a,

Parallele.ForEach() ... une ligne sa ce passe de commentaire, et on a fait des test de perf, c'est identique, ...

ensuite effectivement, les generic, les delegate, les interfaces, les dataset typé, Linq, ... font que les performances sont enorme,
on avait une application developper en vb6 qui est passer en .net, des traitement qui prenais 5mn, sont maintenant instantanée ...

Enfin bon, Bonne prog.
Sébastien