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.

[Médinoc]

En fait, je pense avoir compris ton argument, et tu as raison: Alors que *n*x propose officiellement la libc (qui est incluse dans la Single Unix Specification), la libc n'est pas une "feature" de Windows mais un détail d'implémentation.

Visual <=6 et Windows utilisant la même DLL pour la libc n'est qu'une "coincidence", et ce que fait MinGW n'est qu'un odieux parasitage non-supporté par Microsoft (et ses limites apparaissent quand on commence à jouer avec les long double).

[baccali]

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?

Parce que justement ce ne sont pas eux qui ont optimiser ni même créer ces fonctions et qu'ils ont leur API bien à eux. Ceux qui ont créer la Libc est l'équipe de l'IDE.

<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).

Désolé mais j'ai pas très bien saisis ce que tu as voulut dire par là? Pourquoi chercherai-tu à utiliser une librairie portable pour faire un système d'exploitation? Pour Math.h, tu peux utiliser les Maths de la libC comme tu peux utiliser une autre librairie. Combien de programme les utilisent ces fonctions. Par contre pour les autres Windows propose son API

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).

C'est vrai, si tu cherches de la portabilité, c'est pas l'API Win32 qu'il faut utiliser! Pourquoi dis-tu que malloc est plus facile à déboguer?

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().

Non tu ne m'as pas compris. Je n'ai pas dit que les fonction d'un noyau SUS était les fonctions de la libc, mais que la libC est l'interface OFFICIELLE (et la seule?) pour pouvoir utiliser ces système sans avoir à dialoguer avec le noyau.

Par contre sous windows, elle n'est là que parce que tout le monde l'utilise mais elle n'a rien à voir avec le système. Windows propose L'API Win32 (qui ne sont pas du tout les fonctions du Noyau) pour interfacer avec le noyau. C'est comme si tu disais que parce que tout le monde utilise la librairie curse et qu'elle est dans (quasiment?) toutes les distributions Linux, elle est nécessaire au Système!

Ce que je veux dire c'est que Windows a eut la main forcé pour inclure cette Lib. C'est du business avant tout et de toute façon c'était devenu ingérable entre le dll Hell lié au msvcrt (80, 90 etc...) et la gestion de la mémoire! La preuve en est qu'elle est là, mais toute utilisation de la LibC est déconseillé. Bien sûr ce n'est pas dit comme çà, mais plus tu lis la doc msdn et plus tu vois des implémentations Windows des fonctions de la LibC avec marqué "cette fonction remplace telle fonction de la libC de façon plus sécurisé". Si on prends un exemple parmis les fonctions de string, strcpy remplacé par strcpy_s puis finalement par stringcchcopy. Et c'est pareil pour les autres.

Donc j'ai du mal à croire qu'ils conseille de ne pas utiliser une librairie dont ils se base pour leur système!

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.

Ah bon? UNIX est détenu par l'Open Group! The Open Group Base Specifications Issue 6! POSIX y ajoute des extensions (en particulier les RT Signals) mais les signaux sont bien né chez AT&T.

[Médinoc]

Parce que justement ce ne sont pas eux qui ont optimiser ni même créer ces fonctions et qu'ils ont leur API bien à eux. Ceux qui ont créer la Libc est l'équipe de l'IDE.

Tu sais, il y a des limites au "not invented here", surtout quand on a une interface standardisée. Et je ne vois pas pourquoi l'équipe de l'IDE se chargerait de développer des routines bas niveau en assembleur; ce serait plutôt le travail des équipes qui bossent sur l'optimiseur du compilo.

Désolé mais j'ai pas très bien saisis ce que tu as voulut dire par là? Pourquoi chercherai-tu à utiliser une librairie portable pour faire un système d'exploitation? Pour Math.h, tu peux utiliser les Maths de la libC comme tu peux utiliser une autre librairie. Combien de programme les utilisent ces fonctions. Par contre pour les autres Windows propose son API

Tu poses la question à l'envers: Pourquoi faire un effort conscient pour ne pas utiliser les fonctions standard (que tu connais forcément et dont tu sais ce qu'elles font) quand tu n'as pas besoin d'autre chose?

Pourquoi dis-tu que malloc est plus facile à déboguer?

Parce qu'il y a des fonctions de diagnostic pour ça (Le "Debug Heap") dans la version Debug de la CRT.

