Discussion :

[baccali]

Bon après quelques tests et quelques question par ci par là, je ne suis toujours pas convaincu, après cette discussion, que la libc soit nécessaire au bon fonctionnement du système, par contre ce qui est sûr c'est que msvcrt.dll oui. Question noyau il est sûr qu'il ne l'utilise pas. Tout comme sous UNIX. Cependant, là j'ai par exemple un cmd.exe et powershell.exe sous les yeux, et j'ai beau faire pas mal d'opération depuis mais sous process explorer il ne me montre pas de chargement des fonctions de la libc dans msvcrt.dll. ( Powershell ne l'a même pas chargé. Ce qui est impossible sur Linux)Et cmd.exe exporte aussi des fonctions de OLE mais ce n'est pas pour cela que sans cette DLL çà crash (je viens de tester).

Donc bon!! Comme vienne de me le dire quelques connaissances plus rôdées que moi sur le sujet, le vrai problème, c'est que faire une panoplie de tests fiables prendraient trop de temps mais que la légende veut que le système se porte très bien sans libc (à voir). Il peut très bien être utilisé dans un petit module qu'on utilise jamais ou alors dans toute la source. Je ferai mon petit tour sur kd/NTSD quand j'aurai le temps car pour l'instant lorsque que je supprime msvcrt.dll sur mon XP pro (c'est une VM hein j'suis pas dingue!), il réapparait tout de suite. Je leur redemenderai si on peut passer à travers çà. On ne peut pas dire que msvcrt.dll, par contre l'inverse peut se dire. Pour l'instant, par exemple, j'ai msvcrt qui est chargé par explorer, mais qui dans la dll serait sur la fonction ... endrthreadex!! (D'ailleurs je pensais qu'elle était exporté par une dll du système celle là!)

Donc je continuerai mes test et vous tiendrai au courrant mais apparemment la libc elle même ne serait pas nécessaire! Par contre msvcrt.dll oui (ce qui confirme aussi pas mal de chose que j'ai pu lire ici et là!) et la libc, du moins dans les NT un peu récents, donc avec un msvcrt un peu récent, est de fait donc dispo à l'install du système.

Cordialement.

[Melem]

Bon, c'est déjà bien qu'on ait réussi à attribuer le même rôle à msvcrt.dll .

Bon après quelques tests et quelques question par ci par là, je ne suis toujours pas convaincu que la libc soit nécessaire au bon fonctionnement du système

Juste une question de bon sens : puisque Windows est pour sa majeure partie écrit en C, penses-tu vraiment que ses développeurs vont s'amuser à se priver de malloc, des fonctions de manipulation de chaîne et de mémoire, des fonctions mathématiques, etc. dans leur code ? Tu peux te dire oui, mais en tout cas, si le snapshot de Médinoc n'a pas suffit à te convaincre de l'importance de la lib C sous Windows, je ne vois pas ce qui pourrait.

Tu peux aussi simplement regarder le nom du produit associé à msvcrt.dll dans l'onglet détails de ses propriétés. Tu verras que ce sera marqué "MS Windows". Ca veut dire que le fichier fait partie du système Windows. Bien sûr, je rêve si je pense que cela va te suffir ...

[baccali]

Bon, c'est déjà bien qu'on ait réussi à attribuer le même rôle à msvcrt.dll .

msvcrt.dll ne veut pas dire libc. elle exporte aussi bien memset que endthreadex! On attribut donc pas exactement la même fonction à cette dll (mais selon ce que j'ai pu comprendre si c'était effectivement comme tu le dis je pense qu'elle s'appellerai pluto libc.dll!) et c'est même normal que plusieurs dll du système l'utilise. Mais çà ne veut pas dire qu'elle utilise les fonctions de la libc.

Bien sûr, je rêve si je pense que cela va te suffir ...

Et pas qu'un peu!!

Bon prenons le bon sens mais avant :
Pourquoi se priveraient-ils des malloc? Je te demande aussi pourquoi on a des HeapAlloc et des HeapFree.

Parce qu'il y'a marqué ms-windows sur la dll elle est nécessaire au bon fonctionnement du système? Sur les dlls .NET aussi (qui a aussi sa propre dll msvcrt associée je te rappelle), il y'a marqué Windows! Sont-elles nécessaire au système?

Le bon sens lui même maintenant :

Pourquoi s'en priveraient-ils? Parce que Windows est décomposé en plusieurs équipe travaillant sur leur produits à eux et que depuis le départ ils veulent instaurer leur propre environnement de dévellopement sans avoir à compter sur une équipe qui utilise leur fonction pour bosser. Quelle est l'utilité des PVOID, INT, VOID CHAR etc... C'est le serpent qui se mord la queue là. " Bon les gars On vient de créer HeapAlloc mais on va utiliser à partir de maintenant malloc, créé par une autre équipe et qui utilise elle même HeapAlloc et rajoute dessus plein de trucs dont on a pas besoin! D'ailleurs elle utilise meme pas tout le temps HeapAlloc mais virtualAlloc aussi, on a moins de controle sur nos appli mais bon c'est pas grave parce que nos applis, sous licence, sensées tourner et optimisée uniquement pour windows seront portables"?!!! Tu vois pas un malaise là? Windows s'en fout depuis le départ de la portabilité de leurs applis! çà, c'est le boulot d'une autre équipe, toujours windows néanmoins mais tu inverses un peu je pense : Ce n'est pas la libc qui as fait Windows mais Windows qui a fait la libc. A la base surtout pour du business si tu veux mon avis. (tout comme ils implément posix pour récupérer certains client nix!)

Ps : D'ailleurs je viens de me rappeler que certaines fonctions (de l'équipe de msvcrt si je me souviens bien) ne sont pas déclarée avec les macros windows car l'équipe a décider que leur fonctions devait plus suivre les conventions standard et ne pas "dépendre totalement de windows"! J'y ai jamais vraiment réfléchit alors que je me souviens m'être demandé ce que çà voulait dire...! En y réfléchissant peut-être parlaient-ils juste des versions de Windows au cas où une macro changerait de def. En plus je n'ai plus aucun souvenir de là où je l'ai lu (en général j'ai toujours un bout de phrase a rechercher dans mes pdfs mais là...) donc ça risque d'être dur à retrouver dans tous mes bouquins ou pire, internet. ça vaut pour ce que ça vaut mais c'est pas faute de le dire quand même.

