Fonctionnement de MinGw

J'ai commencé à utiliser mingw pour programmer en c et depuis que je me suis mis au c++, j'ai quelques questions...

Je comprend "en gros" comment un compilateur fonctionne. Et comment il va utiliser les librairies c standard selon l'os sûr lequel on compile le programme.(MSVCRT pour windows, libc ou quelque chose avec gcc pour les unix et linux je crois bien...)

Mais je me demandais... mingw... c'est gcc... qui utilise sa propre librarie (http://www.mingw.org/phpwiki-1.3.14/.../mingw-runtime)...

Si j'ai bien compris, le mingw runtime library permet de compiler un programme avec mingw (gcc) qui va tourner nativement sur windows en utilisant la librairie c de Microsoft (MSVCRT)...

Mais... comment est-ce que cela fonctionne pour compiler du c++? et même du java, objective-c, fortran avec mingw??

Il faut télécharger les packs de gcc, mais ensuite? Le programme tourne toujours en natif... Il utilise quand même la librairie c?? Même si c'est du fortran ou autre chose? Comment est-ce fait??

Dans le wiki de mingw, il est écrit ça pour le mingw-runtime :The MinGW Runtime is core package that contains headers and libraries to support C functionality.

C'est écrit pour le c... mais comment il fait pour le c++, le java et tout les autres??



Bref, j'en ai beaucoup à apprendre on dirait!

Merci beaucoup de votre aide

Alex

Que tu écrives un programme en fortran, en cobol, en C ou en C++, les compilateurs vont générer un code machine "similaire" mais qui ne pourra s'exécuter que dans un environnement particulier.
Dans cet environnement "particulier" se trouvera la libC ou son équivalent pour C++, fortran, ...

Le binaire généré pour s'exécuter sous mingw plantera si on "enlève" mingw pour essayer de l'exécuter sous Windows directement.

JAVA c'est différent. Le compilateur ne génère pas du code machine (au sens x86) mais du code qui pourra être interprété par une machine Java. Cette dernière étant un binaire exécuté par la "vraie" machine x86 qui tourne "dessous".

- W

Citation:

---

Envoyé par wiztricks

Le binaire généré pour s'exécuter sous mingw plantera si on "enlève" mingw pour essayer de l'exécuter sous Windows directement.
- W

---

MinGW génère des exécutables natif pour windows qui fonctionnent sans avoir à utiliser une dll (comme cygwin par exemple...)

Alors je comprend pas trop...

Ca veut dire quoi "natif" lorsqu'on lit dans Mingw contents

Citation:

---

mingw-runtime: Header files and import libraries for the default C runtime library, (also known as msvcrt), which is required by MinGW compiled programs running on the Microsoft Windows operating system.

---

Après on peut discuter de la taille de la couche qu'il y a... et s'accorder à dire que MinGW est plus light que Cygwin

-W

Euh, non… y'a pas d'environnement particulier ou quoi que ce soit !
C'est du pur natif, même pour le Java (gcj donne du code machine natif). En outre, pas le GNU libc sous le capot, ce qui explique pourquoi on est pas soumis à la GPL pour la distribution d'un programme compilé avec MinGW.

Le mingw32.dll, c'est juste un binding pour la runtime library C standard de Windows. Il suffit de voir la taille du fichier pour se rendre compte qu'il n'y a franchement pas grand chose dedans.
Après, pourquoi il y aurait besoin de binder, je n'en sais rien…

Pleins d'infos ici : http://www.mingw.org/wiki/MinGW


Pour revenir à la question initiale, à savoir pourquoi on a toujours une runtime library C derrière, quel que soit le langage, c'est une bonne question.

Je dirais que ça vient du fait que Windows soit lui-même codé en C et qu'il faille utiliser les instructions de l'OS pour qu'il veuille bien s'occuper de l'appli qu'on veut lui faire exécuter.