Non tu ne m'as pas compris. Je n'ai pas dit que les fonction d'un noyau SUS était les fonctions de la libc, mais que la libC est l'interface OFFICIELLE (et la seule?) pour pouvoir utiliser ces système sans avoir à dialoguer avec le noyau.

Par contre sous windows, elle n'est là que parce que tout le monde l'utilise mais elle n'a rien à voir avec le système. Windows propose L'API Win32 (qui ne sont pas du tout les fonctions du Noyau) pour interfacer avec le noyau. C'est comme si tu disais que parce que tout le monde utilise la librairie curse et qu'elle est dans (quasiment?) toutes les distributions Linux, elle est nécessaire au Système!

Là-dessus, tu as raison (voir mon post précédent).

elle est là, mais toute utilisation de la LibC est déconseillé. Bien sûr ce n'est pas dit comme çà, mais plus tu lis la doc msdn et plus tu vois des implémentations Windows des fonctions de la LibC avec marqué "cette fonction remplace telle fonction de la libC de façon plus sécurisé". Si on prends un exemple parmis les fonctions de string, strcpy remplacé par strcpy_s puis finalement par stringcchcopy. Et c'est pareil pour les autres.

Mauvais argument, car Microsoft milite pour faire inclure ces ajouts dans le standard. Ils ont déjà déposé des requêtes pour ça. En gros, ils veulent que leurs fonctions deviennent la libc.
De plus, nombre de leurs DLLs référencent toujours les anciennes fonctions, donc on ne peut pas vraiment dire qu'ils ne les utilisent pas.

Ah bon? UNIX est détenu par l'Open Group! The Open Group Base Specifications Issue 6! POSIX y ajoute des extensions (en particulier les RT Signals) mais les signaux sont bien né chez AT&T.

Je voulais dire qu'UNIX n'avait pas le monopole des signaux, car certains sont bel et bien définis dans la libc. Mais c'était un mauvais argument de toute façon.

[baccali]

Tu sais, il y a des limites au "not invented here", surtout quand on a une interface standardisée. Et je ne vois pas pourquoi l'équipe de l'IDE se chargerait de développer des routines bas niveau en assembleur; ce serait plutôt le travail des équipes qui bossent sur l'optimiseur du compilo.

De toute façon quand je parlais de l'équipe de visual studio je parlais pas seulement de ceux qui font l'interface graphique. Aucune de ces équipes, si effectivement deux équipe il y'a, ne sont liées au Système Windows lui même si je peux dire çà comme çà. On pourrait même dire qu'ils n'ont pas besoin de connaître les sources du noyau pour faire leur boulot, seulement de la doc que nous nous avons. C'est comme si Windows avait pris une entreprise tiers pour leur dire qu'ils ont besoin d'un environnement de programmation agréable et efficace (je dis pas!) pour le programmeur lambda! Je ne prétend pas que c'est le cas ni savoir comment Windows fonctionne mais c'est pour te dire que msvcrt.dll n'a rien à voir avec le système Windows. C'était çà la question C'est comme si tu me disais que posx.dll est de base dans les installs Windows donc les gars qui font le système n'arrêtent pas d'utiliser des mmap et consor!

Tu poses la question à l'envers: Pourquoi faire un effort conscient pour ne pas utiliser les fonctions standard (que tu connais forcément et dont tu sais ce qu'elles font) quand tu n'as pas besoin d'autre chose?

Parce que justement ces fonctions standard sont implémentées à partir de nos fonctions à nous! Donc le vrai cassage de tête serait de créer des fonctions puis d'utiliser des fonctions d'un autre qui utilisent elles même mes fonctions à moi!!! Je ne parle pas du programmeur lambda! Je parle de l'équipe chargée de l'interface au noyau (Win32, NTdll et kernel32).

Parce qu'il y a des fonctions de diagnostic pour ça (Le "Debug Heap") dans la version Debug de la CRT.

Ah ok cool je ne connaissais pas merci!

Mauvais argument, car Microsoft milite pour faire inclure ces ajouts dans le standard. Ils ont déjà déposé des requêtes pour ça. En gros, ils veulent que leurs fonctions deviennent la libc.
De plus, nombre de leurs DLLs référencent toujours les anciennes fonctions, donc on ne peut pas vraiment dire qu'ils ne les utilisent pas.

