La question est de savoir pourquoi la limitation existe toujours. Certes, les fenêtres modernes peuvent augmenter le côté MAX_PATH
pour permettre des chemins plus longs. Pourquoi la limitation n'a-t-elle pas été supprimée?
- La raison pour laquelle il ne peut pas être supprimé est que Windows a promis qu'il ne changerait jamais.
Grâce au contrat d'API, Windows a garanti à toutes les applications que les API de fichier standard ne renverront jamais un chemin plus long que les 260
caractères.
Considérez le code correct suivant:
WIN32_FIND_DATA findData;
FindFirstFile("C:\Contoso\*", ref findData);
Windows a garanti mon programme qu'il remplirait ma WIN32_FIND_DATA
structure:
WIN32_FIND_DATA {
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
//...
TCHAR cFileName[MAX_PATH];
//..
}
Mon application n'a pas déclaré la valeur de la constante MAX_PATH
, l'API Windows l'a fait. Mon application a utilisé cette valeur définie.
Ma structure est correctement définie et alloue uniquement des 592
octets au total. Cela signifie que je ne peux recevoir qu'un nom de fichier inférieur à des 260
caractères. Windows m'a promis que si j'écrivais correctement ma candidature, ma candidature continuerait de fonctionner à l'avenir.
Si Windows autorisait les noms de fichiers plus longtemps que les 260
caractères, mon application existante (qui utilisait correctement l'API correcte) échouerait.
Pour quiconque appelle Microsoft à modifier la MAX_PATH
constante, il doit d'abord s'assurer qu'aucune application existante n'échoue. Par exemple, je possède toujours et j'utilise une application Windows écrite pour fonctionner sous Windows 3.11. Il fonctionne toujours sur Windows 10 64 bits. C'est ce que vous offre la compatibilité descendante.
Microsoft a créé un moyen d'utiliser les 32 768 noms de chemin complets; mais ils ont dû créer un nouveau contrat API pour le faire. D'une part, vous devez utiliser l' API Shell pour énumérer les fichiers (car tous les fichiers n'existent pas sur un disque dur ou un partage réseau).
Mais ils doivent également ne pas casser les applications utilisateur existantes. La grande majorité des applications n'utilisent pas l'API shell pour le travail sur fichier. Tout le monde appelle FindFirstFile
/ FindNextFile
et l'appelle un jour.