Autre théorie, le core de GCC contient un compilateur C. C'est vrai pour le package de MinGW, c'est vrai aussi sous Linux : le support du C doit être activé pour pouvoir supporter un autre langage.
Tout passe donc par le compilateur C. Le fait qu'il doit le dénominateur commun expliquerait donc pourquoi une lib runtime C.

Ou alors, c'est un peu des deux.

Je suis curieux de savoir, moi aussi :)

donc finalement, tout ce qu'on compile avec MinGW, que ce soit du java, du c++, ou du fortran, va utiliser la librairie c de windows pour la gestion de la mémoire et les entrées/sorties... non?

C'est ce que je suppose. C'est donc à confirmer !

Citation:

---

Envoyé par Florian Goo

Le mingw32.dll, c'est juste un binding pour la runtime library C standard de Windows. Il suffit de voir la taille du fichier pour se rendre compte qu'il n'y a franchement pas grand chose dedans.
Après, pourquoi il y aurait besoin de binder, je n'en sais rien…

Pleins d'infos ici : http://www.mingw.org/wiki/MinGW

---

Ma réponse contient un extrait de la documentation que tu cites et signale que c'est effectivement "petit".

Si on comprends la question initiale sur GCC et non sur MinGW... Se souvenir que la compilation d'un langage peut se faire en plusieurs étapes:
analyze lexicale, syntaxique, ..., génération de code,...

Ce qui permet à un compilateur moderne tel que GCC d'être découpé en:

• front-end: qui fait ce qui est spécifique au langage jusqu'à la génération d'un pseudo-code,
• back-end: il s'occupe de la génération du code machine à partir du pseudo-code

Le back-end suppose un minimum d'environnement d'exécution "au dessus" de l'abstraction apportée par la libc.
-W
Note: La réponse est simplificatrice, pour ce que çà intérresse voir l'architecture de GCC

Citation:

---

Envoyé par Alexandreg12

donc finalement, tout ce qu'on compile avec MinGW, que ce soit du java, du c++, ou du fortran, va utiliser la librairie c de windows pour la gestion de la mémoire et les entrées/sorties... non?

---

L'OS est toujours Windows et inutile de ré-écrire ce que fait déjà la librairie C qui vient avec.
-W

Citation:

---

Envoyé par wiztricks

Ma réponse contient un extrait de la documentation que tu cites et signale que c'est effectivement "petit".

---

Oui, nos posts se sont croisés.

Citation:

---

Envoyé par wiztricks

Si on comprends la question initiale sur GCC et non sur MinGW... Se souvenir que la compilation d'un langage peut se faire en plusieurs étapes:
analyze lexicale, syntaxique, ..., génération de code,...

Ce qui permet à un compilateur moderne tel que GCC d'être découpé en:

• front-end: qui fait ce qui est spécifique au langage jusqu'à la génération d'un pseudo-code,
• back-end: il s'occupe de la génération du code machine à partir du pseudo-code

---

Donc le pseudo-code en question, ce serait du C ?

Citation:

---

Envoyé par wiztricks

Le back-end suppose un minimum d'environnement d'exécution "au dessus" de l'abstraction apportée par la libc.

---

Si c'est que tu voulais dire par environnement d'exécution, on est d'accord :). Mais on utilise plutôt cette expression pour désigner une machine virtuelle (et aussi pour parler d'un contexte d'exécution d'un processus si j'en crois Wikipédia, mais ça n'a plus trop de rapport).

J'ai l'impression que le pseudo-code n'est pas du c, mais qu'il est toujours pareil pour tous les langages compilés avec gcc et que ce pseudo-code utilise la librairie c pour fonctionner (celle de microsoft pour MinGW)

Citation:

---

Donc le pseudo-code en question, ce serait du C ?

---

Le C subit le même traitement que les autres.
Ce qui est important c'est que ce langage intermédiaire soit là.
Initialement défini pour représenter du C ou du C++, il peut être utilisé pour représenter des langages similaires (procéduraux).
-W