Pourquoi mauvais argument? Je m'en doutais un peu mais j'ai l'impression qu'on ne débat plus exactement sur la même chose.

La question de base (même si c'était déjà une dérivation de la question principale, d'où la découpe de la discussion) était de savoir si l'équipe Windows utilise la libc. Je ne parle pas de Microsoft au grand complet, ceux qui font les programmes tiers comme IE ou cmd.exe, mais l'équipe "du noyau" si je peux dire! Donc est-ce que la libc est absolument nécessaire sous Windows et apparemment on est d'accord sur ce sujet et ta réponse appuie encore plus cette affirmation. Mais je n'oserai jamais prétendre que les codeurs d'applications, WIndows ou autres, sont fous d'utiliser la libc. Je pense juste que c'est une question de choix mais je ne condamne pas et je pense que Microsoft non plus d'ailleurs car je ne pense pas qu'il y'ait un ordre à l'équipe d'Office qui stipule qu'ils ne doivent pas utiliser la libc mais l'API native. L'équipe Windows met à disposition l'API pour leur noyau mais n'impose pas au reste de l'utiliser.

Sur ton sujet tu as aussi totalement raison! Si je suis un codeur qui ne veut pas autre chose de mon appli que faire ce qu'elle doit faire, si l'appli n'est pas super poussée et qu'il y'a autant de "trucs" pour me faciliter ma tâche comme le debug heap, pourquoi pas! (Perso je me suis fait une petite lib perso pour la surveillance de la mémoire de mes processus pendant mes tutos sur la programmation Windows et j'en suis pleinement satisfait pour le moment mais peut-être ton lien me donnera peut-être de nouvelles choses à surveiller). Par contre ce qui est sûr c'est que si je cherche un meilleur contrôle de mes applis, si par exemple je préfère utiliser HeapAlloc au lieu de VirtualAlloc, ou que je veux faire des trucs un minimum compliqués avec mon appli, on revient forcément à l'API native. Donc pour moi je trouve juste qu'il est plus "logique" d'utiliser l'API native dès le départ mais je ne condamne aucunement ceux qui trouvent des avantages à utiliser la libc. (par exemple comme tu as dis si on veut faire un bout de code qu'on veut portable pour pouvoir le réutiliser le plus rapide c'est effectivement la libC).

[Melem]

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!

Bon, je reformule ma question : pour l'allocation de mémoire sous *n*x, tu as mmap et brk côté appels systèmes et malloc et sbrk côté lib C. Peux-tu m'expliquer brièvement comment fais-tu le choix entre ces différentes fonctions pour allouer de la mémoire ?

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?

Sous *n*x, il y a sans doute plus d'apport de la lib C que sous Windows, la lib C a vu le jour en même temps que la réécriture d'Unix en C, personne ne le nie. Mais ça n'empêche pas que d'autres systèmes, écrits en C, comme Windows, ont été également écrit avec l'aide de la bibliothèque standard du C. Dans les deux cas (Windows ou *n*x), l'implication de la bibliothèque standard est plus grande dans la couche au-dessus du noyau que dans le noyau lui-même.

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?

Les deux. D'une part, la lib C est plus simple à utiliser que l'API native et d'autre part, je répète que je vois mal des programmeurs C se priver de sa bibliothèque standard lorsqu'on peut l'utiliser. D'autant plus que certaines fonctions de la lib C (<ctype.h>, <math.h>, fonctions de tri - nombres aléatoires - certaines conversions - ... (<stdlib.h>), etc.) n'ont aucun équivalent dans l'API native. Win32 (le sous-système, son API et les applications standard de Windows) a donc très certainement été écrit à l'aide la bibliothèque standard du C (qui je rappelle, est proposée par différents fichiers, dont msvcrt.dll). Dès lors que cette bibliothèque (on s'en fout ici de la version utilisée) devient indispensable pour l'écriture de Win32, les développeurs auront encore moins d'envie de se priver des autres fonctions pratiques (entrées/sorties, manipulation des chaînes, mémoire, etc.) lorsqu'elles correspondent aux besoins. De plus, nous avons vu que de nombreuses DLLs (shell32.dll, ole32.dll, advapi32.dll, ...) et applications (explorer.exe, services.exe, lsass.exe, ...) importantes de Windows importent des fonctions de la bibliothèque standard du C depuis msvcrt.dll, ça veut dire ce que ça veut dire non ?

