Miért nem értik meg az emberek, hogy vége az IT "aranykorának"?

" Mi köze a C pointernek az oprendszer memória védelméhez? "

Látod? Ezért vagy te alkalmatlan, mert még ezt sem tudod.

Csak hazudozni tudsz, meg olyan állításokat tenni, amit nem támaszt alá a világon semmi.

pl. ez itt:

"Továbbra is a kérdés az "átlagos" fejlesztésekről szól, és nem arról, hogy előveszünk egy olyan területet amivel foglalkozik néhány 1000 ember ezen a bolygón. Lehet, hogy a te beszűküld tudatodban ez a fejlesztés csúcsa, de ma már marginális teljesen."

A kérdés nem erről szólt, hanem arról, hogy mit kell tudnia egy átlagos fejlesztőnek?

Mi az a szint, amit ti nem vagytok képesek megütni?

És az teljesen mindegy, hogy néhány ezer, vagy több. A lényeg az, hogy a többi is képes lenne-e rá vagy sem.

És nem a fejlesztés csúcsa, ezt én nem is állítottam, hiába hazudod, de a piac egy szegmense. Ráadásul, elég fontos és jól fizető szegmense. A kapcsolódási pont nem is ez, hanem az, hogy egy polcról levett fejlesztőnek képesnek kell lennie ezt a szegmenst is kiszolgálni.

> A valós módban fordított program meg nem fog futni védett módú környezetben, ahogy a védett módban fordított program sem indul el valós módban, mert eleve, más védett módban a memóriakezelés.

Ez olyan, mintha azt mondanám, hogy a labda piros. Te meg azzal cáfolnád, hogy nem, mert gömbölyű. Persze én vagyok a tudatlan ostoba, mert bár a labda színéről volt szó, nem említettem, így bizonyára nem is tudom, hogy a labda gömbölyű. Nem az a kérdés, hogy fut-e egy valós módra *fordított* program védett módban, hanem az, hogy más *kódot* kell-e írni ahhoz, hogy valós helyett védett módra fordítsam a C-ben írt programot. A C nyelvű program *írása*, *tervezése* során nekem kell-e tudnom azt, hogy mire lesz lefordítva és az hogyan működik. Nyilván van az a helyzet, mikor direkt módon, alacsony szinten érünk el hardvert, de az más tészta.

De akkor a hecc kedvéértd összedobtam egy apró programot: [link]

(Bár félek tőle, hogy elkezdesz olyan dolgokat nagyító alá venni, ami a kérdés szempontjából irreleváns, mondjuk hogy nincs felső határ megadva a program argumentumára, így a ciklusváltozók túlcsordulhatnak. De próbáljuk meg, hátha tudunk a kérdés szempontjából releváns vizsgálódási szempontra koncentrálni.)

- Ez a C program milyen architektúrára íródott?

- Hülye kérdés, olyan architektúrára lehet fordítani, amire szeretnéd, meg persze amire írtak C fordítót.

- x86-os architektúrán ez real, protected vagy long módban kezeli a memóriát?

- Hülye kérdés, olyanon, amilyen módban fordítod.

- Milyen operációs rendszerre íródott ez a program?

- Hülye kérdés, olyan operációs rendszerre fordítod, amilyenre szeretnéd és amelyiken van C fordító.

- Ezt a kódot lefordítottuk védett módra. Futtatható-e a program valós módban?

- Nyilván nem. De tulajdonképpen ennyit elég is tudnod.

- Oké, de melyik sorokat kell megváltoztatni ahhoz, hogy védett módban is fusson?

- Nem kell a programon változtatni, csak le kell fordítani védett módhoz a változatlan forráskódot.

- Lefordítottuk ezt a programot Windows 10-en. Fog-e futni Linuxon?

- Nem, legalábbis emuláció nélkül önmagában nem.

- Mit kell változtatni a kódon, hogy Linuxon is használjuk?

- Semmit, csak le kell fordítani Linuxra.

- Hogy-hogy nem kell változtatni a kódon ahhoz, hogy más operációs rendszeren és/vagy más architektúrán is lefordítható legyen?