Bonsoir,

Citation:

---

Envoyé par wiztricks

Le binaire généré pour s'exécuter sous mingw plantera si on "enlève" mingw pour essayer de l'exécuter sous Windows directement.

---

Citation:

---

Envoyé par wiztricks

Ca veut dire quoi "natif" lorsqu'on lit dans Mingw contents



Après on peut discuter de la taille de la couche qu'il y a... et s'accorder à dire que MinGW est plus light que Cygwin

-W

---

De mémoire les programmes que j'écrivais avec MinGW ne dépendaient que de msvcrt.dll (présente de base sur tous les Windows), et peut-être d'autres DLL classiques comme kernel32.

Citation:

---

Envoyé par Alexandreg12

donc finalement, tout ce qu'on compile avec MinGW, que ce soit du java, du c++, ou du fortran, va utiliser la librairie c de windows pour la gestion de la mémoire et les entrées/sorties... non?

---

C'est peut-être comme ça mais il n'y a pas d'obligation. Il pourrait utiliser une autre bibliothèque C standard, ou directement Win32, ou encore une autre bibliothèque.
Tu peux voir les dépendances de tes programmes avec celui-là : http://www.dependencywalker.com/.

mais j'ai quand même l'impression que gcc utilise une librairie c standard pour ça alors c'est pour ça que mingw utilise la librairie c standard de windows.

Maintenant, oui on peut utiliser une autre librairie c (comme le fait cygwin), mais le problème c'est qu'il faut absolument inclure cette librairie c avec notre application pour la faire fonctionner! Alors qu'avec mingw, la librairie standard de windows présente partout (bah, tant qu'il y a windows!)

Citation:

---

Envoyé par dapounet

Bonsoir,




De mémoire les programmes que j'écrivais avec MinGW ne dépendaient que de msvcrt.dll (présente de base sur tous les Windows), et peut-être d'autres DLL classiques comme kernel32.



C'est peut-être comme ça mais il n'y a pas d'obligation. Il pourrait utiliser une autre bibliothèque C standard, ou directement Win32, ou encore une autre bibliothèque.
Tu peux voir les dépendances de tes programmes avec celui-là : http://www.dependencywalker.com/.

---

J'ai du mal à comprendre comment quelqu'un d'autre que microsoft pourrait développer une bibliothèque c standard pour windows... Ou nimporte quelle bibliothèque du genre pour un autre langage... On va pas toujours se retrouver à utiliser ce que microsoft à fait à la fin?

Un compilateur -- quel que soit le langage cible -- peut soit generer du
code destine a etre directement execute par la machine cible (on parle
alors de code natif), soit du code destine a une machive virtuelle telle
que la JVM, cette machine virtuelle a elle alors plusieurs choix dont les
extremes sont une interpretation du code et une generation de code natif
(on parle de compilation JIT). Ce genre de choix de cible de compilation
est independant du langage, meme si generalement les compilateurs C et C++
generent du code natif et les compilateus Java generent du code pour la
JVM. Il est des exceptions, gcj -- le compilateur Java de GCC -- est
capable de generer du code natif (si j'ai bonne memoire aussi bien a partir
de code Java que de byte code pour la JVM).

Suivant les langages et les cibles, il n'est parfois plus pratique de
generer du code qui a besoin d'un certain support en plus de ce qui est
fourni par le processeur et l'OS. Deux exemples: si on cible un processeur
n'ayant pas d'instructions de calcul en virgule flottante, il est plus
simple de se lier avec une bibliotheque fournissant ce qu'il faut plutot
que de generer du code inline a chaque operation. Autres exemples,
l'utilisation des exceptions ou du RTTI en C++. Ce support peut aller
d'une simple bibliotheque qui n'est utilisee que dans des cas particuliers
(exemple du calcul en virgule flottante) a... en fait on peut considerer
les machines virtuelles comme un cas extreme.