N.B.: Désolé je n'ai pas pu tout lire, mais j'essaierai quand j'en aurai le temps.

[baccali]

Bon, je reformule ma question : pour l'allocation de mémoire sous *n*x, tu as mmap et brk côté appels systèmes et malloc et sbrk côté lib C. Peux-tu m'expliquer brièvement comment fais-tu le choix entre ces différentes fonctions pour allouer de la mémoire ?

Comment? Voici mon raisonnement!

1. Les fonctions du noyau changent selon le *nix.
2. MAIS Sous les *nix like, la libC est l'interface officielle.
Conclusion, Si je veux faire une application "UNIX", si je veux être sûr qu'elle fonctionne sous HP HUX, SOLARIS, BSD ou autre, vaut mieux utiliser la libC.

Par contre sous Windows, l'interface officielle n'est pas la libC mais l'API donc si je veux une appli qui marche sur les NT, Windows 7, XP, Vista, j'utilise l'API Win32. Par exemple, sous Windows 8, l'interface officielle c'est le Windows RunTime. Si tu veux une appli qui "marche" dessus en exploitant correctement le système tu chipotes pas tu l'utilises.

Sous *n*x, il y a sans doute plus d'apport de la lib C que sous Windows, la lib C a vu le jour en même temps que la réécriture d'Unix en C, personne ne le nie. Mais ça n'empêche pas que d'autres systèmes, écrits en C, comme Windows, ont été également écrit avec l'aide de la bibliothèque standard du C. Dans les deux cas (Windows ou *n*x), l'implication de la bibliothèque standard est plus grande dans la couche au-dessus du noyau que dans le noyau lui-même.

Je ne te comprends vraiment pas. En fait si je crois que je comprends ce que tu veux dire mais le problème c'est que tu ne fais pas la distinction entre l'environnement d'un Windows 7 et de Windows lui même. En gros pour toi tant qu'il y'a marqué Microsoft dessus c'est Windows.

D'ailleurs en parlant d'histoire, Avant de créer Windows et même lors de la création de Windows, Microsoft avait déjà son language, le Microsoft BASIC et UNIX n'était qu'un système comme un autre. Donc c'est pour te dire qu'écrit en C ou non, Windows avait déjà ses propres standard et ses propres fonctions en assembleur. Mais étant un logiciel commercial et avec ce qu'est devenu la libc, quel système peut se permettre aujourd'hui de se proclamer environnement de programmation sans libC. Maintenant Bill Gates ne surveille pas tout non plus et même si c'était le cas, qu'est ce qu'il en aurait à foutre que wininit utilise la libc au millieu des autres dlls (Wintsa, cryp ...). Mais ce n'est pas pour çà que si l'équipe qui fait l'environnement desktop utilise à fond posx.dll qu'on pourra dire : "Ouai, la posx.dll est devenu un standard incontournable (ce qui au passage est inévitable et windows l'a bien compris car ils commence à l'intégrer) donc Windows est écrit avec les fonctions posix CQFD".

Pour le reste pour ne pas me répéter je te réponds ici message -> http://www.developpez.net/forums/d11...ement-windows/

Et au fait, PERSONNELLEMENT je ne trouves pas que les fonctions de la libc soit plus simples que celle Win32 pour un peu que tu saches ce que tu fais et comment marche Windows! Elles sont juste plus courtes et la façon de programmer est différente (surtout dû au COM) mais c'est pas plus mal et malgré que je sois programmeur Unix depuis pas mal de temps, je commence à préférer de plus en plus la programmation Windows mais c'est un avis perso, on écoute pas tous la même musique et pendant que j'écris ce message je programme un serveur sous linux donc...

[Médinoc]

Mec, je programme en Win32 depuis des années et je peux t'assurer que les fonctions de la libC sont en effet plus simples à utiliser.

Qu'il s'agisse de fonctions reposant sur l'API native (fprintf(), malloc(), etc.) ou non. Je n'utilise les fonctions à plus bas niveau que quand j'en ai besoin.

[baccali]