- Azért, mert a C egy absztrakció a gépi kód felett. Lehet, hogy egy hardverközeli absztrakció, de absztrakció. A különböző rendszerek eltérő működését és kezelését elfedi, absztrakt szintre emeli pl. a malloc függvény, meg az az opcode, amire ezt a fordító fordítja. Így ugyanaz a malloc függvény oprendszertől és architektúrától függetlenül ugyanazt a működést valósítja meg a lefordított programban, ami a C nyelv specifikációjában áll. Tovább megyek, nem *szabad*, hogy a program működése függjön attól, hogy alacsony szinten milyen módon történik a memória kezelése. A fordítónak kutya kötelessége a malloc függvényhívást úgy lefordítania az adott rendszerre, hogy az egy logikailag egybefüggőnek tűnő memóriát biztosítson és akként is kezeleje, meg egy erre mutató logikai mutatót adjon vissza, vagy ha a kívánt memóriát nem tudja biztosítani, akkor NULL-t adjon vissza, *függetlenül* attól, hogy amúgy mi történik úgymond a színfalak mögött.

- Akkor nekem – mint C nyelven programozónak, aki egy Eratoszthenész szitáján alapuló prímszámkereső programot ír – kell-e foglalkoznom, hogy milyen architektúrán és oprendszeren pontosan hogyan is történik a memóriafoglalás, memóriacímzés? Főleg úgy, hogy fogalmam sincs, a jövőben ki milyen – akár még nem létező, vagy általam nem ismert – operációs rendszerre és architektúrára fogja lefordítani a programomat?

- Nem igazán, ez nem a te dolgod, hanem azé, aki az architektúrát megtervezte, az oprendszert, meg a C fordítót írta. Nyilván vannak a hardverből, architektúrából, oprendszerből fakadó korlátok, sajátosságok meg side effectek, amely megértéséhben *segíthet*, ha ismered a különböző platformok alacsony szintű működését is. De szigorúan véve neked elég legfeljebb a korlátok létezéséről tudnod, az okukról nem *muszáj*.

~ ~ ~

Írtam – igaz csak kísérletezésképpen – Androidra alkalmazást Java-ban. Valójában azt sem kellene tudnom, hogy Android rendszeren általában ARM architektúrájú CPU-k vannak. Történetesen tudom, de ha nem tudnám, akkor sem írtam volna más kódot. Ahogy azt sem kell tudnom, hogy amúgy van x86-os portja is az Androidnak. Azt is tudom, hogy az Android magja a Linux kernelen alapul. De ha nem tudnám, akkor sem írnék más programot. Megmondom őszintén, fogalmam sincs, hogy hogyan kezelik, hogyan címzi meg egy ARM architektúra a memóriát.

Miért nem tudom? Az Android forrása nyílt, az Android is, az ARM architektúra is jól dokumentált, ha kicsit is szükség lett volna erre a tudásra, akkor utána tudtam volna nézni. Csakhogy ezeddig nem volt szükségem rá. Maga a Java gondoskodik arról, hogy ha valaki csinál egy 49 bites 3-as számrendszeren alapuló rendszert, ahol a memóriát Fibonacci-számrendszerben kell megcímezni triplán szegmentált logikával, és portolja rá az Androidot meg a java virtuális gépet, akkor anélkül fusson rajta az alkalmazásom, hogy minderről én tudnék.

Nekem, mint Androidra fejlesztő programozónak milliószor fontosabb, hogy tudjam, hogy az Andorid UI-ja milyen komponenseket nyújt és azok mit tudnak. Meg milliószor fontosabb tudnom, hogy Android milyen jogosultsági rendszerrel rendelkezik, milyen művelet milyen jogosultsághoz kötődik, és ez hogyan változott meg az Androd n+1-en az Android n-hez képest. Ezt meg nekem kell folyamatosan újra és újra tanulni, még ha tanultam volna egy egyetemen mobilalkalmazás fejlesztést, akkor is nekem kell újra tanulnom, verzióról verzióra utánajárnom, tehát azt a tudást és tapasztalatot, ami valóban élő, ami friss, azt nem az egyetemen sajátítottam el és fogom ott elsajátítani a jövőben sem. (Nota bene mikor én huszonpár éves voltam, nem léteztek okostelefonok. Mégis velem egykorú és idősebb programozók – diplomások és diploma nélküliek – specializálódtak mobilalkalmazás fejlesztésre és jók benne.)

45,

hatalmas nagy hülyeségeket írsz le.

1. A C programot, hogy ne kelljen a vashoz, vagy az opréhez igazítani, kis túlzással kb. hello world szintig írhatod, attól följebb, komplexebb esetekben, még ha le is fog fordulni, nem kivánt működés fog fellépni, vagy már eleve el sem indul.

