Hogyan programozhatsz gépi kódban?

"Nem egészen. Én a plain bináris, futtatható állományok működését írtam le. Ezek közé tartozik a .com is.

...

"de a mai Windowsok és különösen más operációs rendszerek a .COM-ot már nem támogatják."

...

Ennek semmi jelentősége. Ha emulálja a PC-t a gépén, akkor olyan mindegy, hogy a host opre mit támogat és mit nem.

...

Én azért tettem erre javaslatot, mert ezt látom a legcélravezetőbbnek, hogy megismerje a kérdező azt, amit szeretne. Legalábbis véleményem szerint."

Már bocs, de tudod mi a lényegi különbség az EXE és a COM futtatható bináris között? Esetleg láttad már egy ELF bináris szerkezetét (hogy ne csak DOS-Windows oprendszereket nézzünk)?

A kulcsa az eltérésnek a relokálhatóságban van. Nagyon-nagyon leegyszerűsítve, az operációs rendszer a fájl betöltésekor a programban lévő címeket átalakítja annak megfelelően, hogy pontosan hova került betöltésre a program, ehhez van a fájlban egy táblázat, amely megmutatja, hogy a programban hol kell átállítani a címeket. A COM-ban ilyen nincs, de gyakorlatilag az összes többi formátumban van ilyen. Ezért sokkal nehezebb kézzel ilyeneket írni akár egy HEX editorral (egyszer megpróbáltam, tényleg nehéz).

