Tárgykód (object code): a fogalom definíciója és szerepe a programfuttatásban

A tárgykód alapfogalmai: Mi is az valójában?

A szoftverfejlesztés világában számos alapvető fogalommal találkozunk, amelyek elengedhetetlenek a programok működésének megértéséhez. Ezen fogalmak közül az egyik legfontosabb a tárgykód, angolul object code. De pontosan mi is ez, és miért olyan központi szereplője a programfuttatásnak? Ahhoz, hogy megértsük a tárgykód lényegét, érdemes először a programfejlesztés kezdeti lépéseit áttekintenünk.

Amikor egy programozó kódot ír, azt egy magas szintű programozási nyelven teszi, mint például C, C++, Java, Python vagy Rust. Ezek a nyelvek emberi nyelven íródott utasításokhoz hasonlítanak, és viszonylag könnyen olvashatók, érthetők és karbantarthatók. Egy számítógép azonban nem közvetlenül érti ezeket az utasításokat. A processzor (CPU) csak egy nagyon specifikus, alacsony szintű nyelvet, az úgynevezett gépi kódot képes végrehajtani. A gépi kód bináris formában, egyesekből és nullákból álló sorozatként reprezentálódik, és közvetlenül a CPU utasításkészletéhez igazodik.

Itt jön képbe a tárgykód. A tárgykód az a közvetítő forma, amely a magas szintű forráskód és a végleges gépi kód között helyezkedik el. Lényegében a forráskód egy fordítóprogram (compiler) általi feldolgozásának eredménye. A fordító feladata, hogy a programozó által írt emberi olvasható kódot lefordítsa egy olyan formába, amelyet a számítógép már közelebb állónak talál a saját nyelvéhez.

A tárgykód nem teljesen gépi kód, de már nagyon közel áll hozzá. Tartalmazza a forráskódban definiált függvények és változók gépi kódú reprezentációit, de még nem egy teljes, önállóan futtatható program. Ennek oka, hogy a modern programok ritkán állnak egyetlen forrásfájlból. Gyakran több forrásfájlból, külső könyvtárakból és egyéb komponensekből épülnek fel. A tárgykód fájlok (gyakran .o Linuxon/macOS-en vagy .obj Windows-on kiterjesztéssel) az egyes forrásfájlok lefordított, de még nem „összefűzött” verziói.

A tárgykód az a fordítóprogram által generált köztes reprezentáció, amely a magas szintű forráskódot alacsony szintű, gépi kódhoz közeli formába alakítja át, még mielőtt a végső, futtatható program létrejönne.

A tárgykód tehát egyfajta „építőelem” a szoftverfejlesztésben. Képzeljük el úgy, mint egy épület egyes előregyártott elemeit: falpaneleket, tetőszerkezeteket, stb. Ezek önmagukban még nem alkotnak egy kész házat, de már feldolgozott, felhasználható formában vannak. A tárgykód tartalmazza az adott forrásfájlhoz tartozó gépi utasításokat, adatokat, és a program más részeivel való kapcsolódáshoz szükséges információkat, mint például szimbólumtáblákat és relokációs bejegyzéseket. Ezeket az információkat később egy másik eszköz, a linker (kapcsolóprogram) használja fel a végső futtatható program előállításához.

Ez a moduláris felépítés rendkívül fontos előnyökkel jár. Lehetővé teszi, hogy a programozók különálló egységekként fejlesszék és fordítsák le a kódjukat. Ha egyetlen forrásfájlban történik változás, nem szükséges az egész projektet újrafordítani, csak az adott fájlt kell újra tárgykóddá alakítani, majd újra linkelni. Ez jelentősen felgyorsítja a fejlesztési ciklust, különösen nagy projektek esetén.

Összefoglalva, a tárgykód egy nélkülözhetetlen lépés a programozási nyelvből a végrehajtható program felé vezető úton. Ez a köztes állapot teszi lehetővé a komplex programok hatékony építését és a moduláris fejlesztési megközelítést. A következő szakaszokban részletesebben is megvizsgáljuk, hogyan keletkezik a tárgykód, milyen a felépítése, és hogyan illeszkedik a teljes programfuttatási folyamatba.

A fordítási folyamat és a tárgykód keletkezése