2., Te androidot nem programoztál soha. Te egy virtuális gépre írtál valamit, ami független a vastól, de hát, tudod, a VM-eknek ez a céljuk. Egyedül itt mondható el az amiről te beszélsz, de itt is más volt az eredendő ok.

Ráadásul, a cél sem valósult meg maradéktalanul az évtizedek alatt. Elég a kicsavart JAVA szlogenre utalni: írd meg egyszer, keress hibát mindenütt.

Egyik példád (a korábbiakkal együtt) sem igazolja azt, amit bele szeretnél látni, mármint, hogy a fejlesztőnek hülyének kell lennie és, hogy az egész azért lenne, hogy a fejlesztő elől elrejtsen memóriát és más dolgokat. Nem.

Amiről te görcsösen papolsz, az az egész elsősorban azért van, hogy a fejlesztés gyorsabbá, hatékonyabbá, olcsóbbá és/vagy kényelmesebbé váljon. Ezen túl, az utóbbi időben előtérbe került a biztonság és az adatvédelem, összességében a rendszerek üzembiztonságára való törekvés. Ennek okán vannak API-k, layerek és nem azért, hogy bármit is eldugjanak a programozók elől, már csak azért sem, mert ezeket az API-kat, layereket is, hogy, hogy nem, de szintén programozók fejlesztik ki.

46 (2024.11.11 19:22):

Aki hatalmas hülyeségeket ír folyamatosan (és nem ez az egyetlen kérdés ahol ez előfordul) az Te vagy, és nem a korábbi válaszadó. És pl. rád jellemző ha már nem tudsz ész érvekkel előállni jön a durva személyeskedés, a képtelenebbnél képtelenebb jelzők használata, amivel sértegeted a válaszadókat (gondolok itt kis sügér és társai amik már törölve is lettek nagyon helyesen). Ez pont az a fajta "vita" amikor már nem tudsz értelmes érveket mondani a saját hazugság spirálodból kimászására jön a sértegetés.

Nézzük a hsz-edből csak egy konkrétumot (az, hogy a korábbiakra sem válaszolsz szintén téged minősít):

"hogy a fejlesztőnek hülyének kell lennie és, hogy az egész azért lenne, hogy a fejlesztő elől elrejtsen memóriát és más dolgokat. Nem."

1./ Senki sehol nem írta le, hogy a fejlesztőnek hülyének kell lennie. ("egy hülye szembe megy az autópályán! - Egy? mindegyik szembe jön" és igen itt te vagy az a hülye aki szembe megy az autópályán). Ezt te képzelted bele, soha senki sehol nem állította, hogy a fejlesztőnek hülyének kell lennie. Amit állítunk, hogy most (tehát 2024-ben) egy fejlesztőnek mást kell tudnia mint ez előtt 20-30-40 évvel.

2./ " A C programot, hogy ne kelljen a vashoz, vagy az opréhez igazítani, kis túlzással kb. hello world szintig írhatod, attól följebb, komplexebb esetekben, még ha le is fog fordulni, nem kivánt működés fog fellépni, vagy már eleve el sem indul." -> Ez szembe megy azzal ami az összes magas szintű programnyelv kidolgozásakor szempont (kezdve Cobol, Fortran, Algol mint első szabványos magasszintű nyelvek); később a C és társaik esetén, hogy az elkészített program hordozható legyen, és amit az egyik gépre megírt valaki az változtatás nélkül (maximum kisebb változtatással) átvihető legyen a másikra. Ezért lettek ezek a nyelvek szabványosítva (legtöbbször eleinte ANSI később nemzetközi akár ISO szabvány is). Ha a fejlesztő betartja a szabványokat és annak megfelelően írja meg a programját és egyik operációs rendszerről a másikra, vagy esetleg egészen más hardverre viszi át akkor csak nagyon minimálisan (szerencsés esetben egyáltalán nem) kell átalakítani a programját. Nekem volt olyan (nem pici) programom ami 4 féle operációs rendszeren futott 4 féle hardveren, és összesen annyit kellett változtatni, ami az egyes operációs rendszerek esetén a fájlnevek szabályai eltértek! Semmi mást. Simán lefordult és lefutott. Nem kellett módosítani semmit. És ha valaki ténylegesen nem hülye akkor betartja ezeket a szabályokat és a programja fog működni. Néhány tényleg nagyon rendszer specifikus rész esetén lehet eltérés a forrás kódban. De ez ritka mint a fehér holló. Persze ez csak akkor igaz ha a fejlesztő nem hülye, és betartja a szabványt és nem használ egyedi specifikus megoldásokat.