[Melem]

msvcrt.dll ne veut pas dire libc. elle exporte aussi bien memset que endthreadex!

Comme tu veux. Dans ce cas libc.so ne veut pas dire libc non plus. Elle exporte aussi bien memset que itoa.

Plus sérieusement, on a d'une part la norme du langage C qui définit la bibliothèque standard du C et les diverses implémentations de cette bibliothèque, qui comporte souvent des extensions. Sous Linux, l'implémentation est libc.so, sous windows c'est msvcrt.dll.

Pourquoi se priveraient-ils des malloc? Je te demande aussi pourquoi on a des HeapAlloc et des HeapFree.

Pour la même raison qu'on a des mmap et des munmap sous nix. Personnellement, toi qui te présentes comme programmeur averti sous nix, tu utilises quoi d'habitude : mmap/munmap ou malloc/free ?

HeapAlloc permet de spécifier le tas sur lequel on veut allouer la mémoire et des flags qui n'existent pas dans malloc. Or, la plupart du temps, tu n'as rien à faire de ces paramètres, tu veux juste allouer de la mémoire de telle taille et dans ce cas là, malloc suffit. Donc je ne vois aucune raison d'utiliser HeapAlloc à la place de malloc lorsque cette dernière suffit. Et puis si ça ne tenait qu'à une fonction, ça se comprendrait, mais là sérieusement non.

Parce qu'il y'a marqué ms-windows sur la dll elle est nécessaire au bon fonctionnement du système?

Est-ce que c'est ce que j'ai dit ? J'ait dit que cela signifiait que la DLL appartenait à Windows, c'est-à-dire que ce n'est pas une DLL qui a été apportée par IE ou que sais-je encore, mais belle et bien une DLL de Windows. Et elle est nécessaire au bon fonctionnement de Windows parce que Windows l'utilise, pas parce que c'est marqué Windows dessus.

Sur les dlls .NET aussi (qui a aussi sa propre dll msvcrt associée je te rappelle), il y'a marqué Windows! Sont-elles nécessaire au système?

Sur plein d'autres fichiers aussi, ce qui veut dire, je le répète encore, qu'ils appartiennent à Windows, rien de plus. Après, essentiel ou pas, ça dépend du fichier en question. Par exemple, msvcrt.dll l'est, notepad l'est moins.

Quelle est l'utilité des PVOID, INT, VOID CHAR etc...

Uniformisation.

Bon les gars On vient de créer HeapAlloc mais on va utiliser à partir de maintenant malloc, créé par une autre équipe et qui utilise elle même HeapAlloc et rajoute dessus plein de trucs dont on a pas besoin!

Je ne vois pas où est le problème. On s'en sert quand on a besoin, on ne s'en sert pas sinon. Comme je te l'avais dit depuis le départ : lib C ou appels systèmes ? => Les deux, selon les besoins.

