Quelle forme est DLL et ce qui la rend dépendante processeur

Question

Je sais que DLL contient une ou plusieurs fonctions exportées qui sont compilés, liés et stockés séparément ..

Ma question est de ne pas sur la façon de créer .. mais il est tout sous quelle forme il est stocké .. Est-ce que ça va être sous la forme de 0 de & 1 de .. ou dans les commandes de montage ADD, MUL, DIV, MOV, APPEL, RETOUR etc .. Aussi ce qui fait qu'il est dépendant processeur .. (comme x86, x87, jeu d'instructions IBM 700) ..

Quelqu'un peut-il s'il vous plaît expliquer brièvement peu ..!

Answer 1

Tout d'abord, tout dans un ordinateur est sous forme de « 0 et 1 ». Le fait que l'ordinateur peut afficher certains d'entre eux sous forme de texte, des images, des sons, des modèles 3D, etc. est juste une question de la façon dont vous les interprétez. Mais là-bas, au métal, il est tout simplement « 0 et 1 » (également connu sous le nom bits). Notez bien qu'ils sont toujours regroupés en groupes de 8, et ceux-ci sont appelés « octets ». Il est vraiment un souci d'efficacité, car chaque bit fonctionnant avec serait individuellement trop fastidieux. En fait, les ordinateurs d'aujourd'hui ne fonctionnent même plus sur un seul octets (ou plutôt - ils le font très rarement). La plupart du temps vous opérez avec 4 ou 8 octets à la fois, selon que vous avez un processeur 32 bits ou 64 bits (c'est en termes simples, il est en fait un peu plus compliqué que ça).

En ce qui concerne un fichier .DLL - comme un fichier .EXE, il contient des octets qui décrivent des instructions qu'un processeur peut exécuter. La CPU prend ces octets directement à partir du .DLL / .EXE et les exécute sans aucune autre modification. Voilà pourquoi ces fichiers sont spécifiques CPU. Dans différentes architectures de processeurs la même combinaison d'octets signifie des choses différentes, donc un .DLL / .EXE fonctionnera correctement que sur le CPU pour lequel il a été conçu. Sur d'autres unités centrales ces octets signifieront d'autres instructions, et lorsqu'il est exécuté, le programme sera très probablement faire un peu une absurdité totale et planter immédiatement.

L'ensemble des commandes que vous avez mentionné méritent aussi une explication. « Assembleur » est pas une langue qu'une CPU peut comprendre. Il est un langage humain peut comprendre. Il a été créé parce que l'écriture dans le code de la machine directement (les octets que la CPU comprend en fait) est très difficile. Ce que vous obtenez est charabia absolue à l'écran (essayez d'ouvrir un certain fichier .EXE dans le Bloc-notes!) Mais tout doit être réglé pour que cela fonctionne avec précision.

langage assembleur est fondamentalement la même chose, à l'exception de ces instructions sont écrites dans le texte que les humains peuvent lire. Pour chaque code machine qu'une CPU peut comprendre, il y a instruction h avec un nom convivial humain. Un compilateur d'assemblage lit simplement les instructions et les remplace par les octets qui représentent les instructions réelles pour la CPU à exécuter. Il est 1: 1 opération. Chaque commande en langage assembleur correspond à une seule instruction de la machine (encore une fois, en termes simples).

Donc, vous voyez, il n'y a même pas un seul langage assembleur. Chaque architecture CPU a son propre langage assembleur, car ils ont chacun des instructions différentes.

Notez bien que tout cela s'applique aux fichiers .DLL / .EXE natifs. fichiers .NET sont différents - ils ne contiennent pas de code de la machine, mais plutôt des instructions pour un résumé, CPU inexistant. Il est comme bytecode Java. Lorsqu'un .DLL .NET / .EXE est exécuté, le moteur d'exécution .NET, il se traduit par des instructions abstraites aux instructions que le processeur spécifique peut comprendre. Ils utilisent beaucoup de trucs pour faire de ce très rapide, de sorte que ces fichiers fonctionnent presque aussi vite que simples .DLL / fichiers .EXE.

Est-ce que clarifier les choses? :)

Answer 2

DLLs autochtones (pas d'ensembles .NET) contiennent habituellement du code machine qui ne peut être exécuté sur une certaine plate-forme. Le code de la machine est une séquence d'octets que le processeur traite comme instructions (ADD, MOV, etc.).

Answer 3

Dans Windows, dll sont stockés dans le format PE qui est essentiellement une collection de sections qui contient les informations sur la façon de la carte dans la mémoire. certaines sections contient le code du programme (qui est du processeur dépend bien sûr), d'autres contiennent des données du programme, d'autres fonctions exportées et importées et ainsi de suite.

Le code managé est compilé dans une certaine langue intermédiaire qui est JITed par le temps d'exécution comme il est exécuté. Par conséquent, votre dll ne contient aucun code dépendant du processeur et vous serez en mesure d'exécuter votre programme sur une plate-forme avec l'exécution pertinente.

Answer 4

dépend de votre DLL. En général, une DLL contient du code exécutable en tant que fichier EXE. les DLL de code sont processeur dépendant puisque le code ne peut être exécuté sur une plate-forme spécifique. le code est stocké en utilisant le même "format" en tant que fichier EXE (code machine binaire).

cependant, une DLL peut contenir parfois seulement des données: ils sont alors appelés « DLL de ressources » et ne sont pas dépendants de traitement du tout. ils agissent comme un conteneur pour les fichiers de données utilisés par les applications.

A noter que de nombreux hybrides sont DLLs: ils contiennent à la fois le code et les ressources. par exemple, la plupart des DLL qui comprend la partie utilisateur du système d'exploitation Windows sont hybrides: vous pouvez les ouvrir à l'aide de Visual Studio ou une ressource Explorer pour voir les ressources (les segments de données) qu'ils contiennent, ou les ouvrir avec Dependency Walker ou dumpbin à voir les fonctions (les segments de code) qu'ils contiennent.

(bien sûr cette réponse est vraiment spécifique de Windows, je ne sais pas pour .so fichiers qui sont l'équivalent linux d'une DLL)

Answer 5

Les deux DLL et un EXE contiennent du code exécutable.

Dans le cas d'une DLL, il ne possède pas les pièces nécessaires pour être directement exécutable. Il doit être appelé à partir d'un autre morceau de code exécutable. Une DLL peut appeler un autre, mais tout doit finalement être appelé à partir et EXE.

Ainsi, les règles sur ce qui est compatible avec ce processeur qui appliquent à EXEs appliquent également aux DLL.