Les langages ont generalement une bibliotheque standard plus ou moins bien
etoffee -- la tendance actuelle est a l'augmentation des services fournis
par cette bibliotheque.

Le mot runtime suivant le contexte designe soit le support necessaire pour
le langage, soit la combinaison de ce support et de la bibliotheque
standard.

GCC c'est un ensemble de compilateurs, comprenant entre autres un
compilateur C, un compilateur C++, un compilateur natif Java, une
bibliotheque standard C++, une bibliotheque Java. A noter qu'il n'y a pas
de bibliotheque standard C.

MinGW c'est GCC configure pour utiliser la bibliotheque standard C fournie
avec Windows (plus quelques extensions fournies avec MinGW parce
qu'absentes du runtime fournit avec Windows). Ses compilateurs C++ et Java
sont configurer pour utiliser les bibliotheques standards fournies avec
GCC.

Cygwin, c'est un environnement POSIX pour windows. Il comportait la
derniere fois que j'ai regarde GCC configure pour utiliser le meme
environnement d'execution que MinGW (autrement dit: bibliotheque standard C
de MS, extensions de MinGW, bibliotheque standard C++ et Java de GCC
compilees de maniere a ne pas dependre de la couche Cygwin) et un
environnement d'execution Cygwin (bibliotheque standard de Cygwin,
bibliotheque Posix de Cygwin, bibliotheque standard C++ et Java de GCC
compilees de maniere a bien s'interfacer avec la bibliotheque Posix de
Cygwin).

Citation:

---

Envoyé par Florian Goo

En outre, pas le GNU libc sous le capot, ce qui explique pourquoi on est pas soumis à la GPL pour la distribution d'un programme compilé avec MinGW.

---

