Je me suis juste posé la question moi-même et je me suis fait mal au cerveau pendant quelques heures. Je n'ai toujours rien trouvé qui fasse vraiment un point. Quiconque écrit quelque chose sur un sujet ne peut pas réellement «enseigner». Si vous voulez enseigner à quelqu'un, prenez la langue la plus élémentaire qu'une personne comprend, afin qu'elle n'ait pas besoin de se soucier des autres sujets lors du traitement d'un sujet. Je suis donc parvenu à une conclusion pour moi-même qui semble bien s'intégrer dans tout ce chaos.
Dans le langage de programmation C, chaque programme commence par la main()
fonction. D'autres langages peuvent définir d'autres fonctions où le programme démarre. Mais un processeur ne connaît pas le main()
. Un processeur ne connaît que les commandes prédéfinies, représentées par des combinaisons de 0
et 1
.
Dans la programmation par microprocesseur, n'ayant pas de système d'exploitation sous-jacent (Microsoft Windows, Linux, MacOS, ..), vous devez indiquer explicitement au processeur par où commencer en définissant le ProgramCounter
(PC) qui itère et saute (boucles, appels de fonction) dans le commandes connues du processeur. Vous devez savoir quelle est la taille de la RAM, vous devez définir la position de la pile de programmes (variables locales), ainsi que la position du tas (variables dynamiques) et l'emplacement des variables globales (je suppose que cela s'appelait SSA ?) dans la RAM. Un seul processeur ne peut exécuter qu'un seul programme à la fois.
C'est là que le système d'exploitation entre en jeu. Le système d'exploitation lui-même est un programme qui s'exécute sur le processeur. Un programme qui permet l'exécution de code personnalisé. Exécute plusieurs programmes à la fois en basculant entre les codes d'exécution des programmes (qui sont chargés dans la RAM). Mais le système d'exploitation EST UN PROGRAMME, chaque programme est écrit différemment. Le simple fait de mettre le code de votre programme personnalisé dans la RAM ne le fera pas fonctionner, le système d'exploitation ne le sait pas. Vous devez appeler des fonctions sur le système d'exploitation qui enregistre votre programme, indiquer au système d'exploitation la quantité de mémoire dont le programme a besoin, où se trouve le point d'entrée dans le programme (lemain()
fonction en cas de C). Et c'est ce que je suppose qui se trouve dans la bibliothèque d'exécution, et explique pourquoi vous avez besoin d'une bibliothèque spéciale pour chaque système d'exploitation, car ce ne sont que des programmes eux-mêmes et ont des fonctions différentes pour faire ces choses.
Cela explique également pourquoi il n'est PAS lié dynamiquement au moment de l'exécution car .dll
sont les fichiers, même si cela s'appelle une bibliothèque RUNTIME. La bibliothèque d'exécution doit être liée de manière statique, car elle est nécessaire au démarrage de votre programme. La bibliothèque d'exécution injecte / connecte votre programme personnalisé dans / à un autre programme (le système d'exploitation) à RUNTIME. Cela provoque vraiment un cerveau f ...
Conclusion: RUNTIME Library est un échec de dénomination. Il n'y a peut-être pas eu de.dll
(liaison au moment de l'exécution) dans les premiers temps et le problème de la compréhension de la différence n'existait tout simplement pas. Mais même si c'est vrai, le nom est mal choisi.
De meilleurs noms pour la bibliothèque d'exécution pourraient être: StartupLibrary / OSEntryLibrary / SystemConnectLibrary / OSConnectLibrary
J'espère que j'ai bien compris, pour correction / expansion. à votre santé.