Właśnie o to zapytałem i przez kilka godzin raniłem mózg. Nadal nie znalazłem niczego, co naprawdę ma rację. Każdy, kto coś pisze na jakiś temat, nie jest w stanie tak naprawdę „uczyć”. Jeśli chcesz kogoś uczyć, weź najbardziej podstawowy język, który dana osoba rozumie, aby nie musiał przejmować się innymi tematami podczas prowadzenia tematu. Więc doszedłem do wniosku, który wydaje się dobrze pasować do całego tego chaosu.
W języku programowania C każdy program zaczyna się od funkcji main (). Inne języki mogą definiować inne funkcje, w których program jest uruchamiany. Ale procesor nie zna main (). Procesor zna tylko predefiniowane polecenia, reprezentowane przez kombinacje „0” i „1”.
W programowaniu mikroprocesorowym, który nie ma podstawowego systemu operacyjnego (Microsoft Windows, Linux, MacOS, ...), musisz wyraźnie powiedzieć procesorowi, od czego zacząć, ustawiając ProgrammCounter (PC), który iteruje i skacze (pętle, wywołania funkcji) w polecenia znane procesorowi. Musisz wiedzieć, jak duża jest pamięć RAM, musisz ustawić pozycję stosu programu (zmienne lokalne), a także pozycję sterty (zmienne dynamiczne) i lokalizację zmiennych globalnych (chyba nazywało się to SSA ?) w pamięci RAM. Pojedynczy procesor może wykonywać tylko jeden program na raz.
W tym miejscu pojawia się system operacyjny. Sam system operacyjny jest programem działającym na procesorze. Program umożliwiający wykonanie kodu niestandardowego. Uruchamia wiele programów jednocześnie, przełączając się między kodami wykonywania programów (które są ładowane do pamięci RAM). Ale system operacyjny JEST PROGRAMEM, każdy program jest napisany inaczej. Samo umieszczenie kodu programu niestandardowego w pamięci RAM go nie uruchomi, system operacyjny o tym nie wie. Musisz wywołać funkcje w systemie operacyjnym, który rejestruje twój program, powiedzieć systemowi operacyjnemu, ile pamięci potrzebuje program, gdzie znajduje się punkt wejścia do programu (funkcja main () w przypadku C). Wydaje mi się, że to właśnie znajduje się w RuntimeLibrary i wyjaśnia, dlaczego potrzebujesz specjalnej biblioteki dla każdego systemu operacyjnego,
To wyjaśnia również, dlaczego NIE jest on dynamicznie łączony w czasie wykonywania, tak jak pliki .dll, nawet jeśli nosi nazwę RUNTIMELibrary. Biblioteka RuntimeLibrary musi być połączona statycznie, ponieważ jest potrzebna podczas uruchamiania programu. RuntimeLibrary wstrzykuje / łączy Twój program niestandardowy do / z innym programem (systemem operacyjnym) w RUNTIME. To naprawdę powoduje, że mózg ...
Wniosek: RUNTIMELibrary nie powiodła się w nazewnictwie. Być może we wczesnych czasach nie było .dll (linkowanie w czasie wykonywania), a problem zrozumienia różnicy po prostu nie istniał. Ale nawet jeśli to prawda, nazwa jest źle wybrana.
Lepszymi nazwami dla RuntimeLibrary mogłyby być: StartupLibrary / OSEntryLibrary / SystemConnectLibrary / OSConnectLibrary
Mam nadzieję, że dobrze zrozumiałem, czekam na poprawki / okrzyki rozszerzeń.