3./ " hogy az egész azért lenne, hogy a fejlesztő elől elrejtsen memóriát és más dolgokat. Nem." -> De pontosan azért van a hardver, az operációs rendszer és minden ami körülötte van, hogy ne kelljen az alkalmazási program írójának bajlódnia azzal, hogy a./ egyáltalán mennyi memória van a gépben; b./ hogyan történik a processzor és a memória között az adatok mozgatása; c./ hogyan történik fizikailag a memória címzése. Nyilván aki megírja a fordítót és a standard függvényeket neki kell ezeket tudnia. De pl. már a POSIX szabvány is pont arról szól, hogy ez még jobban el legyen rejtve a felhasználói program elől. És pontosan erről szól (bár végül beismered, hogy hallottál ilyenről) az, hogy "VM"-eket használunk, hogy újabb és újabb rétegek kerülnek az alkalmazói program fejlesztője és a hardver közé, hogy ne kelljen ezzel foglalkozni. De aki leragadt az 1960-as évek szintjén az ezt sose fogja igazán felfogni. (Ugyan írtad, hogy akkor még nem is éltél, de a tudásod és a programozási stílusod az 1960-as évek szintjén mozog, feltehetően egy 1960 körül írt könyvből tanultad meg valamikor és azóta elfelejtetted a tudásodat frissítani, vagy fel sem fogtad az újdonságokat).

46: Nem érzed, hogy saját magadnak mondasz ellent, mostmár olyan szinten beletekeredtél a saját zagyvaságodba, hogy egy mondatodon belül cáfolod saját magad. Szerintem pihenj le, és részegen ne írj hozzászólást.

"Amiről te görcsösen papolsz, .... Ennek okán vannak API-k, layerek és nem azért, hogy bármit is eldugjanak a programozók elől, már csak azért sem, mert ezeket az API-kat, layereket is, hogy, hogy nem, de szintén programozók fejlesztik ki."

Eleve többször leírtuk, hogy "átlagos fejlesztőről beszélünk" és leírtuk, hogy igen vannak akik az operációs rendszereket, az alacsony szintű részeket fejlesztik, nyilván nekik más tudásra van szükség. De ez 10 000-ből jó ha 1 eset. A többiek meg használjak az API-kat meg a "layereket" (jelentsen ez itt most bármit is).

Nem érzed, hogy ellentmondasz saját magadnak? Te tényleg ennyire elképesztően sötét vagy?

