> A program megy, de nem működik, tehát kompatibilis. :-D
Valóban, feltételes módban kellett volna azt az egy mondatvégi szót írni: "maximum az OS-ből hiányzik már a meghívott funkció, de maga a program futna". Nyugodtan ignoráld facepalmok vagy akármik kíséretében az egész mondanivalót egy hiányzó toldalék miatt; szerintem enélkül is tökéletesen érthető volt, hogy opcode kompatibilitásról beszélünk.
> A 6502 mellé azért kevertem oda teljes joggal a 8080-at
Utólag. Na, az a csalás. Utólag belerakni valamit. x86-ról volt szó előtte, nem másról. A másik szálon meg 4 féle arch-ról. (Nem mintha egyébként ez változtatna a többin, ezt csak a "csaltál" kitételedre írtam.)
> Itt az egy pont a MSnek (Intelnek), hogy crossassemblerrel gyorsan át lehetett tuszkolni a programokat.
Igen, mert volt olyan. 6502-ről 68000-re hogy tuszkolták át a programokat? Sehogy. Írhatták meg újra. 6502-esen. 68000-esre. Biztos egyszerűbb dolguk volt, mint a mikiszoftnak.
> A 286 korszakban már voltak DOS alá programok.
Mert előtte nem. Előtte csak maga a DOS volt, programok nélkül. Még kommandkom sem volt.
> Az új CPU előnye - eltekintve néhány kivételtől - csak a gyorsaság volt.
Irreleváns. Nem az előny volt a lényeg, hanem a váltási nehézségek minimalizálása, ami az x86-os vonalon belül megvolt.
> Pontosan ezért keveredett bele a C fordító is, hiszen a DOS még assemblerben készült. Viszont utána olyan kódbázis alakult ki, amely - esetleg némi befektetéssel - platformok között hordozható lehet.
Az Apple cuccai meg Lisa ill. Apple Pascalban. Ott a C-vel nem is foglalkoztak. Többek közt ezért is irreleváns a C fordító. Persze a Pascal is hordozható, ha van a túloldalon/túloldalra fordítód, de az Apple-nek nem volt, amíg meg nem írták.
> Éppen ott tartunk, hogy a MS a múlt héten vásárolt processzoromat a jövő héten nem fogja támogatni. :-D
Csakhogy ennek semmi köze az x86 CPU-k egymás közti opcode kompatibilitásához, amiről szó volt. Porszívót nem vettél véletlenül a múlt héten? Tudod mikiszoft félét, amivel sosem fogsz szívni... Esetleg azt is besuvaszthatnád ide érvnek.
> Az első mondatodnak ma már kizárólag az "x86 egyes lépcsői között" van értelme. Ha a szoftverparkod már két lépcsős, az sok is lehet. Ilyenkor a gyártó alaposságán múlik a platformváltás zökkenőmentessége. És ebbe beleértendő az is, hogy felmérést készít a felhasználók által kialakított szoftverparkról, konzultál az egyéb szoftvergyártókkal. Ez a zárt kód és idegen CPU(k) hátránya.
Bármilyen régebbi x86-os opcode-ra forgatok le egy programot, az 99%-os valószínűséggel futni fog a mostani gépemen is, hacsak nem hajítottak ki valami utasítást. Én még nem találkoztam ilyennel, de shit happenz.
> De akár vissza is lehetne fordítani a dolgot. Jó dolog-e az, ha az Intel kompatibilis a 40 évvel ezelőtti opkódokkal. Vajon nem okoz ez valamilyen hátrányt?
Nekik? Biztos. A szoftverfejlesztőknek és a felhasználóknak? Lehet. De ha okoz is, előnye messze több van.
> Tehát nem kötekedek, csak egyrészt nem látom akkora problémának a váltást.
Ez a mondat értelmezhetetlen. Nem látod akkora problémának, mint mit? Vagy csak úgy simán, nem akkora probléma? Utóbbi esetén értelmezhetetlen, hogy hogy kapcsolódik ide, mert én sehol nem állítottam olyat, hogy ez aaakkkora probléma, hogy világvégemindmeghalunk; azt mondtam, hogy nehezebb egyik archról átállni a másikra, mint egy archon belül egyik modellről a másikra. Ennyi volt az állítás, amiből ez az egész szál elindult és nem több. Ezt azóta sem cáfoltad, csak belehoztál a szálba olyan elemeket, amiknek köze nem volt az egészhez, pl. C fordító, mert más nyelv nincs is; hát az Apple-nél meg pont nem C-ben ügyködtek anno.
> Másrészt meg nincs teljesen igazad az "egyes lépcsőkben" sem. Belátom, a DOS az adu, bár értelme nincs. Ha az egy lépcsőből véletlenül kettő is lesz, akkor az oprendszer jelenléte (és a driverek hiánya) miatt erősen megkérdőjelezhető a kompatibilitás.
Az MS-DOS-t azért hoztam fel, mert amikor az Apple váltogatta az architektúrákat, akkor a "túloldalon", az x86-os világban az MS-DOS dívott. De akkor hagyjuk az MS-DOS-t; mondok mást: WINE. Azért tudja a virtuális gépeknél sokkal nagyobb teljesítménnyel "emulálni" a windowst, mert nem kell a CPU-t is emulálnia. És működik a vindózos cucc Linuxon, BSD-n, Solarison, meg ahova le tudod forgatni a WINE-t. Az "oprendszer" (esetünkben a windows) jelenléte nélkül. Fogod a windózos binárisodat, átrakod akárhová, az API wrappingot a WINE (elméletileg) biztosítja és az opcode kompatibilitásnak köszönhetően futni fog. (Már, ha a WINE bugmentesen implementálta a szükséges interface-eket és értelemszerűen ez a hordozhatóság csak azonos architektúrán belül értendő.) És - bár nem tudom, milyen hatékonysággal, de - ugyanezt csinálja a mikiszoftnak a WSL, vagy mi a rosseb nevű Linuxos rétege. Nekik is mennyivel egyszerűbb a dolguk, hogy a CPU emulációjával nem kell bajlódniuk. (Egyébként WINE még windowsra is van és sok esetben sokkal kompatibilisebb a korábbi windózokkal, mint maga a host windows. Na, többek között ezért is irreleváns, hogy az ms nem akarja a múlt héten vett CPU-dat támogatni.)
> Mert ugye a 10 éves gépemre rakhatok DOS-t - de minek, viszont se Windows se linux környezetben nem fognak futni a 386-os programok.
A DOS-osak? windowson egy részük futni fog. Itt egy kis DOS-os karaktertáblaprogram. Xp-n még fut, Win7-esen már nem, ugyanazon a gépen. Nem a 386-tal van a baj (főleg mivel nem 386-os kód), hanem az API-val.
> Az opcode pipa, csak nem megy. Ez a második mondatod.
Mint mondtam: köss bele egy hiányzó toldalékba. A szövegkörnyezetből elég egyértelmű volt, hogy miről beszélek. Ahogy mondják: értsd jól. Te nem akartad érteni, inkább belekötöttél egy lemaradt szótagba, több kB szövegben. Baromira nem az újabb OS-ből már hiányzó részek okozta breakage volt a lényeg, hanem az, hogy a régebbi programokat egyszerűbb az új rendszeren életrekelteni, ha az architektúra azonos. Nem, még az OS sem feltétlen kell hozzá, ld. WINE.