Oui je comprends bien et je ne t'en juge pas! C'est juste que le sujet c'est "Windows utilise-t-il la libC" donc c'est ce que je cherche à confirmer ou infirmer. Si tu les trouves plus simples c'est ok, perso moi je les trouve juste plus courtes à taper mais avec comme prix à payer que tu perds en sécurité, (en perf?) et en contrôle sur ton appli donc çà va pour les trucs plutôt basiques. Mais si je veux utiliser une autre librairie que celle Native au système, çà dépend ce que j'ai à faire mais étant d'UNIX à la base, j'utiliserai aussi la libc.

Je veux juste te faire comprendre que c'est ton choix à toi, comme celui de beaucoup, mais que c'est loin d'être indispensable sous Windows comme le disait Melem. Mais je ne nie pas son côté pratique (selon les situations). C'est pour cela que je demandais laquelle des deux on me conseillerai.

[Melem]

baccali, je te demande juste de traduire ce tout minuscule programme en Win32 pur, sans le moindre appel à la bibliothèque standard du C :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include <stdio.h>
#include <ctype.h>
#include <math.h>
 
#define PI_SUR_4 atan(1)
 
int main()
{
    const char * filename = "input.txt";
    FILE * f_in = fopen(filename, "r");
    if (f_in == NULL)
        perror(filename);
    else
    {
        int c, nb_puncts = 0, nb_chars = 0, indicateur;
        while ((c = getc(f_in)) != EOF)
        {
            if (ispunct(c))
                nb_puncts++;
 
            nb_chars++;
        }
 
        indicateur = tan((PI_SUR_4 * nb_puncts) / nb_chars);
 
        if (!feof(f_in))
            perror(filename);
 
        /* Ici appel de fonctions super specifiques a Windows necessitant */
        /* les valeurs de nb_puncts, nb_chars et indicateur.              */
 
        printf("Nombre de ponctuations : %d.\n", nb_puncts);
        printf("Nombre total de caracteres : %d.\n", nb_chars);
        printf("Indicateur : %.2f.\n", indicateur);
 
        fclose(f_in);
    }
    return 0;
}

Pense ensuite à l'effort qu'auraient du déployer l'équipe de développement de Windows s'ils s'étaient réellement privés de la bibliothèque standard dans le développement d'un logiciel de la taille de Windows.

[baccali]

1. Melem, Déjà je suis déçu de voir que tu penses encore çà mais bon sans vouloir te vexer tu m'as l'air d'être du genre quand je suis convaincu de quelque chose je m'y tiens et j'écoute plus trop ce qu'on me dit.

EDIT : Non! En fait je crois comprendre ce que tu dis et j'y réponds dans mon message d'après!

2. çà me fait un peu rigoler parce que ton application est vachement spécifique aux string et au math et malgré çà en plein millieu de ton code il y'a marqué que tu reviens à l'API Windows.
3. Ton code est vachement spécifiques aux chaines de charactères et aux maths (enfin surtout pour ispunct). Si je ne dois pas utiliser la libC pour çà il faudrait que je cherche des librairie pour les strings (ce qui ne coure pas les rue vue qu'il y'a la libc ). J'ai trouvé la bstring mais je verrai demain si elle est potable. Pour les librairies maths j'ai déjà donner quelques noms à Médinoc donc tu vas pas croire que la seule librairie au monde à avoir une fonction qui rempli la fonction de atan() c'est la libc quand même.

4. Qu'est ce qu'un ispunct viendrait faire dans le dévellopement d'un SE (je dis pas hein)? J'ai l'impression Tu continue à mélanger les cmd.exe et explorer.exe, Windows.exe!! (le dernier est fait exprès! ) Tu en as vu dans tous les depends que tu as fait? Si ils en aurait eut besoin à mon avis tu aurais déjà son équivalent. Pas qu'ils se refusent absolument à utiliser ispunct juste parce que c'est la libC, mais ils ne dépendent pas de la libC et si ils en ont vraiment besoin son équivalent devra se trouver dans une dll du système. (http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx)

5. Maintenant moi je voudrais te poser quelques questions : Quand tu ouvres le fichier comme çà. Le fichier a quoi comme attributs? Le fichier peut-il être partagé avec d'autres processus? Si tu "fork" un thread ou un processus, il pourra l'ouvrir lui aussi, Quelles sont les protection de l'ouverture du fichier?. C'est bloquant comme ouverture de fichier? Si tu veux vraiment controller tout çà tu dois faire d'autres appels alors qu'avec un CreateFile tout est réglé. Je me trompe? Pour le getc Readfile et ERROR_HANDLE_EOF et on a juste remplacé quelques charactère dans le code. Bref me dis pas que c'est du suicide sans libC de faire un logiciel (j'ai pas dit un parser ou quoi). Fais moi cette ligne de code avec la libC.

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
#include <windows.h>
 