Az egész legalább 50 éve arról szól, hogy a cél az (bár ezt te is már kezded beismerni): az, hogy a szoftver fejlesztés olcsóbbá váljon. Ez hozza magával, hogy gyorsabban könnyebben lehessen fejleszteni. Ez hozta magával (és ez 1957-ben kezdődött az első szabvánnyal ami egy programnyelvet írt le), hogy az alkalmazói program hordozható legyen. Azaz ne kelljen ugyanazt megírni 10 féle hardverre, a 10 féle hardveren futó 50 féle operációs rendszerre. Elég legyen az alkalmazói programot (és ha képes lennél alapszintű szövegértésre akkor láthatnadá, hogy az összes hsz-ben mindannyian erről beszélünk és nem az operációs rendszerek és a fordítók és alapvető libek, API-k és továbbiak fejlesztéséről) lefordítani a másik platformon és fusson lehetőleg változtatás nélkül. (Ezt az ANSI 1957-ben leírta, amikor az első programnyelvet szabványosította.). De ez szerepel az összes programozás tankönyvben is. Ahhoz, hogy egy program hordozható legyen (igen ehhez kellenek az API-k és a "layerek" amit végül te magad is beismersz, végre valami ami nem egetrengető ökörség a hsz-edben), ahhoz az kell, hogy azokat a "finomságokat" amiket Te állandóan az összes hasonló kérdés alá odaböfögsz, hogy egy ARM alapú Androidra fejlesztő programozónak ismernie kell bitre pontosan az Intel ma már sehol nem használt szegmentált címzését. Ennyire te se lehetsz hülye. Még ha elfogadom azt a tévképzetedet, hogy ezeknél a szabványos nyelveknél, API-knál nem volt elsődleges cél az "elrejtés" végül csak hozza magával, hogy "eltűnik" az elől aki az API-t használja. Ld. pl. a kolléga által többször emlegetett malloc függvény a C-ben. Bármelyik C-ben ugyanúgy néz ki, függetlenül, hogy az Intelre, ARM-re, Windowsra, Linuxra, BSD-re, QNX-re, Androidra, iOS-re vagy bármilyen más oprendszerre fordít. Majd az aki a mallocot megírja annak nyilván tudnia kell, hogy az adott oprendszer esetén ezt hogyan is kell végrehajtani. Aki meg az oprendszert írja az meg nyilván "előkészíti" az ehhez szükséges rendszer eljárásokat (itt már több is lesz, ld. pl. Linux esetén) és majd aki a malloc-ot megírja meghívja szépen egmás után ezeket a syscall-okat. Szintén az aki az operációs rendszert írja az majd lekezeli azt, hogy ez a hardver és a processzor szintjén hogyan nézzen ki. De továbbra is az egész hsz háborúban nem ezekről a fejlesztőkról beszélünk hanem azokról akik bepötyögik a C forrásukba, hogy malloc (vagy mondhatnám a printf-et is, vagy bármi mást ami a szabványos C része). Az, hogy ez most cél volt, vagy "következmény" az már lehet filozófiai vita része. De minden esetre mára eljutottunk odáig (szerencsére), hogy megírunk egy bármilyen alkalmazói programot és ha betartjuk a szabályokat igen minimálisan kell változtatni ha egyik rendszerről a másikra visszük át a cuccot, mert minden rendszerspecifikus dolog el van "dugva" mert erre megy a világ.Igen amit kolléga írt: "egy hülye szembe megy az autópályán".

"Eleve többször leírtuk, hogy "átlagos fejlesztőről beszélünk" és leírtuk, hogy igen vannak akik az operációs rendszereket, az alacsony szintű részeket fejlesztik, nyilván nekik más tudásra van szükség."

Mégis, minek képzeled te magad?

Azt, hogy egy programozónak mit kell tudnia, nem te döntöd el és nem 2*Sü.

A vita pedig arról szól, ami amúgy vitán felül áll.

Tételesen, hogy hogy egy képesített programozó tudásának részét kell képezze a PC memóriájának valós módú (szegmens:offset plusz 4 bites eltolás) címzésmódja, vagy sem. Ha megnézzük az egyetemek/főiskolák releváns anyagát, azt találjuk, hogy bizony az anyag része ez még ma is. Oktatják, ismertetik, mi több, számon is kérik a hallgatókon. Ez az elég elborult cimzésmód egyébként a maga korában sem lehetett valami népszerű dolog, de a számítástechnika megkerülhetetlen részét képezte, hiszen az akkor egyeduralkodó operációs rendszer is ezt használta. Hogy miért tanítják ezt ma is? Gondolom azért, mert ha valaki ezt megérti, akkor a többi sem lesz számára probléma.

A főiskolák/egyetemek nem a ti kivánalmaitok szerint végzik az oktatást, ha tetszik ez nektek, ha nem. Ezeknek az intézményeknek a deklarált célja az, hogy a hallgatóknak részletes, átfogó, általános tudásalapot biztosítsanak. Olyat, ami nem a pillanatnyi hype-hoz, divat-hullámoz igazodik, hanem annál sokkal értékesebb, hasznosabb ismereteket nyújt. Hogy a leendő diplomás, a szakember, a tudása okán cserekompatibilis legyen a lengyel, amerikai, belső ázsiai, vagy fülöp szigeteki kollégájával. Olyan tudásra, ismerethalmazra tesz szert, amivel bármilyen környezetbe képes lesz integrálódni.

Ez meg nem úgy meg, ahogy 2*Sü elképzeli, hogy az egynyári sügér, aki pár hónap alatt megtanult valamilyen szinten HTML-kedni és havi 200 ficcsért nyomja sz.rásig, az programozó szakemberként, vagy "frontend programozóként" aposztrofálja magát.

