ACCÈS DIRECT DISQUES ET PARTITIONS VB NET
cs_yvesyves
Messages postés
561
Date d'inscription
samedi 10 janvier 2004
Statut
Membre
Dernière intervention
11 octobre 2010
-
11 mars 2008 à 17:25
violent_ken Messages postés 1812 Date d'inscription mardi 31 mai 2005 Statut Membre Dernière intervention 26 octobre 2010 - 3 mai 2010 à 11:47
violent_ken Messages postés 1812 Date d'inscription mardi 31 mai 2005 Statut Membre Dernière intervention 26 octobre 2010 - 3 mai 2010 à 11:47
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/46012-acces-direct-disques-et-partitions-vb-net
https://codes-sources.commentcamarche.net/source/46012-acces-direct-disques-et-partitions-vb-net
3 mai 2010 à 11:47
Sinon j'ai pas encore regardé les nouveautés de vb2010 concernant le parallélisme, j'irai voir çà !
@+
3 mai 2010 à 11:39
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
3 mai 2010 à 11:28
"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 ;)
@+
3 mai 2010 à 09:41
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
23 nov. 2009 à 23:24
C'est un réel plaisir de voir ton post
Cela est plus que vrai que ce code est une transformation pure et simple d'un code VB 6.0 en VB net sans utiliser toutes les particularités de VB Net.
Je suis bien conscient que cela ne fait pas très pur au niveau code mais sa réécriture en VB Net "correct" me prendrait un temps fou.Le début du projet en VB 6.0 date de plus de 6 ans si mes souveniers sont bons.
tes modestes conseils sont plus qu'appréciés et si un jour je me décide de la réécrire de A à Z j'en tiendrais compte à plus d'un titre.
Merci bien pour la note et A+
23 nov. 2009 à 22:18
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).
@+
10 nov. 2009 à 14:42
Cela doit être possible mais compliqué, hier je suis tombé sur un article expliquant que .NET pour ce genre de choses c'est pas l'idéal, C++ l'étant car toutes les définitions sont présentes. Par ex, impossible de trouver les définitions de IOCTL_DISK_GET_PARTITION_INFO_EX ... elles existent sans doute.
J'ai bossé un peu hier sur le projet, ca ne marche pas, j'ai fait comme toi : CreateFile puis ReadFile mais j'ai toujours Access Denied ...
Apres j'ai vu qu'il faut impérativement user de DeviceIoControl entre les deux, dans ton projet il est utilisé, mais pas du tout a cet endroit, donc bon, va falloir un gros coup de Pinvoke car DeviceIoControl a besoin d'un certain nombre de déclarations ... à suivre.
A éclaircir !
9 nov. 2009 à 23:12
Merci pour ces précieuses informations : on abandonne donc définitivement toute écriture sur le disque pour ce projet
A+ et bonne prog
9 nov. 2009 à 22:58
(CreateFile)
Physical Disks and Volumes
Direct access to the disk or to a volume is restricted. For more information, see "Changes to the file system and to the storage stack to restrict direct disk access and direct volume access in Windows Vista and in Windows Server 2008" in the Help and Support Knowledge Base at http://support.microsoft.com/kb/942448.
9 nov. 2009 à 22:54
8 nov. 2009 à 23:49
++
8 nov. 2009 à 23:34
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 !
8 nov. 2009 à 22:36
Avec Windows vista il fonctionnait directement
Willi : en écrivant l'écriture secteur disque sous forme d'une Dll avec Delphi penses-tu que cela fonctionnerait ? Car avec l'éxécutable Delphi on peut modifier un secteur disque : j'ai testé
8 nov. 2009 à 22:28
http://sourceforge.net/projects/directdisk/
Ce n'est plus le cas sous Windows Seven : je regarde pourquoi
7 nov. 2009 à 11:32
OK j'ai pigé le role de l'UpdateSequence. Quand je parlais de "fix" => remplacement de la séquence de fin d'un enregistrement c'est tout !
Pour ceux qui se sont intéressés à la source de ShareVB (http://www.vbfrance.com/code.aspx?ID=44163) j'ai apporté une correction à cette méthode chargé d'appliquer l'UpdateSequenceArray.
++
7 nov. 2009 à 01:25
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+
7 nov. 2009 à 00:35
Peux-tu expliquer pourquoi à la lecture d'un enregistrement MFT il faut appliquer un "fix" sur l'update sequence array ??
Je te pose la question car j'ai un soucis avec la manière dont je "fix" l'enregistrement MFT. Ma fonction lève une exception d'accès en zone mémoire non autorisé de manière aléatoire. Je peux lire 10 enregistrements sa plante comme je peux lire 50000 enregistrement sans erreur d'accès mémoire.
Dans ta fonction UpdateSequence tu fais un test si pas de corruption de l'enregistrement. A quoi sert ce test ?
Merci.
5 nov. 2009 à 15:48
lol :-)
Je vous tiens au jus, allez, a la prochaine !
5 nov. 2009 à 06:50
pour Aybe81 j'ai vu ce que tu as fait pour l'instant et c'est vrai que cela fait plus pro et plus propre
Rassures-toi ce n'est pas du charabia pour moi mais j'ai simplement adapté le code VB 6.0 vers VB Net sans me soucier des particularités de VB Net (pas d'orientation objet,pas de Pinvoke pour les DLL,etc....). Cependant ma source a le mérite de fonctionner
en tout cas bravo et bon courage
Pour Willi je vais regarder ce qui cloche au niveau de CreateFile. Merci bien
4 nov. 2009 à 22:09
Bien évidemment cela fonctionne toujours en enlevant les attributs que j'ai mentionnés :-)
4 nov. 2009 à 22:06
CreateFile(ldrive, GENERIC_READ Or GENERIC_WRITE, _
FILE_SHARE_READ Or FILE_SHARE_WRITE, _
IntPtr.Zero, _
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0&)
GENERIC_READ Or GENERIC_WRITE depasse la valeur d'uint.
En enlevant GENERIC_READ et FILE_SHARE_READ, les arguments passent en uint.
Je viens de me rendre compte de ça en le passant en C#.
J'arrete pour aujourd'hui, je pensais pouvoir afficher un ptit secteur ce soir, mais ca sera pour un autre jour ...
Sinon bonne nouvelle, j'ai remarqué que la plupart du code n'est que de simples assignations, ca sera moins long que je pensais.
Voilà ce que j'ai fait pour l'instant : http://img42.imageshack.us/img42/5120/cap00045.png
a++
4 nov. 2009 à 20:20
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+ :-)
4 nov. 2009 à 19:35
++
4 nov. 2009 à 01:32
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 !
3 nov. 2009 à 23:50
Pour Willi : j'ai retenté l'écriture directe de secteurs sur le disque avec Writefile pour la purge des clusters libres. Même en éxecutant en tant qu'administrateur cela ne fonctionne point : problème de privilèges
Tant pis
Bonne prog à tous et A+
3 nov. 2009 à 00:45
@+
3 nov. 2009 à 00:15
Le visuel ici on s'en tamponne un peu les amygdales j'ai hate à voir au moins la partie gestion NTFS et FAT.
++
2 nov. 2009 à 22:30
a+
2 nov. 2009 à 22:26
Mais rassures-toi je ne tiens aucune rigueur quant à tes remarques
bon courage et sans rancune
A+
2 nov. 2009 à 21:15
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.
@+
2 nov. 2009 à 18:09
Merci pour les critiques que je trouve assez sévères.Je ne suis qu'un amateur qui s'est passionné avec la programmation en VB.
Le plus gros du boulot a été de comprendre les systèmes de fichiers FAT puis surtout NTFS avec une documentation plus que succinte.
Pour moi le résultat est bien au-delà de mes espérances lorsque j'ai commencé le projet il y a 4 ou 5 ans en VB 6.0
Maintenant si tu sais faire mieux vas-y
A+
2 nov. 2009 à 00:55
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 !
2 nov. 2009 à 00:16
Je plaisante faites comme bon vous semble !
1 nov. 2009 à 23:16
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 ?
1 nov. 2009 à 23:12
{"Overload resolution failed because no Public 'Add' is most specific for these arguments: 'Public Function Add(text As String) As System.Windows.Forms.ListViewItem.ListViewSubItem': Not most specific. 'Public Function Add(item As System.Windows.Forms.ListViewItem.ListViewSubItem) As System.Windows.Forms.ListViewItem.ListViewSubItem': Not most specific."}
En fait l'ObjectQuery ne fonctionne plus, tous les membres sont "Property evaluation failed."
Bon, eh bien voila une raison de plus pour le refaire :-)
1 nov. 2009 à 23:00
1 nov. 2009 à 22:59
Je dois changer cette ligne :
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
par
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Et désactiver ClickOnce,
Après il se lance, sinon il plantait dès le démarrage ...
1 nov. 2009 à 22:43
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.
@+
1 nov. 2009 à 22:19
Merci à Willi pour ces précieux conseils
1 nov. 2009 à 16:59
++
1 nov. 2009 à 01:03
Pour les Runs je pense avoir compris merci :)
J'en profite pour mettre la note max. 10 pour le contenu de la source et tes réponses !
29 oct. 2009 à 21:06
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+
29 oct. 2009 à 20:27
Je bosse autour du système de fichiers NTFS je devrais m'en sortir avec ta source ! D'ou mes questions :)
Si tu as un bon lien je veux bien l'anglais me fais pas peur car je trouve un bon nombre de site ou c'est trop léger voir incomplet.
29 oct. 2009 à 18:56
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+
29 oct. 2009 à 11:36
Certains attributs sont en permanance résidents mais pour les autres j'avoue j'ai même après ton explication un peu de mal à piger l'histoire de la runlist avec les attributs non résidents.
Autre question concernant les types attributs existant. Qu'est ce que les attributs 'ATTRIBUTE_LIST','EA_INFORMATION','INDEXROOT' et 'INDEX_LOCATION' ??
Est-il possible de retrouver l'offset de départ d'un fichier ? (je ne parle pas dans la MFT).
Willi.
29 oct. 2009 à 07:03
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+
28 oct. 2009 à 23:01
Dans ta source et meme dans d'autres je retrouve régulièrement le terme de "Runs" genre RunsCount RunsList.
Quelle est sa définition au sein du système de fichier NTFS ?
Willi.
30 août 2009 à 17:13
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
30 août 2009 à 16:46
Ce que je voulais dire c'est utiliser un peu les pratiques d'orienté objet.
Par exemple, les structures de données. Un bon cas est la structure du Boot sector et le BPB. vaut mieu d utiliser une structure de données avec quelques méthodes statiques pour les opérations courantes(Récupération du BS d'un device).
Apres une petite analyse, j ai vue que le code est presque a 100 orienté modules et GUI, ce qui rend l'apprentissage depuis le code trop difficile
Personnellement, j ai trouvé pas mal de trucs que je chercherais mais après une lecture approfondie de la spécification FAT de microsoft.
Quand même, un source noble sur le net ;-)
Salutations
30 août 2009 à 16:40
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
30 août 2009 à 16:25
30 août 2009 à 16:20
26 août 2009 à 15:55
26 juil. 2008 à 20:33
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
26 juil. 2008 à 13:11
Je me suis renseigné sur le format RAW et j'ai appris que c'est un format propriétaire surtout utilisé dans les appareils photos numériques et téléphones mobiles entre autres.Ce format sert pour les Memory Cards de ces appareils.
Par extension on dit aussi que le format RAW est un format brut pour une partition.
J'ai créé une partition RAW sur mon PC ( on crée une partition sans la formater)
Dans mes disques logiques elle est reconnue mais on demande d'insérer un support c'est à dire qu'on ne reconnait pas le système de fichiers de cette partition. Et de plus il n'y en a pas.
Dans disque physique j'ai ma partion NTFS plus cette partition RAW. La partition RAW est reconnue comme une partition FAT 16 ( code 06) dans la cartographie du disque.Mais on voit très bien en affichant le 1° secteur de la partition RAW que celui-ci est vide et ne correspond donc point à un secteur de boot de partition NTFS ou FAT.
quand au problème des provilèges j'ai toujours été admin sur mon poste chez moi.Je vais regarder ce que l'on peut faire.
a+ et bonne prog
26 juil. 2008 à 12:43
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,
@+
26 juil. 2008 à 00:56
e me suis renseigné sur les partitions RAW : pour moi ce sont des partitions qui ont été créées mais qui n'ont pas été formatées ( elles ne contiennent pas de systèmes de fichiers)
Par contre on peut accéder à cette partition en bas niveau (accès direct au disque avec la lecture et l'écriture des secteurs)
C'est pour cela que le projet en Delphi ne plante pas car il ne se contente que de lire et écrire des secteurs disque
Je vais essayer de créer une partition RAW sur mon PC et voir ce qu'il en est.
A+
26 juil. 2008 à 00:12
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
25 juil. 2008 à 21:25
tu dis : La MMC est bien reconnue mais seulement en tant que disque physique, pas logique (RAW).
en tant que disque physique arrives-tu à visionner les secteurs en cliquant sur celui dans la liste des disques physiques( une form apparait et visionne le 1° secteur ainsi que les caractéristiques du disque et son partitionnement)
La MMC apparait-elle dans les listes logiques en tant que partition
Ta MMC est -elle une carte mémoire d'appareil photo ? car j'ai jamais testé avec cela
25 juil. 2008 à 21:02
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 ... :-)
@+
25 juil. 2008 à 20:56
C'est vraiment très étrange, ca ne fonctionnait pas, (erreurs d'accès), recompilé plusieurs fois sans succès,
je le lance en tant qu'Administrateur, ma machine plante complètement,
quelques heures plus tard (après reboot) cela fonctionne normalement et sans élévation de privilèges ...
Je vais tester un peu plus pour mon usage et je te rapporterais des bugs, si j'en trouve.
ciao;
25 juil. 2008 à 18:16
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 +
25 juil. 2008 à 18:03
Je m'en sers pour lire une MMC au format RAW (Application pour lire/écrire sur une memory card de Pioneer CDJ1000)
Visiblement ça ne marche plus sous Vista : http://support.microsoft.com/kb/942448
Quel est ton pronostic pour Vista ?
Merçi,
28 juin 2008 à 15:28
Bien le bonjour à tous et bonne prog
22 juin 2008 à 00:35
Xp utilise l'ISO 9660 pour les CD et DVD et Vista utilise l'ISO 13346 UDF ce qui fait que le CD d'installation de Vista est illisible avec le programme
De plus les CD audio ne fonctionnent pas avec le programme sous Vista
Des problèmes au niveau des disques durs étaient apparus mais ont été solutionnés
Devant cette non-compatibilié Microsoftienne la source est uniquement compatible Windows XP
18 juin 2008 à 22:50
22 avril 2008 à 23:32
21 avril 2008 à 17:50
12 mars 2008 à 18:18
Il faut dire aussi que cela n'est pas facile à faire en VB net après 10 ans de programmation en VB4,puis 5 et enfin 6.
Si tu as des idées pour la présentation elles sont les bienvenues.Bonne prog à tous
12 mars 2008 à 17:53
12 mars 2008 à 17:51
Excellent travail, vivement la gestion des autres systèmes de fichiers ;-)
12 mars 2008 à 17:29
11 mars 2008 à 17:25