on a moins de controle sur nos appli mais bon c'est pas grave parce que nos applis, sous licence, sensées tourner et optimisée uniquement pour windows seront portables"?!!! Tu vois pas un malaise là?

On te l'a déjà dit mille fois : tu n'utilises pas une fonction de la bibliothèque standard du C dans un code spécifique à un système parce que c'est portable, puisque le code lui-même a été taillé pour un système précis, mais parce que tu penses qu'elle a été le meilleur outil disponible. Si on a besoin de plus de contrôle, oui, on va utiliser un appel système, mais la plupart du temps, les fonctions de la lib C suffisent.

Ce n'est pas la libc qui as fait Windows mais Windows qui a fait la libc.

Tu peux remplacer Windows par Linux, Unix, Mac OS X et tout ce que tu veux d'autre, ça sera toujours vrai. De manière générale, la bibliothèque standard du C a besoin d'un système pour exister, ce n'est pas avec elle qu'on fait un système. Si tu veux programmer un driver sous Linux ou sous Windows par exemple, tu n'as pas accès à la bibliothèque standard du C, parce que tu te trouves à un niveau inférieur. Aucun kernel n'est écrit avec la bibliothèque standard du C (bien sûr, une version épurée a éventuellement été utilisée, comme c'est le cas de Windows et de Linux). Par contre, une fois le kernel sur pieds, on peut l'implémenter puis l'utiliser pour développer les applications.

Pour terminer :

- La bibliothèque standard du C a-t-elle servie à écrire Windows ? Oui.
- Ces fonctions sont-elles importées depuis msvcrt.dll ? Dès fois oui (cf Médinoc), dès fois non (certains programmes ont pu être liés statiquement)

[baccali]

Pour la même raison qu'on a des mmap et des munmap sous nix. Personnellement, toi qui te présentes comme programmeur averti sous nix, tu utilises quoi d'habitude : mmap/munmap ou malloc/free ?

malloc et free LA PLUPART DU TEMPS, pourquoi? parce que c'est la seule API sous Linux qui face interface avec le noyau. Par contre sous Windows, Tu as une autre API qui est là de base, faite en parallèle avec le noyau et encore à côté tu as une libc qui n'est là que parce que trop de programmes utilisent la dll dans laquelle elle se trouve!

Suivont ton raisonnement et supposons que la libC soit à la base de Windows. Les signaux sont dans msvcrt. Ils sont dans Windows les signaux? C'est un concept Windows ou UNIX? Et errno? Les fonctions NATIVES de Windows l'utilisent ou utilise GetLastError? y'a-t-il ne serait-ce qu'une relation entre les deux?

HeapAlloc permet de spécifier le tas sur lequel on veut allouer la mémoire et des flags qui n'existent pas dans malloc. Or, la plupart du temps, tu n'as rien à faire de ces paramètres, tu veux juste allouer de la mémoire de telle taille et dans ce cas là, malloc suffit. Donc je ne vois aucune raison d'utiliser HeapAlloc à la place de malloc lorsque cette dernière suffit. Et puis si ça ne tenait qu'à une fonction, ça se comprendrait, mais là sérieusement non.

Tu essayes de me convaincre que la libc est plus simple à utiliser que les fonctions Windows ou que Windows ne fonctionne pas sans la libC? Parce que si tu veux juste me dire qu'utiliser la libC sous Windows est plus "pratique" (Si tant est que mettre des NULL là où tu n'as pas besoin des flags est plus difficile) que d'utiliser les fonctions natives lorsque tu ne veut pas faire un minimum de recherche et savoir quoi sert à quoi? Oui on est 100% d'accord. Maintenant est-ce que le gars de Microsoft qui as créer ces fonctions ne savent pas à quoi elles servent, là on est moins d'accord!


Bon je vais m'arrêter là pour les citations/réponses car de tout ce que j'ai lu du reste, je comprends que tu te méprends fondamentalement sur le système Windows.

Mais Tout d'abord j'aimerai que tu me montres où il est marqué que Windows a été créé ou écrit ou quoi que ce soit d'autre que tu aies voulu dire, avec la libC parce que c'est assez gros çà! Si tu veux dire que les gars qui ont fait le noyau ont sérialiser des bits avec des memset, des strings.h etc... Je peux difficilement laisser passer. Tout ce que j'ai pu apprendre là dessus c'est que le noyau est codé en C, une partie en C++ et les parties vraiment sensibles en assembleur comme les context switch par exemple mais je n'ai jamais entendu parler de libC et je serai surpris qu'ils n'aient pas pu utiliser leur API de Windows 98 pour le faire, vu que de toute façon la libC utilise le système sous-jacent. Par contre si tu parles des gars qui ont fait crss.exe par exemple, qui est ce que moi j'appelle windows, là je te dis stop tout de suite (vas voir ton depends), à moins que tu aies des infos concrêtes là dessus! J'avoue que j'ai vraiment du mal à saisir ce que tu veux dire par là et çà fait deux fois que tu le dis! A commencer par ce que tu entends par "Windows"?