Hát nem. Ezek a szerény tudású emberek, legyen bármilyen jó minőségű az, amit csinálnak, mégis csak egy nagyon vékonyka szeletével bírnak annak a tudásnak, amivel rendelkeznek a diplomások, a valódi szakmabeliek. Mert az nyilvánvaló, hogy ezek a "frontendesek" soha nem voltak szakmabeliek, ahogy a gumisnál dolgozó betanított munkás sem autószerelő.

> 1. A C programot, hogy ne kelljen a vashoz, vagy az opréhez igazítani, kis túlzással kb. hello world szintig írhatod, attól följebb, komplexebb esetekben, még ha le is fog fordulni, nem kivánt működés fog fellépni, vagy már eleve el sem indul.

Mutass egy olyan példát, aminél ennek az oka az eltérő architektúrák eltérő memóriacímzése. Mert ha pl. a fájlrendszert akarod elérni, ott már lehetnek olyan eltérések, amik eltérő kódot, vagy a kód elágaztatását igénylik. Meg persze ha direkt hozzáféréssel kezelsz hardvert, ami szintén nem túl gyakori, mert ezeknek is megvan a maguk absztrakciós rétege. Meg nyilván ha direktben hívsz meg egy Win32 API-t, az Linux alatt érthető okokból nem fog futni. De a memóriakezelés tekintetében mondasz-e egy olyan példát, ahol adott rendszeren egy kód jól fut, egy másik rendszeren meg nem, és aminek az oka a memóriacímzésből fakadó eltérés?

> 2., Te androidot nem programoztál soha.

Szakember vagy. Nyilván tudod, hogy az Android hivatalosan ajánlott programozási nyelve sokáig a Java volt, 2019 óta meg a Kotlin az előnyben részesített nyelv. Mindkettő VM bájtkódra fordul. Tulajdonképpen – ha valamit is csináló, értelmes alkalmazást akarsz írni észszerű időn belül – nem is nagyon volt más alternatíva, lévén az Androidhoz csak ebben implementált API van közreadva. (Ma már kicsit árnyaltabb a kép, meg nem is vagyok ennek a területnek a szakértője, de azért a mobilalkalmazások igen nagy hányada VM-re forduló kódot jelent.) Nyilván szakemberként tudod, hogy a Java és a Kotlin is egy programnyelv, így a bennük való programírást is programozásnak nevezzük. Akkor tulajdonképpen mi alapján mondod mégis azt, hogy Android alá, a Google által hivatalosan ajánlott nyelven írt program megírása nem az Android programozása? Ja, nem hex editorral kell opcode-ot írni, de hát C-ben sem.

> Egyik példád (a korábbiakkal együtt) sem igazolja azt, amit bele szeretnél látni, mármint, hogy a fejlesztőnek hülyének kell lennie és, hogy az egész azért lenne, hogy a fejlesztő elől elrejtsen memóriát és más dolgokat. Nem.

Nem azért született a C, mint absztrakciós szint, mert a fejlesztő hülye. Azért született, mert a fejlesztő nem akar 10 különböző kódot írni, hogy 10 különböző platformon, oprendszeren, architektúrán is futtatható legyen ugyanaz a program.

> Ennek okán vannak API-k, layerek és nem azért, hogy bármit is eldugjanak a programozók elől

Hát nem a biztonság és az adatvédelem miatt. Az ellen az API önmagában nem véd.

Az API egészen pontosan arra való, hogy egy nyilvános, egzakt módon definiált és jól dokumentált felületet biztosítson akár egy zárt kódú program vagy operációs rendszer esetén is, így az API-n keresztül úgy lehet az adott program vagy oprendszer szolgáltatásait elérni, hogy ehhez meg kellene ehhez osztani annak a forrását, vagy ismerni kellene a belső működését. Egészen pontosan erre találták ki. Azért hogy elfedje, elrejtse az API-t biztosító rendszer működését. Én nem, egyáltalán nem azért, mert az azt használót hülyének gondolják. Adott esetben azért, mert a rendszer belső működését titokban akarják tartani, adott esetben azért, hogy kompatibilitási réteget biztosítson, adott esetben meg azért, hogy különböző nyelven megírt programok is gond nélkül, azonos módon tudjanak egymással kommunikálni.

2*Sü, meg kell mondjam, te csak arra vagy jó, hogy bosszantsd az embert, vagy hogy legyen kin röhögni. Most már csak röviden válaszolgatok neked, mert unom a firkálmányaidat és a fafejűségedet.

>>> "Mutass egy olyan példát, aminél ennek az oka az eltérő architektúrák eltérő memóriacímzése."

