Quand j'apprendais .net, je l'ai vu comme une plate-forme qui dirige mes programmes .NET qui a sa propre pile et son tas.
Mais maintenant après avoir appris plus sur les choses, je vois une application .NET comme tout simplement comme toute autre application native C / C ++. Il est dans le format de fichier exécutable portable (PE) avec le nouveau répertoire de données et la section .Text est rempli de code MSL au lieu d'un code de machine. La seule différence est que peu de DLL (qui sont considérées comme une plate-forme .NET) (comme toute autre dépendance DLL) sont chargées.
Je suppose qu'au point de saisie, il y a un code de machine qui appelle la DLL chargé (plate-forme .NET) et les fonctions de la DLL lisez le MSIL à partir de la section .Text (segment à être plus correct) et générez du code de machine équivalent. Et mettez-le dans une sorte de tampon (je ne sais pas quelle zone serait-ce. Je ne peux pas être .Text et .data comme ils sont réadonnants. Seront-ils en train de pile ou de tas?). Ensuite, faites le point EIP sur ce tampon des instructions. Les dernières instructions rappellent à nouveau dans des DLL pour répéter le processus de repos de MSIL.
AS de J'aime cette vue réaliste. Je ne sais pas jusqu'où je suis vrai. Je devine juste ces choses. S'il vous plaît corrigez-moi et dites-moi plus à ce sujet. Jusqu'où sera-t-il similaire à cette vue? Où puis-je en savoir plus sur la plate-forme .NET à partir de ce point de vue? Heap géré & Stack géré Ils ne sont que quelques portions du tas et la pile de processus. C'est juste que peu de fonctions (appelées GC) garderont une trace des allocations de mémoire et des translocations de ces portions de mémoire.
7 Réponses :
Votre description manque une chose: la plupart des codes dans un assembly .NET sont Just-in-Time (JIT) compilé , ce qui signifie que le MSL n'est pas converti en code de machine avant le moment Avant que la méthode soit appelée pour la première fois, à quel point il est mis en cache pour l'avenir. Cela accélère considérablement le temps de démarrage, au prix d'un ralentissement mineur, la première fois que chaque méthode est appelée. (Je omettons les détails comme le fait que le compilateur JIT peut ré-optimiser la fonction après son appel fait quelques fois.)
Le code JIT-compilé vit sur le tas, du point de vue du système d'exploitation. Le compilateur JIT marquera le code comme exécutable et fera tout ce qui est nécessaire pour le rendre correctement exécuté.
Ce n'est pas précis à 100%, mais je dirais que vous avez un aperçu décent de certaines portions du cadre en baisse.
Si vous souhaitez en savoir plus, je vous suggère de jeter un coup d'œil à l'air d'abord au . FAQ NET Framework et lorsque vous avez terminé avec celui-ci, lisez le . NET 1.1 à l'intérieur du cadre .NET série d'articles. Ces articles ne couvriront pas de nombreuses avancées survenues au cours des 4 dernières versions, mais elles donneront une bonne base solide de ce que le framework .NET est tout.
Dernièrement, j'ai lisée Pro C # 2008 et le. NET 3.5 Platform (il y a maintenant un VS2010 /. NET 4.0 version, aussi), et il fait un excellent travail expliquant comment le Bytecode .Net fonctionne sur le back-end et comment vous pouvez en apprendre de ce qui est vraiment appelé en utilisant le réflecteur, etc. C'est dense et long (et parfois plus d'informations que je ne voulais), mais c'est une bonne lecture informative.
CLR via C # décrit certains internes. Choses nettes, y compris le processus de charge PE et l'hébergement de CLR dans votre propre processus.
Quel chapitre de ce livre explique ce que vous avez dit?
Vous avez manqué un point de point très important - CIL CIL (anciennement MSIL) est un code de sécurité. Vous ne pouvez pas faire de pointeur arbitraire VOODOO, tapez la coulée ou des mauvaises choses similaires (à l'exception des régions de code non sécurisées). C'est probablement la différence la plus importante pour d'autres langues telles que C (++), Pascal, etc. Ces garanties de sécurité sont profondément construits dans la langue, le système de type et la conception d'exécution.
+1, mais j'ajouterais que j'ajouterais «Impossible d'accéder au tableau en dehors de ses limites», ce qui empêche totalement des scénarios de dépassement des tampons.
Eh bien, vous pouvez faire certains vaudou. Ou au moins certains hocus-pocus. Certaines langues rendent cela clairement, par exemple en vous faisant déclarer des régions dangereux . Il y a aussi beaucoup de constructions de msil non vérifiables (mais valides).
Ouais j'allais mentionner que c'est une grande différence de Java, qui n'a rien comme le mot-clé dangereux.
Vous trouverez peut-être cet article MSDN intéressant: http://msdn.microsoft .COM / EN-US / MAGAZINE / CC163791.ASPX
ainsi que ces livres: http://www.amazon.com/expert-net- 2-0-IL-assembleur / DP / 1590596463 / REF = PD_BBS_SR_1 / 104-0844985-7433557? IE = UTF8 & S = Books & QID = 1175791950 & SR = 8-1
pour CLR Cochez: CLR via C # .
C'est vraiment un excellent livre surtout si vous êtes intéressé par "niveau bas" .NET / CLR.
pour JVM Check: Machine virtuelle Java
+1 pour CLR via C #. J'ai trouvé la section sur la collecte des ordures particulièrement intéressante, car le CLR GC fait beaucoup plus que de suivre une allocation. Le CLR et GC coopèrent de sorte que votre code d'exécution puisse réellement être détourné, demandez à vos références sur les nouveaux emplacements de mémoire, puis commencez à courir à nouveau comme si rien ne s'est passé.
Je vous recommanderais de mettre Java dans une question distincte pour obtenir de meilleures réponses. En outre, avec Java, la réponse n'est pas la même sur toutes les plateformes (sauf à un niveau élevé - le code circule dans une machine virtuelle). Êtes-vous seulement intéressé par la façon dont cela se fait sous Windows?
Je suis d'accord avec @yishai; Java a de nombreuses différences significatives de .net qui sont susceptibles de bouleverser la question. Enregistrez-le pour une question séparée.