int WINAPI main(void)
{
CreateSymbolicLink(szFileName, 
            szLinkName, 
            SYMBOLIC_LINK_FLAG_DIRECTORY);
IsTextUnicode(szFineName, StringCbLength(szLinkName), IS_TEXT_UNICODE_REVERSE_ASCII16);
/* Bon je m'arrête là*/
    return(0);
}

6. Tu prends un code au hasard un programme lambda pour argument!
Très bien alors fais moi ce "Hello World" avec la libC (çà reste du même accabit que la prog gdi) et dis moi comment le monde ferait si on avait pas la libgtk et pourquoi Windows se priverait de l'utiliser. Sachant que eux aussi ils ont leur fonction pour les strings ( ).

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
 
#include <gtk\gtk.h>
 
static void hello( GtkWidget *widget,
                   gpointer   data )
{
    g_print ("Hello World\n");
}
 
static gboolean delete_event( GtkWidget *widget,
                              GdkEvent  *event,
                              gpointer   data )
{
 
    g_print ("delete event occurred\n");
 
    return TRUE;
}
 
 
static void destroy( GtkWidget *widget,
                     gpointer   data )
{
    gtk_main_quit ();
}
 
int main( int   argc,
          char *argv[] )
{
    GtkWidget *window;
    GtkWidget *button;
 
    gtk_init (&argc, &argv);
 
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
 
 
    g_signal_connect (window, "delete-event",
		      G_CALLBACK (delete_event), NULL);
 
    g_signal_connect (window, "destroy",
		      G_CALLBACK (destroy), NULL);
 
    gtk_container_set_border_width (GTK_CONTAINER (window), 10);
 
    button = gtk_button_new_with_label ("Hello World");
 
    g_signal_connect (button, "clicked",
		      G_CALLBACK (hello), NULL);
 
    g_signal_connect_swapped (button, "clicked",
			      G_CALLBACK (gtk_widget_destroy),
                              window);
 
 
    gtk_container_add (GTK_CONTAINER (window), button);
 
 
    gtk_widget_show (button);
 
    gtk_widget_show (window);
 
    gtk_main ();
 
    return 0;
}

Pourquoi ils se prennent la tête avec du XAML dans Windows 8 alors que la gtk est là? On se le demande!

[Médinoc]

#5: Le principe, c'est que dans la plupart des applications on n'a pas besoin de contrôler tout cela: les valeurs par défaut suffisent.

Ce qui revient à ce que je disais: On n'appelle les fonctions bas niveau que quand on a besoin de quelque chose que les fonctions haut niveau ne supportent pas.

[Médinoc]

Au fait, j'ai regardé les sources des fonctions de printf de glib: Devine quoi, elles écrivent leur sortie avec fwrite().

Pas avec WriteFile(), et pas avec write(): Avec fwrite.

PS: GTK fait des casts de pointeur de fonction. J'ai déjà eu a aider quelqu'un sur le forum qui ne trouvait pas un bug à cause de ces maudits casts de pointeur de fonction.

En XAML, aucun risque.

[baccali]

Excuses moi Médinoc mais là on avance vraiment plus donc ce sera mon dernier message car ces derniers temps je passe plus de temps sur le fofo qu'à mon travail! Je veux bien continuer à discuter, mais tant que je vois un peu de "bon sens" (je n'entends par là rien de méchant! Juste un peu d'objectivité) de l'autre côté et surtout de l'écoute car si on doit buter sur chaque phrase que je dis au point de comparer xaml et la libc çà risque de durer longtemps. Sans compter melem qui reste sur sa position seulement par principe et une "logique" personnelle mais sans rien de concret.