Ezer ilyen akad, de nem csak a memória címzése, hanem már a processzor üzemmódja is korlát, mert x86 esetén pl. a BIOS és annak rutinjai, szolgáltatásai csak valós módban érhetőek el, védett módban erre lehetőség, jellemzően nincs. A képernyő memória direkt elérését szolgalmazó rutinokat már nem is hozom fel.

>>> "Nyilván tudod, hogy az Android hivatalosan ajánlott programozási nyelve"

A google egy magáncég, ergo, nincs olyan tevékenysége, hogy "hivatalos". Ami hivatalos, az a NAV felszólító levele, vagy egy bírósági végzés, netán rendőrségi idézés. Ezek mindegyike hivatalos, de a google és az ő céges nyilatkozataik éppen annyira hivatalosak, mint egy kocsma közepén ordibáló emberé, szóval: semennyire.

>>> "Nem azért született a C, mint absztrakciós szint, mert a fejlesztő hülye. Azért született, mert a fejlesztő nem akar 10 különböző kódot írni, hogy 10 különböző platformon, oprendszeren, architektúrán is futtatható legyen ugyanaz a program."

Ez a te, meglehetősen stupid álláspontod, amely primitív, nevetséges, azon túl, hogy merő kitaláció, ami a te tájékozatlanságodon alapul.

A C azért született, mert az assembly túl fárasztó, a B nyelv meg túl lompos és körülményes volt ahhoz, hogy kielégítse a UNIX-szal kapcsolatos fejlesztői igényeket és véletlenül sem azért, amit te ide behazudsz.

Eleve, a C nem absztrakciós szint, hanem egy MID level programozási nyelv. Az más kérdés, hogy mint minden programozási nyelv, nyújt valamilyen absztrakciót, más alternatívákhoz képest. Mondjuk a valamivel korábbi Algolhoz, Pascalhoz képest kifejezetten szegényes ez az absztrakció. A C kód meg kb. annyira hordozható, mint egy vonatszerelvény kerekek nélkül. Nem véletlen, hogy #include direktíva nélkül nem is igen lehet C nyelvű, működőképes programot írni. Pascalban viszont lehet. Ennek fényében éppen a C-re mondani azt, amit te behazudsz, ez az évtized vicce. A C nyelv éppen a hardver-közeliségének köszönheti a karrierjét.

Egyébként, hogy az igazat megtudd, a C kezdetben a UNIX opre forrása mellé volt csomagolva és nem volt több, mint egy preprocesszor meg egy transpiler (ez az egyik prog-nyelvről egy másikra fordít, de forrást köp ki). A preprocesszor a forrást feldolgozta, egy köztes formátummá alakítva, a transpiler meg ebből generált assembly kódot. Végül ezt a kódot fordították tárgykódra a célgép assemblerével.

Természetesen az egész cuccot mindenhol az ott egzisztáló gép hardveres képességeihez, egyedi adottságaihoz kellett igazítani. Ez azonban többnyire megérte, mert az assembly mnemonikok átírása és a HW specifikus részek kiigazítása még mindig kisebb munka volt, mint amivel az eredmény (a futó, biztonságos(nak hitt) UNIX) kecsegtetett.

Ráadásul, a C még csak nem is magas szintű, amit mellesleg megelőzött több, valóban magas szintű nyelv, mint a BASIC, Algol, Pascal, stb. De még ezek egyikének sem volt célja az, amiről te próbálod itt kábítani a népet a, már lassan egy kötetet kitevő marhaságaiddal.

>>> "Hát nem a biztonság és az adatvédelem miatt. Az ellen az API önmagában nem véd."

De igen, ugyanis az API, vagy egy köztes layer hivatott ellenőrizni például a memória hivatkozásokat, hogy egyáltalán, tartományon belüli e a kért cím, mert lehet, hogy nincs is n megabájt abban a gépben, csak n div 2. Ilyenkor, ha nem lenne erre való köztes layer, akkor a hiba magával rántaná az oprendszert is. De még írhatnék ilyen példát százat, nem létező, vagy foglalt port címekről, verem túlcsordulásról, hardware failure-ről, csak már nincs hozzá kedvem.

Az operációs rendszer legfőbb feladata az erőforrások adminisztrálásán kívül a védelem. A rendszer védelme (elsődleges prioritás) és a futó programok védelme (másodlagos prioritás).