ça contredit cette page de MSDN (que tu n'as peut-être pas suivie dans les liens de référence de wikipedia).
Citation : - Tu n'as rien découvert dans tes expériences personnelles qui contredise Microsoft et tu n'as pas non plus découvert de fait nouveau.
http://msdn.microsoft.com/en-us/library/aa914353.aspx
Quant à découvrir un fait nouveau, je n'ai jamais eu cette prétention.
Non, c'est toi qui dois confondre.
Citation : - Tu fais des erreurs (par exemple tu confonds une entrée de FAT avec une entrée de répertoire).
Peut-être ne sait tu pas que les fichiers ayant un nom courts sont représentés par une entrée de 32 octets dans le répertoire et que les fichiers ayant un nom long sont représentés par une ou plusieurs entrées de 32 octets, contenant chacune, 13 wchar_t 16 bits du nom UTF-16, suivie d'une entrée du même type que pour les noms courts, contenant, entre autres, le nom court associé au fichier.
Je sais ce que je dis.
Relis le document plusieurs fois si nécessaire.
Chaque terme est important.
Non, c'est la wikipedia.
Citation : - Tu mélanges la limitation dû à un système de fichier avec les limitations d'un bus.
J'expliquais que FAT32 n'est PAS limité à 128 Go, et que si certaines personnes avaient des problèmes lors de la création de grandes partitions, c'était probablement lié à des limitations matérielles ou du BIOS, et non pas du système FAT32 lui même.
Pas seulement. Je n'ai lu la spécification que longtemps après avoir appris le C et le C++.
Citation : - Tu affirmes connaître le C et le C++ parce que tu as lû une spécification. Ca ne fait pas un peu court?
J'ai aussi programmé des utilitaires que j'utilise personellement.
Mon dernier projet est un éditeur hexadécimal (pas encore finalisé) qui gère des fichiers de taille (théorique) allant jusqu'à 2**64 octets, avec opération d'insertion, substitution, suppression, copier et coller, quasiment instantanées, car, plutôt que d'effectuer les opérations réellement, il se souvient seulement de la liste des opérations qui furent appliquées. Donc, la complexité est linéairement proportionelle au nombre d'opérations appliquées et non pas à la taille du fichier. Bon, d'accord, lorsque l'on sauvegarde le fichier, là, c'est obligé d'appliquer les opérations, mais, par quelques transformations des données d'édition, cette opération est optimisée.
Par exemple, suppose que tu aie un fichier de 20Go.
Tu copies les 10 derniers Go et les colle, avec insertion, au début du fichier.
Le fichier fait maintenant 30 Go.
Tu supprimes les 10 derniers Go.
A ce stade, tu obtiens un fichier dont les 2 dizaines de Go ont été échangées.
Maintenant, tu sauvegardes.
L'éditeur hexadécimal va automatiquement, via un buffer d'un méga-octet (paramètre réglable), échanger les deux parties du fichier, par bloc d'1 méga-octet.
L'algorithme que j'utilise procède en 3 étapes.
1) Conversion de la représentation sous forme de liste d'édition vers une représentation sous forme de liste d'intervalles du fichier d'origine et de chaines de caractères.
2) Conversion en une liste de lectures et d'écritures dans le fichier, par une fonction récursive, dont le principe est de sauver, dans un buffer, les données qui vont être écrasées, puis d'écrire le contenu de ce buffer aux endroits qui en ont besoin, avant d'écraser le contenu de ce buffer par de nouvelles données.
3) Application de ces opérations avec écriture d'un journal.
Le projet n'est pas finalisé, mais le principal fonctionne déja.
A la base, ça devait juste être une amélioration d'hexedit, mais en fait, il n'y a plus grand chose en commun.
Si tu veux du concret, lis donc mes posts sur comp.lang.c, comp.std.c, comp.lang.c++, comp.std.c++, et sur http://www.codeguru.com que je ne fréquente plus, faute de temps.
Mes nicknames sont: SuperKoko et NanoTech.
J'utilise aussi mon vrai nom: André GILLIBERT.
Ces derniers temps, j'ai aussi rapporté quelques bugs avec correctifs ou description détaillée du problème.
http://bugs.gentoo.org/show_bug.cgi?id=260637
http://bugs.gentoo.org/show_bug.cgi?id=256472
http://bugs.gentoo.org/255037
J'ai aussi fait quelques patches que je soumettrais peut-être aux développeurs des paquetages (si tu veux, je peux te les transmettre).
1) Support des fichiers de plus de 2 Go, via http, pour mplayer (simple substitution de atoi() par atoll() dans un fichier).
2) Support des fichiers de plus de 2 Go sur plateforme 32 bits pour thttpd (un peu plus subtil car thttpd mmap() les fichiers).
3) Petite amélioration du widget de la scollbar de libXaw.
Pas tout à fait, mais c'est suffisant pour comprendre comment manipuler le contrôleur, et moyennant la norme ATA, j'ai trouvé la commande de gestion de l'APM.
Citation : - Tu as écrit un court programme pour désactiver l'APM sur ton Windows 98. Sur le site que tu indiques il y a des exemples pour ce genre de programmes.
Désolé si je n'ai pas l'air sympa. Je suis un vieux con aigri. C'est ce qui arrive lorsque l'on passe trop de temps sur Internet.