Ensuite d'après toi CreateFile() est comparable à Open(), une fonction du noyau? Tu te trompes lourdement, CreateFile() utilise NtOpenFile() ou NtCreateFile(), et beginthreadex() appelle NtOpenProcess(), qui elles sont les fonctions du noyau (ou du sous système exécutif, comment savoir!). c'est avec elle que tu peux comparer même si ntkrnl.exe n'est pas uniquement composé du noyau Windows, on y trouve des sscanf_s etc... Et L'API Win32 dont font parti HeapAlloc etc... NE SONT PAS LE NOYAU WINDOWS mais une API comparable à la libC sous Unix. Où as-tu vu que tout ce qui n'est pas libc est un appel système? User32 et NTdll c'est le noyau çà? Dis toi que quand tu vois une fonction documentée par msdn, c'est pas forcément une fonction du noyau mais une fonction de l'API déjà là pour nous faciliter la vie et qu'elles font appel à une fonction Windows. Les sources étant cachées, on peut PARFOIS utiliser quelques fonctions documentées que Windows a exporté du kernel sous la pression des programmeurs et qui permettent de communiquer directement avec le noyau mais je peux te dire qu'elles se compte sur les doigts de la main! Fais un depends dessus et tu verras par toi même. Lorsque tu appelles ouvres un device, lis un fichier ou autre, tu n'appelles pas le NtReadFile du noyau directement, mais bien ReadFile, qui est une fonction de l'API et non du noyau. Cette API qui est mise à disposition par l'équipe qui dévelloppe le noyau (ou en très très très proche collaboration avec l'équipe de l'API).

Par contre, de l'autre côté, on a une équipe qui utilise cette API pour rajouter une autre API qui s'occupe de s'assurer que tu puisses utiliser Windows sans avoir à trop te mouiller avec le système sous-jacent. L'équipe msvcrt. Qui n'est nullement une API fondamentale à l'utilisation de Windows, mais quand bien même, permet de faciliter la programmation sous Windows (et je le répète cette équipe dis même ne pas vouloir se conformer aux standard Windows). Et c'est là que le bas blesse car cette API est devenue tellement utilisée, plus utilisée même que les NTDLL.dll, que certains logiciels présent dans une installation de Windows basique l'utilisent. D'où sa présence dans le dossier system32. Windows était obligé car si toutes ces applis apportent leur msvcrt soit on perd énormément de place sur le DD soit c'est en RAM qu'on ne s'en sort plus!

Certains compilo, la plupart d'ailleurs je crois, apporte leur propre msvcrt.dll et le système de renommer ses dlls avec le numéro de version à la fin n'est aucunement une politique Windows mais une politique WPF je crois. Regardes sur ton système et dis moi combien de msvcrt tu trouves ne serait ce que dans le dossier systeme32. msvcrt80, 90, icrt...

De plus, Malheureusement, certains oublient aussi que msvcrt, c'est pour RUNTIME et non LIBC. Deux choses bien différentes. Sous windows tu as __stdcall, _cdecl, fastcall etc... qui sont différents de comment libc.so initialise ses fonctions.