Le sujet ici c'était : "Est-ce que WINDOWS utilise la libc". Ma réponse et mes arguments, NON! C'est une librairie apportée par ton compilo et non Windows. Ce qui veut dire que tu ne pourras jamais dire que Windows (le système) comporte une faille fondamentale et que Microsoft nous a berné quand tu verras une faille dans ta msvcrt.dll (si cette msvcrt.dll a bien été apporté par Microsoft car je rappelle qu'elle est redistribuable et que chaque compilo a la sienne). Je trouvé pile poil la même question sur stackoverflow. Je te donne le lien pour que tu puisses lire la dernière réponse, peut-être comprendras-tu mieux ce que je veux dire, sachant qu'une grosse tête de Microsoft était de la discussion : http://stackoverflow.com/questions/1...libc-under-nix

Maintenant si on ouvres un topic pour débattre sur les avantages de la libc par rapport à telle ou telle librairie, crois moi ou non mais je serai le premier à la défendre, avec pour premier argument qu'on la trouve sur quasiment tous les systèmes.

Et au fait Médinoc : C'était un exemple comme un autre. La glib c'est la gnome library. Donc un truc purement linux à la base et aucun portage digne de ce nom n'a été fait sous Windows. Je crois d'ailleurs que tu dois toujours la compiler avec MSYS non? ou que sans GnuWin32 pas de glib! L'un des deux il me semble. J'ai jamais essayé! En tout cas c'est donc normal qu'elle n'ait pas de source Windows ou très peu et devines quoi, sous windows g_win32_error_message n'utilise pas errno mais GetLasError()! Si tu veux un exemple un peu plus parlant vas voir la librairie Thunk32.dll et dis moi si elle est reliée à msvcrt.

Pour répondre l'argument de melem : "J'aime bien cette librairie, tout le monde l'utilise au point qu'il est dans une install de base Windows donc c'est sûr que le système est basé dessus et écrit avec!". Que dire de la msxml alors? Elle aussi elle est présente dans tous les Windows grâce à IE et plein de logiciels l'utilisent, est-ce que Windows a été écrit avec des fichiers xml?

Et que dire de la librairie curse incluse aujourd'hui dans toutes les distributions Linux (Unix?). Peut-on dire que Linus Torvald a fait son système avec du curse? Je ne pense pas! C'est pas super comparable je sais lui il s'occupe du noyau mais bon c'est tout ce que j'ai trouvé.

Maintenant pour répondre à la question à proprement parler, si tu ne veux pas comprendre que je ne parle pas de ceux qui font les logiciels tiers que tu utilises lorsque tu utilises Windows, que ce sont des équipes bien distinctes qui font le type de programme que tu m'as montrer et qui n'ont rien à voir les unes avec les autres, même si tu préfères penser que le même exe d'internet explorer marchera aussi bien sur ton pda que sur ton windows phone ou sur ton desktop, libre à toi! Tu risques d'avoir des surprises si tu te retrouves à bosser sur un Windows embedded, mais bon c'est ton choix! Si tu préfères penser que les gars qui font l'API et le noyau Windows (NT) ne connaissent tellement pas l'API qu'ils ont eux même créer au point de chercher plus de "simplicité" dans la libc (qui elle même utilise leur API), c'est ton choix et malheureusement je ne pourrais jamais te fournir de preuve pour le contraire (peut-être même l'utilisent-ils sans le dire), libre à toi encore une fois, sur ce point je t'ai déjà dit depuis longtemps que je pouvais (difficilement) laisser passer (et le message du gars ne me convainc pas du contraire, lui même dit PRESUMABLY mais quand je vois qu'aucune librairie de l'API n'est liée (statiquement ou de façon dynamique) à msvcrt et l'idée qu'à Windows concernant la sécurité des fonctions de la libc, que comme dit Médinoc ils militent pour changer les standards, j'ai du mal à croire qu'ils aient codé un noyau avec! Et comme le dit Médinoc dans la plupart des applis on a pas besoin de contrôller tout çà! Mais là c'est le noyau qui le fait pour toi alors bonjour le noyau si il est blindé de strcpy sans protection du buffer de destination! Sans compter qu'aucune des dll système n'est reliée à un msvcrt, sauf peut-être en statique mais je demande à voir. Attention, je ne parle pas d'une ou deux dérivée des fonctions de la libc façon Windows, mais bien les fonctions de la libc, exportées par msvcrt.dll.). Mais que tu m'affirmes avec autant d'assurance que sans libc pas de Windows, que Bill Gates lui même code avec la libC, ou que le noyau NT et son API est pleins de strcpy, de memset, de sigaction etc...là j'émet une objection. D'ailleurs, sachant que NT est un dérivé de OS/2 (qui faisait de la concurrence à UNIX à ses débuts), quelqu'un sait si on trouve la libc de base dans un OS/2?