Ahhoz, hogy megértsük a tárgykód keletkezését, elengedhetetlenül szükséges áttekinteni a programfordítás (compilation) folyamatát. Ez a folyamat több lépcsőből áll, amelyek mindegyike kulcsfontosságú a forráskód végrehajtható programmá alakításában. A tárgykód pontosan ezen lépések egyikének eredménye.

A fordítási folyamat általában a következő főbb szakaszokra bontható:

1. Előfeldolgozás (Preprocessing): Ez az első lépés, ahol az előfeldolgozó (preprocessor) feldolgozza a forráskódot. Feladata többek között a makrók kibontása (pl. #define), fájlok beillesztése (pl. #include), és a feltételes fordítási direktívák (pl. #ifdef) kezelése. Az előfeldolgozás eredménye egy kiterjesztett forrásfájl, amely még mindig magas szintű kódot tartalmaz, de már mentes az előfeldolgozó direktíváktól.
2. Fordítás (Compilation): Ezen a lépésen a fordító (compiler) veszi át az előfeldolgozott forráskódot. A fordító feladata, hogy a magas szintű nyelven írt utasításokat alacsony szintű, assembly nyelvre (vagy közvetlenül gépi kódra) fordítsa. Ez a lépés magában foglalja a szintaktikai és szemantikai elemzést, hibák felderítését, valamint a kódoptimalizációt. Az eredmény általában egy assembly fájl (.s vagy .asm kiterjesztéssel).
3. Assemblálás (Assembly): Az assembly fájlt az assembláló (assembler) program dolgozza fel. Az assembler feladata, hogy az assembly nyelven írt utasításokat közvetlenül gépi kódra fordítsa. Ez a lépés lényegében egy egy-az-egyben megfeleltetés az assembly utasítások és a CPU által értelmezhető bináris utasítások között. Az assemblálás eredménye a tárgykód fájl (.o vagy .obj kiterjesztéssel). Ez a fájl már gépi utasításokat tartalmaz, de még nem egy teljes, futtatható program, mivel hiányoznak belőle a külső hivatkozások feloldásához szükséges információk.
4. Linkelés (Linking): Ez az utolsó lépés, ahol a linker (linker) veszi át a tárgykód fájlokat (akár több forrásfájlból származó tárgykódot is), valamint a felhasznált könyvtárak tárgykódját. A linker feladata, hogy feloldja az összes külső hivatkozást, összekapcsolja a különböző kódrészleteket, és egyetlen, önállóan futtatható programot hozzon létre (pl. .exe Windows-on, vagy futtatható bináris Linuxon/macOS-en). Erről a lépésről részletesebben is szó lesz később.

A tárgykód tehát az assemblálás fázisában keletkezik. Egyetlen forrásfájlból (vagy pontosabban, annak előfeldolgozott változatából) egyetlen tárgykód fájl jön létre. Ez a modularitás a modern szoftverfejlesztés alapja. Képzeljük el, hogy egy nagy projekt több száz forrásfájlból áll. Ha minden apró változásnál az egész projektet újra kellene fordítani az elejétől a végéig, az rendkívül időigényes lenne. A tárgykód fájlok használatával azonban csak azokat a forrásfájlokat kell újrafordítani, amelyek megváltoztak, és csak utána kell újra linkelni az összes tárgykódot.

Például, ha van egy main.c és egy utils.c fájlunk:

• main.c fordítása -> main.o tárgykód
• utils.c fordítása -> utils.o tárgykód

Ezután a main.o és a utils.o, valamint a szükséges rendszerkönyvtárak tárgykódja kerül linkelésre, hogy létrejöjjön a végleges futtatható program.

A fordítóprogramok komplex szoftverek, amelyek számos optimalizációs technikát alkalmaznak a tárgykód generálása során. Céljuk, hogy a keletkező gépi kód a lehető leggyorsabban fusson, és a lehető legkevesebb memóriát használja. Ezek az optimalizációk magukban foglalhatják a redundáns utasítások eltávolítását, a ciklusok optimalizálását, a változók regiszterekbe való hatékony kiosztását, és még sok mást. A fordító beállításai (pl. optimalizációs szintek, mint -O1, -O2, -O3 a GCC/Clang esetén) jelentősen befolyásolhatják a generált tárgykód méretét és teljesítményét.

Érdemes megjegyezni, hogy bár a tárgykód gépi utasításokat tartalmaz, mégsem teljesen független a környezetétől. Az utasítások a célarchitektúra (pl. x86, ARM) utasításkészletéhez igazodnak, és a tárgykód fájl formátuma is operációs rendszer függő lehet (pl. ELF Linuxon, PE Windows-on, Mach-O macOS-en). Ez azt jelenti, hogy egy Windows-on generált .obj fájlt általában nem lehet közvetlenül linkelni egy Linux rendszeren, még akkor sem, ha ugyanaz a forráskód volt az alapja.

Ez a lépcsőzetes folyamat biztosítja a szoftverfejlesztés rugalmasságát és hatékonyságát, lehetővé téve a komplex rendszerek moduláris felépítését és a gyors iterációt a fejlesztés során.

A tárgykód szerkezete: Egy pillantás a belső felépítésre

Ahhoz, hogy mélyebben megértsük a tárgykód szerepét és működését, elengedhetetlen, hogy bepillantsunk egy tárgykód fájl belső szerkezetébe. Bár a pontos formátum operációs rendszertől és fordítótól függően eltérhet (például ELF – Executable and Linkable Format Linuxon, PE – Portable Executable Windows-on, Mach-O macOS-en), alapvető elemei és szekciói hasonlóak.

Egy tipikus tárgykód fájl a következő főbb szekciókat tartalmazza:

• Text Szekció (.text vagy .code):

  Ez a szekció tartalmazza a lefordított gépi utasításokat, azaz a program végrehajtható kódját. Itt találhatók a forrásfájlban definiált függvények gépi kódú reprezentációi. Ez a szekció általában írásvédett a futásidőben, hogy megakadályozza a kód véletlen vagy szándékos módosítását.

• Data Szekció (.data):

  Ez a szekció inicializált globális és statikus változókat tárol. Azokat a változókat, amelyeknek a program indításakor már van kezdeti értékük, ide helyezi a fordító. Például, ha van egy int x = 10; globális változó, annak értéke itt kerül tárolásra.

• BSS Szekció (.bss – Block Started by Symbol):

  Ez a szekció az inicializálatlan globális és statikus változókat tárolja. A program betöltésekor ezek a változók általában nullára inicializálódnak. A BSS szekció célja, hogy helyet foglaljon a memóriában ezeknek a változóknak, anélkül, hogy ténylegesen tárolná az összes nulla értéket a tárgykód fájlban, ezzel csökkentve a fájl méretét. Csak a változók mérete és neve van itt megadva, nem az inicializált érték.

• Rodata Szekció (.rodata – Read-Only Data):

  Ez a szekció konstans adatokat tárol, amelyeket a program futás közben nem módosíthat. Ilyenek például a sztring literálok (pl. "Hello, World!") vagy a konstans tömbök. Ez a szekció is írásvédett a futásidőben, hasonlóan a text szekcióhoz, növelve a program stabilitását és biztonságát.

• Szimbólumtábla (Symbol Table):

  A szimbólumtábla kulcsfontosságú a linkelési folyamat szempontjából. Ez a tábla tartalmazza a forrásfájlban definiált összes szimbólum (függvények, globális változók) nevét, típusát és címét (vagy eltolását az adott szekción belül). Két fő típusú szimbólumot különböztetünk meg:

  • Exportált (globális) szimbólumok: Ezek azok a szimbólumok, amelyeket az adott tárgykód fájl definiál, és amelyeket más tárgykód fájlok vagy könyvtárak is felhasználhatnak.
  • Importált (külső) szimbólumok: Ezek azok a szimbólumok, amelyeket az adott tárgykód fájl használ, de amelyeket valahol máshol (más tárgykód fájlban vagy könyvtárban) definiáltak. A linker feladata lesz ezeknek a hivatkozásoknak a feloldása.
• Relokációs Tábla (Relocation Table):

  Mivel a tárgykód fájlok önmagukban nem futtathatóak, a bennük lévő címek (pl. függvényhívások címei, globális változók címei) relatívak az adott tárgykód fájlon belül, vagy még nincsenek teljesen feloldva. A relokációs tábla tartalmazza azokat a pozíciókat a kódban és az adatszekciókban, ahol a linkernek módosítania kell a címeket, miután a program összes komponense össze lett fűzve a memóriában. Ez a tábla mondja meg a linkernek, hogy hol vannak olyan „lyukak” a kódban, amelyeket a tényleges memóriacímekkel kell kitölteni.

• Debug Információ (Debug Information):

  Opcionálisan a tárgykód fájlok tartalmazhatnak hibakeresési információkat is. Ezek az információk segítik a hibakeresőket (debuggers) abban, hogy a gépi kódú utasításokat visszavezessék az eredeti forráskód soraihoz, lehetővé téve a változók értékeinek megtekintését és a program végrehajtásának lépésenkénti követését. Ez jelentősen megkönnyíti a hibakeresést a fejlesztési fázisban. A hibakeresési információk általában növelik a tárgykód fájl méretét, ezért a végleges, éles környezetbe szánt programokból gyakran eltávolítják őket.

Ez a strukturált felépítés teszi lehetővé, hogy a linker hatékonyan dolgozzon a különböző tárgykód fájlokkal. A szekciók segítenek a linkernek abban, hogy pontosan tudja, hol vannak a kód, az adatok és a relokálandó bejegyzések. A szimbólumtábla a „névjegykártya”, amelyen keresztül a különböző modulok egymásra találhatnak, a relokációs tábla pedig a „térkép”, amely megmondja, hol kell „címeket javítani” a végső futtatható állományban. Ez a mechanizmus a modern szoftverarchitektúrák alapja, lehetővé téve a komplex rendszerek moduláris és hatékony fejlesztését.

Szimbólumfeloldás és relokáció: A tárgykód kulcsfontosságú mechanizmusai

A tárgykód önmagában, ahogy azt korábban is említettük, nem egy futtatható program. Két kulcsfontosságú folyamat szükséges ahhoz, hogy a tárgykód fájlokból végleges, futtatható bináris állomány jöjjön létre: a szimbólumfeloldás és a relokáció. Mindkét feladat a linker, azaz a kapcsolóprogram felelőssége.

Szimbólumfeloldás (Symbol Resolution)

A modern programok szinte mindig több forrásfájlból, valamint külső könyvtárakból épülnek fel. Egyik forrásfájlban definiálhatunk egy függvényt, például calculate_sum(), amelyet aztán egy másik forrásfájlban hívunk meg. Amikor a fordító lefordítja az első fájlt tárgykóddá, tudja, hogy a calculate_sum() létezik és hol található az adott tárgykód fájlon belül. Amikor azonban a második fájlt fordítja, és ott hivatkozást talál a calculate_sum() függvényre, akkor még nem tudja pontosan, hol fog ez a függvény a végleges memóriában elhelyezkedni. Ezt a hivatkozást egy külső szimbólumként jelöli meg.

A szimbólumfeloldás az a folyamat, amely során a linker az összes tárgykód fájlban (beleértve a könyvtárakat is) megkeresi az összes külső szimbólum definícióját, és összekapcsolja a hivatkozásokat a definíciókkal. A tárgykód fájlok szimbólumtáblája kulcsfontosságú ebben a folyamatban. A linker végignézi az egyes tárgykód fájlok szimbólumtábláit, azonosítja az exportált (definiált) és az importált (hivatkozott) szimbólumokat. Amikor egy importált szimbólumhoz megtalálja a megfelelő exportált szimbólumot, akkor „feloldja” a hivatkozást.

Például, ha file1.o definiálja a foo() függvényt, és file2.o meghívja a foo() függvényt, akkor:

• file1.o szimbólumtáblájában lesz egy bejegyzés foo-ról, mint exportált szimbólumról.
• file2.o szimbólumtáblájában lesz egy bejegyzés foo-ról, mint importált szimbólumról.

A linker a file2.o-ban található hivatkozást a file1.o-ban található definícióhoz rendeli hozzá. Ha a linker nem találja meg egy importált szimbólum definícióját az összes rendelkezésre álló tárgykód fájlban és könyvtárban, akkor linkelési hibát (link-time error) fog jelezni, és nem tudja elkészíteni a futtatható programot. Ez gyakran előfordul, ha hiányzik egy könyvtár, vagy rossz a függvény neve.

Relokáció (Relocation)

A szimbólumfeloldás önmagában nem elegendő. A tárgykód fájlokban lévő gépi utasítások gyakran tartalmaznak relatív címeket vagy helykitöltőket, mert a fordító nem tudja előre, hogy a program mely memóriacímre lesz betöltve, vagy hogy a különböző kódrészletek hol fognak egymáshoz képest elhelyezkedni a végső futtatható állományban. Itt jön képbe a relokáció.

A relokáció az a folyamat, amely során a linker (vagy bizonyos esetekben a futásidejű betöltő) módosítja a tárgykód fájlokban lévő gépi utasításokat és adatokat, hogy azok a program végső memóriabeli elhelyezkedéséhez igazodjanak. A tárgykód fájlokban található relokációs tábla tartalmazza azokat a pozíciókat és típusokat, ahol a linkernek „javítania” kell a címeket. Például, ha egy függvény meghív egy másikat, a hívás utasításában lévő címnek a meghívott függvény tényleges memóriacímére kell mutatnia.

A relokációs bejegyzések általában a következő információkat tartalmazzák:

• Offset: A tárgykód szekción belüli pozíció, ahol a címet módosítani kell.
• Típus: A relokáció típusa, például relatív címre vonatkozó eltolás, abszolút cím, vagy egy szimbólumhoz való hivatkozás.
• Szimbólum: A szimbólum, amelyhez a relokáció kapcsolódik (pl. egy függvény vagy változó neve).

A linker a szimbólumfeloldás során meghatározza az összes szimbólum végső címét a futtatható programban. Ezután a relokációs tábla alapján végigmegy a tárgykód szekciókon, és mindenhol, ahol egy relokációs bejegyzés található, frissíti az ott lévő címet a megfelelő, végleges memóriacímmel. Ez biztosítja, hogy minden hivatkozás a programon belül és a külső könyvtárak felé is a helyes memóriacímre mutasson.

Példa a relokációra:

Tegyük fel, hogy van egy tárgykód fájlunk, amelyben egy call utasítás meghívja a my_function nevű függvényt. Amikor a fordító létrehozza ezt a tárgykódot, nem tudja, hol lesz a my_function a végső programban. Ezért a call utasítás operandusában egy helykitöltő vagy relatív cím szerepel. A relokációs táblában lesz egy bejegyzés, amely jelzi, hogy ezen a pozíción a my_function címét kell majd elhelyezni.

Amikor a linker összekapcsolja a programot, és tudja, hogy a my_function a végső program memóriájában a 0x401234 címen fog elhelyezkedni, akkor a call utasítás operandusát frissíti erre a címre.

Ez a két mechanizmus – a szimbólumfeloldás és a relokáció – együttesen biztosítja, hogy a különállóan lefordított tárgykód modulok zökkenőmentesen együttműködhessenek, és egy koherens, futtatható programmá álljanak össze. Ezek nélkül a komplex programok fejlesztése elképzelhetetlen lenne.

A tárgykód és a linkelés: Statikus és dinamikus kapcsolás

A tárgykód és a linker kapcsolata alapvető a programok futtatható formába öntésében. A linkelés (linking) az a folyamat, amely során a linker program összegyűjti az összes szükséges tárgykód fájlt – a saját forráskódunkból generáltakat, valamint a felhasznált könyvtárakból származókat – és egyetlen, önállóan futtatható bináris állománnyá fűzi össze. Két fő típusa van a linkelésnek: a statikus linkelés és a dinamikus linkelés.

Statikus linkelés (Static Linking)

A statikus linkelés során a linker az összes szükséges kódot és adatot, beleértve a felhasznált könyvtárakat is, közvetlenül beágyazza a végső futtatható programba. Amikor egy program statikusan linkelődik egy könyvtárhoz, a könyvtár azon részei, amelyeket a program használ, lemásolódnak a futtatható állományba. Ennek eredményeként a program egyetlen, nagy méretű fájl lesz, amely tartalmaz minden szükséges komponenst a futáshoz.

Előnyei:

• Önálló futtathatóság: A statikusan linkelt programok nem függenek külső könyvtárak meglététől a célrendszeren. Ez rendkívül egyszerűvé teszi a terjesztést és a telepítést, mivel minden szükséges benne van a futtatható fájlban.
• Teljesítmény: Mivel minden kód közvetlenül a futtatható fájlban van, nincs szükség futásidejű címfeloldásra vagy könyvtárak betöltésére, ami elméletileg gyorsabb indítást és futást eredményezhet, bár a modern rendszereken ez a különbség gyakran elhanyagolható.
• Verziókonfliktusok elkerülése: Nincs „DLL Hell” (Windows) vagy hasonló probléma, mivel a program a saját, beágyazott könyvtárverzióját használja.

Hátrányai:

• Nagyobb fájlméret: Mivel a könyvtárak kódját minden programba belemásolja, a statikusan linkelt programok sokkal nagyobbak lehetnek, mint dinamikusan linkelt társaik. Ha sok program használja ugyanazt a könyvtárat, az feleslegesen sok lemezterületet foglal.
• Memóriahasználat: Minden statikusan linkelt program külön memóriaterületet foglal el a saját beágyazott könyvtáraival, még akkor is, ha több program használja ugyanazt a könyvtárat.
• Nehézkes frissítés: Ha egy statikusan linkelt könyvtárban biztonsági javítás vagy hibajavítás történik, minden olyan programot újra kell fordítani és újra terjeszteni, amely ezt a könyvtárat használja.
• Licencelési problémák: Egyes nyílt forráskódú könyvtárak licencelési feltételei megtilthatják a statikus linkelést zárt forráskódú programokkal.

Dinamikus linkelés (Dynamic Linking)

A dinamikus linkelés során a linker nem ágyazza be a könyvtárak kódját a futtatható programba. Ehelyett a futtatható program csak hivatkozásokat tartalmaz a szükséges könyvtárakra. Ezeket a könyvtárakat (pl. .dll Windows-on, .so Linuxon, .dylib macOS-en) csak a program betöltésekor vagy futásidejűleg tölti be a rendszer. A futtatható fájl tartalmaz egy listát azokról a könyvtárakról és függvényekről, amelyekre szüksége van, és a dinamikus betöltő (dynamic loader) felelős ezek megtalálásáért és betöltéséért a memóriába.

Előnyei:

• Kisebb fájlméret: A futtatható programok sokkal kisebbek, mivel nem tartalmazzák a könyvtárak kódját.
• Memóriamegtakarítás: Ha több program használja ugyanazt a dinamikus könyvtárat, a könyvtár kódja csak egyszer töltődik be a memóriába, és megosztható a programok között. Ez jelentős memóriamegtakarítást eredményezhet.
• Egyszerűbb frissítés: Ha egy dinamikus könyvtár frissül, az összes azt használó program azonnal profitál a javításokból, anélkül, hogy azokat újra kellene fordítani vagy telepíteni.
• Modularitás: Lehetővé teszi a programok moduláris felépítését, ahol a különböző komponensek függetlenül fejleszthetők és telepíthetők.

Hátrányai:

• Függőségek: A program futtatásához a szükséges dinamikus könyvtáraknak jelen kell lenniük a célrendszeren, és megfelelő verziójúaknak kell lenniük. Ez vezethet az úgynevezett „DLL Hell” problémákhoz, amikor a különböző programok eltérő verziójú könyvtárakat igényelnek, és ezek konfliktusba kerülnek.
• Teljesítmény: A dinamikus könyvtárak betöltése és a futásidejű címfeloldás némi többletköltséggel járhat a program indításakor és futása során.
• Biztonsági kockázatok: Rosszindulatú kód becsempészhető dinamikus könyvtárakba (DLL hijacking), ami biztonsági sebezhetőségeket okozhat.

A tárgykód szerepe a linkelésben

Mind a statikus, mind a dinamikus linkelés alapja a tárgykód. A fordító mindig tárgykód fájlokat generál az egyes forrásfájlokból. A linker ezután dönti el, hogy ezeket a tárgykód fájlokat (és a könyvtárak tárgykódját) hogyan fűzi össze a végső programba. Statikus linkelés esetén a linker közvetlenül beolvassa a könyvtárak tárgykódját, és beépíti a végső binárisba. Dinamikus linkelés esetén a linker „helyőrzőket” helyez el a futtatható fájlban, amelyek jelzik a dinamikus betöltőnek, hogy futásidőben mely könyvtárakat és mely függvényeket kell betölteni és összekapcsolni.

A tárgykód tehát a linkelési folyamat bemenete. Anélkül, hogy a forráskód tárgykóddá alakulna, a linker nem tudná elvégezni a feladatát, és nem jöhetne létre futtatható program. A linkelés típusa alapvető döntés a szoftverfejlesztésben, és jelentős hatással van a program méretére, terjeszthetőségére, frissíthetőségére és futásidejű viselkedésére.

A futtatható állomány létrejötte: A betöltő szerepe

Miután a tárgykód fájlok sikeresen átmentek a linkelési folyamaton – legyen szó statikus vagy dinamikus linkelésről –, létrejön a végső futtatható állomány (executable). Ez az a fájl, amelyet a felhasználó elindíthat, és amely közvetlenül képes kommunikálni