Azzal a fogalommal még nem találkoztam amit használsz, hogy "plain bináris". És nem véletlen pont a relokálhatóság miatt a bináris executable formátumok mindig oprendszer függőek. És a legtöbb operációs rendszeren is vannak több féle fájl típusok (pl. régen a linuxban volt az a.out, most az ELF lett a "szabványos".

Itt a relokálást maga az operációs rendszer végzi el, ésnem a programozónak kell ezzel foglalkoznia (uagynígy a lapozással és a címfordítással sem, ld. korábbi válaszom). De lassan igencsak off leszünk a kérdést illetően.

"Azzal a fogalommal még nem találkoztam amit használsz, hogy "plain bináris". És nem véletlen pont a relokálhatóság miatt a bináris executable formátumok mindig oprendszer függőek. "

Hát, pedig ez baj! Roppant nagy baj, mert azt jelenti, nem vagy tökéletes. Tudod, a plain bináris azt jelenti, hogy nincs a file szerkesztve, nem tartalmaz stub-ot (jaj, félek ezt sem tudod mit jelent, na mindegy, majd kiguglizod ezt az infó töredéket is mint feljebb a többit). Szóval, plain bináris, hát banyek, az ilyen file-ok futnak jellemzően beágyazott rendszerek és régi 8 bites gépek processzorain is.

" És nem véletlen pont a relokálhatóság miatt a bináris executable formátumok mindig oprendszer függőek."

Vagy nem! Ezt az ordenáré baromságot amúgy kitől hallottad, melyik hozzád hasonló, önjelölt térdzokni weblapjáról kotortad össze?

"A kulcsa az eltérésnek a relokálhatóságban van."

Nem nyert! Itt is tévedni méltóztatsz!

Az eltérés kulcsa ugyanis a méret, na meg az a tény, hogy ezek a file-ok (mz .exe, pe .exe, .elf, .coff, stb) elkivánnak a futásukhoz sok memóriát és sok szegmenst. Tudod burgonya, bár még nem hallottál erről, de létezik ám olyan a PC-kben, hogy SS, DS, CS, ES regiszter.

Ezek a Stack, az adat a kód és az extra szegmensek helyét jelölik ki. Mert ezeket a szegmenseket mind-mind igénylik ám azok a programok, amelyekről úgy vakolsz itt, mintha tényleg lenne közöd hozzájuk, pedig nincs.

"Már bocs, de tudod mi a lényegi különbség az EXE és a COM futtatható bináris között?"

Én tudom koma, fentebb írtam is ezekről, csak az a nagy baj, hogy te nem.

Kedves kötekedő 1. vegyél vissza a stílusból.

2.: "The MZ DOS executable file is newer than the COM executable format and differs from it. The DOS executable header contains relocation information, which allows multiple segments to be loaded at arbitrary memory addresses, and it supports executables larger than 64k; however, the format still requires relatively low memory limits. " (MZ DOS az EXE eredeti fájl formátumának egy másik elnevezése).

A többi személyeskedésre már nem válaszolok.

Ténleg nem kellett volna megerősíteni az általam imént elmondottakat, de ha már megtetted, köszönöm.

"The DOS executable header contains relocation information, which allows

>>multiple segments<<

to be loaded at arbitrary memory addresses, and it supports executables >>larger than 64k<<"

Igen, éppen ezt mondtam én is, a sok szegmens és memóriaigényt.

Az meg talán csak számodra bír ujdonsággal, hogy egy védett módú, multitaszkos operációs rendszer alapban igényli a relokálhatóságot (akár linux, akár windows, akár qnx, BeOS, OS/2 vagy más), hiszen mégis, hogy nézne ki az egész enélkül? Akár 20-40 program is fut egy mai gépen.

Talán minden program azonos címre töltődne be, egymást felülírva, vagy mégis, hogy képzeled?

Na, megint tanultál valami érdekeset. Örülök, hogy segíthettem.

14. (19:09) válasz:

"Nem nyert! Itt is tévedni méltóztatsz!

Az eltérés kulcsa ugyanis a méret, na meg az a tény, hogy ezek a file-ok (mz .exe, pe .exe, .elf, .coff, stb) elkivánnak a futásukhoz sok memóriát és sok szegmenst. Tudod burgonya, bár még nem hallottál erről, de létezik ám olyan a PC-kben, hogy SS, DS, CS, ES regiszter."

Ugyan nem én lettem megszólítva. De a stílusod elég brutálisra sikerült. És nagyon látszik, hogy fogalmad sincs az egészről. A kolléga egy nagyon jó anyagot linkelt erről, és amint láthattad a hozzá szólásában, nem csak linkelni tudta, hanem olvasta is. De amint látom te ezeket nem olvastad.

Eleve négyféle üzemmódban járatható egy 64bites intel proci (és most arról beszéljünk, az amd is hasonló ehhez).

Protected mód, Valós címmód, Rendszer menedzsment mód, komptibilitási mód (32 bites, és 8086), 64 bit lineáris mód. Ez utbbi esetén pl. nem használhatóak a szegmens regiszterek "Specifically, the processor treats the segment base of CS, DS, ES, and SS as zero in 64-bit mode (this makes a linear address equal an effective address). Segmented and real address modes are not available in 64-

bit mode."

Egyébként pont ezt írja le a kolléga által hivatkozott dokumentum 3. fejezet-e. Ha elolvastad jelentkezz és folytathatjuk a beszélgetést arról, hogy ki a fogalmatlan. Ha már nagyzolsz a tudásoddal (ami elég elavult, mert a mai procikban már van FS és GS szegmens regiszter is, így összesen 6 szegmens használható, a korábbi 4-el szemben /talán a 386-os vezette be a 6 szegmenst, most nincs időm visszakeresni, hogy melyiknél jelent meg az ES és a GS/).

"The DS, ES, FS, and GS registers point to four data segments. The availability of four data segments permits efficient

and secure access to different types of data structures. For example, four separate data segments might be

created: one for the data structures of the current module, another for the data exported from a higher-level

module, a third for a dynamically created data structure, and a fourth for data shared with another program. To

access additional data segments, the application program must load segment selectors for these segments into the

DS, ES, FS, and GS registers, as needed." néhány oldallal később: "In 64-bit mode: CS, DS, ES, SS are treated as if each segment base is 0, regardless of the value of the associated

segment descriptor base. This creates a flat address space for code, data, and stack. FS and GS are exceptions.

Both segment registers may be used as additional base registers in linear address calculations (in the addressing

of local data and certain operating system data structures).

Even though segmentation is generally disabled, segment register loads may cause the processor to perform

segment access assists. During these activities, enabled processors will still perform most of the legacy checks on

loaded values (even if the checks are not applicable in 64-bit mode). Such checks are needed because a segment

register loaded in 64-bit mode may be used by an application running in compatibility mode.

Limit checks for CS, DS, ES, SS, FS, and GS are disabled in 64-bit mode."

Ennyit a prociról (az AMD egészen hasonló, de azt még nem programoztam soha natívan).

Oprendszer és fájl formátumok:

Továbbá ha belenézel bármilyen tankönyvbe, leírásba a COM és EXE között a header a lényeges különbség, és az, hogy az EXE bárhova betölthető a memóriába. A COM nagy baja az volt, hogy az egész egy szegmensben kellett, hogy elférjen (64kbyte) így hidalták át azt a problémát, hogy nem tudták egyszerűen relokálhatóvá tenni a programot (ld. ez még a CP/M-ből érkezett hagyaték volt). Azaz így a program futása függetlennél válhatott attól, hogy fizikailag hol van a memóriában. Fontos ez még a 8086 (8088) időszakban volt amikor a proci valójában 16 bites volt, de az címbusz 20 bites volt (lehessen >64kByte memóriás gépet építeni). Erre az egyik lehetséges megoldás volt a szegmens regiszterek bevezetése. Ahogy nőt a memória egyre nagyobb igény volt arra, hogy a program ne mindig ugyanoda kerüljön (ld. pl. korai 8 bites gépek pl. C64, ZX81, ZXspectrum, Primo, HT1080Z és társaik), ahol oprendszer sem volt (a mai értelemben) a program mindig ugyanoda került és egyszerre egy program futott. A 8088 (XT) sem támogatta még a multitask működést, de a memória már szabadabban volt alakítható, és nem volt garantálható, hogy hova kerül a program (egyébként már a CP/M-ben sem volt az, de azt irányt hagyjuk). Így vagy az maradt, hgy egy szegmenst használtunk és azon belül dolgozott a program így viszont csak 64kbyte-ot látott (a négy szegmens regiszter értéke állandó volt, bár az adat szegmenst odébb lehetett rakni ha jól emlékszem a 6.22 DOS-ban volt már rá valami megoldás, de nagyon régen volt és már nem emlékszem tisztán és vissza keresni a doksikat egy ilyin bunkó miatt nincs kedvem), vagy volt az EXE ami megoldott azt,h ogy működjön a program ha máshova került a memóriában (relokálhatóság továbbra is fontos, ahogy a kolléga írta). Aztán megjelent a 386-os proci és felforgatott mindent (ld. pl. védett mód). De ezt a kolléga már bemásolta, hogy miről szól (legalábbis a memória kezelés összefoglalását, mert több száz oldal részletesen leírva).

Amit írtál még "Hát, pedig ez baj! Roppant nagy baj, mert azt jelenti, nem vagy tökéletes. Tudod, a plain bináris azt jelenti, hogy nincs a file szerkesztve, nem tartalmaz stub-ot ... Szóval, plain bináris, hát banyek, az ilyen file-ok futnak jellemzően beágyazott rendszerek és régi 8 bites gépek processzorain is."

ez egy orbitális szamárság. És most döntsük el, hogy régi 8 bites rendszerekről beszélünk, vagy korszerűbb rendszerekről?

Ha meg beágyazott rendszerekről beszélünk ott nagyon-nagyon ritka a fájl. Sok helyen bent van egy (E)EPROM-ban a program és onnan fut és nincs is fájlban. Esetleg van egy minimális firmware bennük, de ez nagyon nem a kérdéshez tartozik, és flash kártyáról fel tudnak olvasni valami bináris fájlt amit betöltenek a memóriában és onnan futtatnak (hát sok ilyet láttam, de, hogy ezt plain binárisnak hívnák még soha). Itt is vannak különböző fájl formátumok (pl. Intel HEX amit sok helyen használnak, könnyű beolvasni, szinte mindenre megírták már "tréfásan" /bár azt úgysem érted/ a kenyérpirítótól az űrsiklóig mindenre).

Ha meg nagyobb a cucc akkor meg már ráfér egy ARM proci és kerül rá egy emb. linux/windows/android és onnan kezdve már megint másról beszélünk. Vagy ami még gyakori, hogy van bent egy FPGA és azon kialakítunk egy ún. soft processzort (kb. olyan funkcionalitással amire szükség van) és megint megy rá egy emb. linux/windows rendszer és megint visszakanyarodtunk az exe (vagy elf) fájl problematikájához.

Akinek itt fogalma sincs semmiről az nem az a kolléga aki eddig jó és értelmes, személyeskedés mentes válaszokat adott, hanem te vagy.

"A COM nagy baja az volt, hogy az egész egy szegmensben kellett, hogy elférjen (64kbyte) így hidalták át azt a problémát, hogy nem tudták egyszerűen relokálhatóvá tenni a programot"

A com formátumnak semmi baja nem volt. A relokálhatósághoz a com-nak meg semmi köze. Azt soha nem is akarták relokálhatóvá tenni. A plain bináris volt az első állomány, régen, még a 8 bitesek korában. Nem tartalmazott semmit, csak szekvenciálisan az adatokat és az utasításokat. Ez került a memóriába, amiből amúgysem volt sok akkor még, és ott futott, egyedül. Mivel multitaszk akkoriban nem létezett. Nem volt szükség másra.

Sajnos azt kell mondjam, az ismereteidről világít, hogy innen-onnan kapargattad össze, tárgyi tévedések egész sora tarkítja. Csak egy-kettő ezekből:

"Fontos ez még a 8086 (8088) időszakban volt amikor a proci valójában 16 bites volt, de az címbusz 20 bites volt (lehessen >64kByte memóriás gépet építeni). Erre az egyik lehetséges megoldás volt a szegmens regiszterek bevezetése."

20 bites címbusszal 1 MB lineárisan címezhető. Mit zagyválsz itt a "valójában" 16 bites prociról?

A szegmentálás egészen más okokra vezethető vissza. Még egy gyöngyszem:

"Ahogy nőt a memória egyre nagyobb igény volt arra, hogy a program ne mindig ugyanoda kerüljön"

Ezen jót nevettem.

Nem a memória mérete, hanem elsősorban a multitaszk miatt - tehát hogy egy időben több program futhasson - vált szükségessé a plain bináris formátum mellett egy olyan, amelyet a memória bármely részébe be lehet tölteni.

"Aztán megjelent a 386-os proci és felforgatott mindent (ld. pl. védett mód)."

Mit forgatott fel a 386-os proci? Védett mód már a 286-osban is volt.

"Ha meg beágyazott rendszerekről beszélünk ott nagyon-nagyon ritka a fájl."

OMG.

És végül ez:

" Itt is vannak különböző fájl formátumok (pl. Intel HEX amit sok helyen használnak, könnyű beolvasni,"

Te jó ég! Azt sem tudod, hogy mi az intel hex formátum. Az nem futtatható te szerencsétlen! Az intel hex egy olyan formátum, amely lehetővé teszi hogy 8 bites bináris adatot 7 bites közegen (terminál) átvihess a gépbe, de ott azt futtatni nem tudod, mert csak karaktereket (0..9, A..F) tartalmaz!

Kérlek!

Áruld el nekem, miért szóltok hozzá olyasmihez, amihez lövésetek nincs, csak innen-onnan összeolvasgatott, rosszul értelmezett butaságok tömkelege? Mire jó ez?

A plain bináris file-ról (ilyen a .com is) itt tudtok ismereteket szerezni:

"What is the difference between plain binary format (.bin) and Windows Executable (.exe)?"

[link]

vagy itt:

"D1.2 --bin Produces plain binary output, one file for each load region. You can split the output from this option into multiple files with the --widthxbanks option."

[link]