Malheureusement comme la plupart des programmes l'utilise, forcément vu qu'il n'y a pas que memset dedans mais des trucs quasi incontournables comme BeginThreadex (qui soit dit en passant appelle NtOpenThread) et surtout que c'est devenu la ligne la plus directe pour te conformer à l'ABI, certains pensent que msvcrt.dll = fonctions de la libC alors que le RT c'est pour RUNTIME et le MSVC c'est pour... MicroSoft Visual C++!!! Oui Oui l'IDE Visual Studio (l'autre équipe dont je te parlais). On comprends donc pourquoi pas mal de programme de l'install de base Windows y sont lié. Donc si tu veux te conformer à l'ABI sans avoir à initialiser ta stack etc... de toi même, c'est la façon la plus simple! Mais encore une fois celà ne veut pas dire que tu dois utiliser les fonctions de la libc qui sont dedans. Mais comme tu l'as si bien fait remarquer, c'est plus simple.

Je pourrais te donner une panoplie de bouquins à lire pour bien comprendre mais le plus simple, le msvcrt.dll de la situation reste encore Wikipedia je te donne les liens (mais sinon tu peux toujours lire Windows internal ou Windows via C/C++ si tu n'es pas convaincu)

By contrast, on Microsoft Windows, the core system dynamic libraries (DLLs) do not provide an implementation of the C standard library; this is provided by each compiler individually. Compiled applications written in C are either statically linked with a C library, or linked to a dynamic version of the library that is shipped with these applications, rather than relied upon to be present on the targeted systems. Functions in a compiler's C library are not regarded as interfaces to Microsoft Windows.

http://en.wikipedia.org/wiki/C_stand...t-in_functions
http://en.wikipedia.org/wiki/Windows...l_and_variants

Maintenant pour répondre à la question EST CE QUE MSVCRT EST ESSENTIELLE POUR UTILISER WINDOWS? en restant objectif, je vais te répondre oui et non! Oui pour l'utilisateur standard car trop d'applications EXTERNES l'utilisent, dont cmd.exe et explorer.exe (même gdi32.dll au moyen d'advapi.dll, tout en notant que adv c'est pour advanced) non pour le programmeur car c'est une API "deuxième niveau" et tu peux utiliser sans trop de mal le 1er niveau. Maintenant EST CE QUE LA LIBC EST ESSENTIELLE POUR WINDOWS, là je te réponds clairement NON! Analyse ton système comme je l'ai fait toute la journée et dis moi si les fonctions de la libC sortent dans les 100 premiers résultat (à supposer que tu n'utilises pas que du GnuWIN32). Si thunk32.dll est tellement utilisée par des applis que Windows l'intègre dans une install est-ce qu'elle est nécessaire au fonctionnement de Windows? Par contre sous UNIX, aucune API n'est fournie par le noyau, la libC est la seule interface au noyau et bien que se disant "neutre", elle est quand même vachement en relation, voire elle intègre les concepts SUS (signaux, errno). Et si tu veux mon avis ce n'est pas pour rien qu'on la différencie du C99. C'est la seule interface au noyau et si tu n'as pas les exports ou les source du noyau tu dois batailler sévère si tu veux programmer sans libc. Donc sous UNIX, oui on peut dire qu'elle est essentielle au système.

Et pour répondre à MA question, On peut utiliser les deux, je ne l'ai jamais nier et c'est pour çà que je posais la question d'ailleurs (2 façon d'arriver à Rome)! Mais je préfèrerai et conseillerai si la question m'était destinée, d'utiliser l'API native car elle te permet un meilleur contrôle de ton programme et t'offres 50 000 fois plus de possibilité et que de toute façon, dès que ton appli devient un peu sérieuse tu retombes inéluctablement sous cette API. Exception faite de beginthreadex et endthreadex qui peuvent même te faciliter la vie si il faut migrer sous .NET. Mais là de toute façon on ne parle plus de l'API libc mais du C runtime, de l'ABI sous-jacente!

Cordialement.

[Médinoc]

News flash: La version statique de la MSVCRT s'appelle libc.lib (ou libcmt.lib pour la version compatible multi-thread).

Si tu veux dire que les gars qui ont fait le noyau ont sérialiser des bits avec des memset, des strings.h etc... Je peux difficilement laisser passer.

Et pourquoi pas? Pourquoi les développeurs noyau se priveraient-ils des fonctions essentielles de string.h alors qu'ils ont déjà pris le temps de les optimiser en assembleur?

<string.h>, <math.h> etc. contiennent les meilleurs exemples de fonctions de la libc qui ne reposent pas sur le noyau (contrairement aux fonctions d'E/S) et peuvent donc être utilisées n'importe où, y compris dans celui-ci (mais en liaison statique).

De plus, pour en revenir à la question de base, n'oublie pas que même si tu fais une application pour Windows, tu peux toujours avoir besoin de porter un morceau de code dans une autre application pour un autre système. Dans ces circonstances, n'utilise pas HeapAlloc() là où malloc() suffit (d'autant qu'il y a d'autres avantages à utiliser malloc(), notamment en phase de débogage).


En gros, ton argument contre "Windows fournit la libc" est que les fonctions exposées directement par le noyau ne correspondent pas aux fonctions POSIX. Mais on peut dire la même chose des systèmes *n*x: Les fonctions POSIX exposées directement par le noyau ne correspondent pas aux fonctions standard C. Est-ce une raison pour utiliser systématiquement open() à la place de fopen()? Je rappelle qu'il n'existe pas d'implémentation "noyau" de fprintf().

PS: Les signaux ne sont pas un concept *n*x: Les signaux essentiels font partie du standard C, *n*x ne fait qu'y ajouter des extensions.