La libc de GNU n'impose pas la GPL pour les programmes l'utilisant (la licence de la libc de GNU c'est la LGPL). Je n'ai aucune idee de la license de la couche Posix de Cygwin.

Citation:

---

Pour revenir à la question initiale, à savoir pourquoi on a toujours une runtime library C derrière, quel que soit le langage, c'est une bonne question.

---

On n'a pas toujours besoin d'une bibliotheque C. C'est simplement plus facile sous Unix -- ou l'interface de l'OS et la bibliotheque C sont intimement lies -- et ca permet de s'interfacer plus facilement avec des bibliotheques ecrites en C.

Citation:

---

Je dirais que ça vient du fait que Windows soit lui-même codé en C et qu'il faille utiliser les instructions de l'OS pour qu'il veuille bien s'occuper de l'appli qu'on veut lui faire exécuter.

---

Je connais beaucoup moins bien Windows qu'Unix, mais il me semble que la separation entre interface de l'OS et bibliotheque C y est beaucoup plus claire que sous Unix. Et que ce soit sous Unix ou sous Windows, le langage dans lequel est ecrit l'OS n'a que peu de rapport avec les interfaces.

Citation:

---

Envoyé par Alexandreg12

J'ai du mal à comprendre comment quelqu'un d'autre que microsoft pourrait développer une bibliothèque c standard pour windows... Ou nimporte quelle bibliothèque du genre pour un autre langage... On va pas toujours se retrouver à utiliser ce que microsoft à fait à la fin?

---

Pour pouvoir ecrire une bibliotheque standard C, il ne faut que quelques primitives d'interfacage au systeme, et ces primitives sont documentees pour Windows (CreateFile, etc). Cygwin utilise ces primitives -- et d'autres -- pour donner une interface Posix a Windows et fournit une bibliotheque standard C basee sur la couche Posix.

Citation:

---

Envoyé par Jean-Marc.Bourguet

On n'a pas toujours besoin d'une bibliotheque C. C'est simplement plus facile sous Unix -- ou l'interface de l'OS et la bibliotheque C sont intimement lies -- et ca permet de s'interfacer plus facilement avec des bibliotheques ecrites en C.

Je connais beaucoup moins bien Windows qu'Unix, mais il me semble que la separation entre interface de l'OS et bibliotheque C y est beaucoup plus claire que sous Unix. Et que ce soit sous Unix ou sous Windows, le langage dans lequel est ecrit l'OS n'a que peu de rapport avec les interfaces.

Pour pouvoir ecrire une bibliotheque standard C, il ne faut que quelques primitives d'interfacage au systeme, et ces primitives sont documentees pour Windows (CreateFile, etc). Cygwin utilise ces primitives -- et d'autres -- pour donner une interface Posix a Windows et fournit une bibliotheque standard C basee sur la couche Posix.

---

Vous parlez de "primitives d'interfacage au système"... Pouvez-vous être plus précis? Avec des exemples? J'ai un peu de mal à comprendre.

Citation:

---

Envoyé par Jean-Marc.Bourguet

MinGW c'est GCC configure pour utiliser la bibliotheque standard C fournie
avec Windows (plus quelques extensions fournies avec MinGW parce
qu'absentes du runtime fournit avec Windows). Ses compilateurs C++ et Java
sont configurer pour utiliser les bibliotheques standards fournies avec
GCC.

---

Vous dites que GCC ne contient pas de bibliothèque c... Pourquoi?

Et, j'ai du mal à comprendre comment MinGW peut faire pour utiliser la bibliothèque c++ de GCC... Je croyais que cette bibliothèque devait être conçue pour un système d'exploitation précis non?

Merci de votre aide

Alex

Citation:

---

Envoyé par Alexandreg12

Vous parlez de "primitives d'interfacage au système"... Pouvez-vous être plus précis? Avec des exemples? J'ai un peu de mal à comprendre.

---

Je vais prendre un exemple avec Linux et Posix -- je ne connais pas assez bien Windows pour pouvoir faire quelque chose de clair sans risquer une erreur ou passer plus de temps en recherche que je n'en ai envie -- et je vais un peu simplifier les choses aussi.

Les systemes d'exploitations fournissent des primitives, appelees traditionnellement appels systemes sous Unix. Un de ces appels sous Linux est clone. Cet appel systeme sert (ou peut servir) a implementer les fonctions Posix fork() et celles liees a la gestion des threads. On peut implementer la fonction standard C system() a base de fork().

Donc il est fort possible que la fonction standard C system() appelle l'interface posix fork() qui elle meme utilise l'appel systeme clone().

Citation:

---

Vous dites que GCC ne contient pas de bibliothèque c... Pourquoi?

---

Parce que c'est comme ca. GCC a ete concu dans un environnement Unix et pour un environnement Unix. Et sous Unix, les rapports entre la bibliotheque standard C et la bibliotheque d'interfacage au systeme sont etroits, tellement etroit que ca n'a guere de sens de tenter de separer les deux (et c'est de mon point de vue une faiblesse d'Unix).

Citation:

---

Et, j'ai du mal à comprendre comment MinGW peut faire pour utiliser la bibliothèque c++ de GCC... Je croyais que cette bibliothèque devait être conçue pour un système d'exploitation précis non?

---

Il y a peu de choses dependantes du systeme dans la bibliotheque standard C++, et encore moins qui ne puisse etre implemente au dessus de la bibliotheque standard C. Il doit y avoir un peu de compilation conditionnelle pour mieux profiter de certaines choses mais ca ne doit guere aller plus loin.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Il y a peu de choses dependantes du systeme dans la bibliotheque standard C++, et encore moins qui ne puisse etre implemente au dessus de la bibliotheque standard C. Il doit y avoir un peu de compilation conditionnelle pour mieux profiter de certaines choses mais ca ne doit guere aller plus loin.

---

Donc si j'ai bien compris, dans le cas de GCC, la librairie c++ utilise le même runtime que pour le c non? Donc finalement, dans ce cas précis, tout est fait en c... tout revient à utiliser la bibliothèque c...

Citation:

---

Envoyé par Alexandreg12

Donc si j'ai bien compris, dans le cas de GCC, la librairie c++ utilise le même runtime que pour le c non? Donc finalement, dans ce cas précis, tout est fait en c... tout revient à utiliser la bibliothèque c...

---

Quel sens donnes-tu a runtime? La reponse est non pour les deux sens que je connais (et que j'ai donne plus haut). Pour faire du C++, il faut un runtime plus developpe que pour faire du C (initialisation des objects a duree de vie statique, traitement des exceptions, RTTI sont les trois points qui me viennent a l'esprit) quel que soit le sens donne a runtime et GCC va fournit ce qu'il faut.

En fait je n'utilise pas les bons termes... Ce que je veut dire c'est la librairie qui permet l'accès aux fonctions du système (in/out, mémoire...)

Eh bien ce n'est pas la libc, c'est l'API système.

• Sous Windows, il est possible d'écrire un programme, en tout autre langage que C ou C++, qui n'utilise pas la C Run-Time Library (CRT). Ces autres langages peuvent avoir leur propre bibliothèque standard, qui s'appuie sur l'API système de Windows (enfin, la partie "user" de cette API).
• Sous Windows, il est également possible d'écrire un programme C qui n'utilise pas la CRT. Je l'ai déjà fait. un tel programme s'appuie directement sur l'API Win32. Par contre, le compilo de Visual délègue certaines tâches à la CRT, comme le traitement des exceptions Win32 et des vérifications de débogage, qui sont alors inaccessibles.
• MinGW utilise la CRT microsoft comme bibliothèque standard C, mais pour la bibliothèque standard C++, je crois qu'elle est liée statiquement par MinGW (car celle de Microsoft n'est pas compatible). Quant aux extensions C99 et POSIX de MinGW, je suppose qu'elles sont statiques également.
• J'ignore comment il en est sous Linux, mais il est possible que la partie "user" de l'API système et la libc soient en fait confondues.

Citation:

---

Envoyé par Médinoc

Eh bien ce n'est pas la libc, c'est l'API système.

• Sous Windows, il est possible d'écrire un programme, en tout autre langage que C ou C++, qui n'utilise pas la C Run-Time Library (CRT). Ces autres langages peuvent avoir leur propre bibliothèque standard, qui s'appuie sur l'API système de Windows (enfin, la partie "user" de cette API).
• Sous Windows, il est également possible d'écrire un programme C qui n'utilise pas la CRT. Je l'ai déjà fait. un tel programme s'appuie directement sur l'API Win32. Par contre, le compilo de Visual délègue certaines tâches à la CRT, comme le traitement des exceptions Win32 et des vérifications de débogage, qui sont alors inaccessibles.
• MinGW utilise la CRT microsoft comme bibliothèque standard C, mais pour la bibliothèque standard C++, je crois qu'elle est liée statiquement par MinGW (car celle de Microsoft n'est pas compatible). Quant aux extensions C99 et POSIX de MinGW, je suppose qu'elles sont statiques également.
• J'ignore comment il en est sous Linux, mais il est possible que la partie "user" de l'API système et la libc soient en fait confondues.

---

Merci beaucoup de vos réponses!!

Donc, ce que j'aimerais maintenant savoir, c'est ou les gens qui ont développé MinGW ont appris comment faire un linker qui peut fonctionner avec la c runtime library de microsoft.

Est-ce que tout est à 100% légal???

La partie "C" de la CRT suit les conventions standard de n'importe quelle DLL. Par contre, au niveau légalité, je ne sais pas.
Quant aux parties "avancées" de la CRT, comme le traitement d'exceptions, il me semble que MinGW fait sa propre cuisine et n'utilise pas les fonctions de traitement d'exception propres à Microsoft.