Pour info, ce fichier n'est absolument pas utilise par la stack tcp/ip, ce fichier est utilise par la resolution de noms(DNS client), la stack tcp/ip elle ne traite rien d'autre que des addresses IP. J'ai pris cet exemple pour te faire comprendre la logique dans laquelle des softs sont ecrits, ils peuvent sembler similaires de l'exterieur, et c'est normal car c'est le but, mais sont ecrit de maniere totalement differente de l'interieur.
Et je ne vois pas quels softs iraient lire ce genre de fichier, même sous les unix classiques personnes ne va lire /etc/hosts, c'est juste à la résolution de noms que le système va d'abord là avant de taper sur le DNS. Et c'est le boulot de l'OS, donc à la limite peu importe comment il fait. Ok pour les APIs communes, mais je ne voyais pas le fichier hosts comme une API...
Un fichier c'est une API, si tu regardes une fonction exportee, c'est rien d'autre qu'une description du format des donnees a envoyer, un fichier et son format c'est la meme chose. Tu peux prendre un /etc/hosts sur Unix et le transposer sur Windows tres simplement, voila un des avantages.
[^] # Re: troll ...
Posté par pasBill pasGates . En réponse au journal Bug dans le TCP/IP de Windows Server 2003. Évalué à 2.
Et je ne vois pas quels softs iraient lire ce genre de fichier, même sous les unix classiques personnes ne va lire /etc/hosts, c'est juste à la résolution de noms que le système va d'abord là avant de taper sur le DNS. Et c'est le boulot de l'OS, donc à la limite peu importe comment il fait. Ok pour les APIs communes, mais je ne voyais pas le fichier hosts comme une API...
Un fichier c'est une API, si tu regardes une fonction exportee, c'est rien d'autre qu'une description du format des donnees a envoyer, un fichier et son format c'est la meme chose. Tu peux prendre un /etc/hosts sur Unix et le transposer sur Windows tres simplement, voila un des avantages.