Je crois comprendre ce que tu dis et le pire c'est qu'il y'a peut-être mésentente. Prenons l'exemple de strcpy. Je suis d'accord avec toi qu'une fonction comme çà a clairement sa place dans un noyau et qu'elle simplifie la tâche. En même temps, si elle est standardisée c'est pour une raison! Mais pour moi si Windows utilise wstrcpy_s et stringcChcpy, la fonction remplie la même tâche, certe, mais n'empêche, ce n'est plus la libc! A mon sens tout du moins.

[Melem]

L'argument n'était pas que msvcrt.dll était essentiel à Windows (le Windows de nos jours, que nous utilisons sur nos PC tous les jours, pas Windows 1.0 ou Windows Phone 7) parce qu'il est par défaut sous Windows, car je n'ai pas dit que msvcrt20.dll l'était aussi par exemple. C'était juste une petite remarque que j'ai faite au début de la discussion pour t'inviter à constater que ce fichier est installé en standard avec Windows et non amené par un logiciel externe à Windows, contrairement à ce que tu soutenais. D'ailleurs, je le répète, on s'en fout de msvcrt.dll ici. Ici on parle des fonctions de la bibliothèque standard.

L'argument que tu refuses de voir est que des DLLs et des applications indispensables au fonctionnement correct de Windows importent des fonctions de la bibliothèque standard du C (des *printf et tout ce qui E/S en général, des fonctions de ctype, de math, de string, de stdlib, ...). Je t'avais donné des exemples pour cela.

Je ne peux pas traduire tes programmes en utilisant la bibliothèque standard du C uniquement, tes exemples montrent bien des cas où la bibliothèque standard est impuissante, et je n'ai jamais dit que la bibliothèque standard pouvait se substituer à n'importe quelle bibliothèque/API. Toi par contre tu dis qu'on peut toujours se passer de la bibliothèque standard, je te demande juste de le prouver en traduisant mon programme microscopique en programme n'utilisant que des fonctions de l'API Windows.

Enfin :

Le sujet ici c'était : "Est-ce que WINDOWS utilise la libc". Ma réponse et mes arguments, NON! C'est une librairie apportée par ton compilo et non Windows.

OK. Mais tu crois par contre que le compilo utilisé par Microsoft pour écrire le noyau n'a pas de lib C (je précise bien : une version allégée), sachant que le compilateur du DDK/WDK, qui permet de développer au même niveau que celui du noyau en a ... Cela m'a d'ailleurs fait penser à une question que je ne me suis jamais posé avant : dans quel fichier réside en fait l'implémentation de la lib C de l'environnement noyau ? Je me suis donc dit dans ntoskrnl.exe, le noyau lui-même, alors je l'ai ouvert dans Dependency Walker et ... vous connaissez la suite.

Liste des fonctions de la bibliothèque standard du C exportées par ntoskrnl.exe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
atoi
atol
bsearch
isdigit
islower
isprint
isspace
isupper
isxdigit
mbstowcs
mbtowc
memchr
memcpy
memmove
memset
qsort
rand
sprintf
srand
strcat
strchr
strcmp
strcpy
strlen
strncat
strncmp
strncpy
strnlen
strrchr
strspn
strstr
swprintf
tolower
toupper
towlower
towupper
vsprintf
wcscat
wcschr
wcscmp
wcscpy
wcscspn
wcslen
wcsncat
wcsncmp
wcsncpy
wcsnlen
wcsrchr
wcsspn
wcsstr
wcstombs
wcstoul
wctomb

Résumé pour ceux qui n'ont pas envie de voir la liste complète à cause de sa longueur, on a des fonctions :

- de stdio.h : sprintf & famille.
- de stdlib.h : conversions (ato*, mb*to*w*, ...), tri (bsearch, qsort), nombres aléatoires (rand & srand).
- de string.h : str*, mem*.
- de ctype.h : is*, to*.
- et de wchar.h.

Je précise en plus que j'ai volontairement exclu de la liste les fonctions non standard de la lib C de Microsoft (les fonctions "secure" et les extensions habituelles).

En résumé : Windows utilise des fonctions de biliothèque standard du C dans l'espace utilisateur comme dans l'espace noyau.

J'ose espérer que cela puisse clôturer cette discussion.

Merci à tous.