Az interjúban a tehetséges szlovák elmondta nekünk, hogyan sikerült C # alkalmazást futtatnia a régi Windows 3.11-en.

kódtól

Ma a Windows 3.0 pontosan 30 évet ünnepel a bevezetése óta. Ahogy a verziószám sugallja, a mai legnépszerűbb asztali operációs rendszer harmadik legnagyobb, de nyolcadik kiadása volt.

Valójában az 1990-es évek elején még nem volt teljes értékű operációs rendszer - a Windows "csak" egy grafikus környezet volt, amely még mindig az MS-DOS-on alapult.

Ez nem változott a közvetlenül következő verziókban. Az MS-DOS képezte a Windows alapját az elkövetkező néhány évre, beleértve a Windows 3.11 verzióját 1993 végétől. Ezt megemlítjük Michal Strehovský szlovák programozó sikere miatt.

A majdnem 30 éves Windows 3.11-nél sikerült futtatnia egy C # programozási nyelven írt alkalmazást. Ez azért érdekes, mert ez a nyelv körülbelül 7 évvel később keletkezett. Abban az időben a Microsoft már a Windows 2000, vagy a legendás Windows XP verziójával foglalkozott. Mindkét esetben külön operációs rendszerek voltak, az MS-DOS alapja nélkül.

Ezenkívül a C # a 32 bites operációs rendszerek napjaiban keletkezett. Soha nem úgy tervezték, hogy programjait 16 bites operációs rendszereken futtassa. És pontosan ez a Windows 3.11.

Az interjúban elolvassa, mi inspirálta Michal Strehovskýt, milyen motivációja volt és mit kellett legyőznie a munkahelyén.

Michal Strehovský Közel 10 éve dolgozik a Microsoftnál, de munkája során nem sikerült, de szabadidejében hobbiként. Számítástudományt tanult a Masaryk Egyetemen. A múltban hozzájárult a Živé.sk-hoz - írt nekünk egyedülálló sorozat a repedésvédelemről - és előtte könyvekkel is foglalkozott. Korábban a rejtett Windows-beállítások megváltoztatására szolgáló, a SysTuner nevű szoftver mögött állt, amelyet 2004-ig fejlesztett ki.

Kezdjük azzal, hogy hogyan szerezte ismereteit. Gyermekkora óta érdekli a programozás?

Apám révén kezdtem bele a programozásba. Apja gépészmérnök volt, és akkoriban Sinclair ZX Spectrum számítógépet használt munkájához. Néha hazahozta a munkahelyéről, és a játékok mellett megmutatott egy rövid programot is, amelyet írt, és matematikai példákat adott a megoldásokra. A példák megoldása mellett azonban érdekelt a program működése.

Sok mindent magam tanultam szabadidőmben. Csak kíváncsi voltam, és tudni akartam, hogyan működnek a számítógépek. Senki nem parancsolta, hogy tanulmányozzam őket, és nem is adott forrást értük.

Ezenkívül az internet-hozzáférést a múltban nagyon korlátozták. Szüleim maximum heti egy órát engedélyeztek nekem. Szóval találtam néhány forrást erről a témáról az óra során, majd egész héten át tanulmányoztam őket az iskola mellett.

Két, a repedésről szóló könyv is inspirált, amelyek akkor jelentek meg.

Pontosan?

Meg kell nézni a processzor utasításait és meg kell érteni, hogy mit csinálnak. Azt is érzékelnie kell, hogy a program hogyan lép kölcsönhatásba "a világgal" és az operációs rendszerrel, amelyen fut. Élvezem ezt.

Az elmúlt 7 évben a .NET futtatását végző virtuális gép programozásával töltöttem. Ez idő alatt az ember is tanul valamit. Tehát hobbimat kombináltam azzal, amit csinálok, vagy a Microsoftnál dolgoztam.

Saját projektként létrehoztam egy könyvtárat, amelyet a fejlesztő hozzáadhatott alkalmazásához, és így bizonyos fokú védelmet nyerhet a repedések ellen.

Tehát megpróbálta kezelni magát a repedéssel?

Középiskolában próbáltam játszani vele. Saját projektként létrehoztam egy könyvtárat, amelyet a fejlesztő hozzáadhatott alkalmazásához, és így bizonyos fokú védelmet nyerhet a repedések ellen.

Például egyes szolgáltatásait sikerült észlelni, amikor a felhasználó megpróbált futtatni egy alkalmazást a hibakeresőben. A hibakereső olyan eszköz, amelyet a programozók, valamint a crackerek és a hackerek az alkalmazások elemzéséhez és a memóriában lévő adatok vagy utasítások nyomon követéséhez használnak, amelyeket a processzornak küldenek. A crackerek a biztonsági rések azonosítására és az alkalmazásfejlesztő által végrehajtott védelem kijátszására használhatják.

Természetesen megpróbáltam eladni azt a könyvtárat is, gondolom, 20 dollárra szabtam az árát. Néhány ember meg is vásárolta, de nem is kerestem belőle minimum adóbevallás benyújtásáért.

A kapcsolatok nélküli középiskolás diáknak azonban nehéz lesz megbirkóznia. De értékes tapasztalatokat szereztem belőle. Szinte biztos vagyok abban is, hogy ez biztosította a jelenlegi munkámat. Amikor a munkáltató meglátta, mit csináltam szabadidőmben, automatikusan érdekesebb voltam számára.

Nézzük meg, hogyan futtatott egy C # alkalmazást a régi Windows 3.11-en. Valahogy összefüggött azzal, hogy a Microsoftnál dolgozik?

Ez az egyik dolog, amivel hétvégén játszom. Ez semmilyen módon nem kapcsolódott a Microsoftnál végzett munkámhoz, kizárólag szabadidős tevékenységem volt. Arra gondoltam, hogy a C # eljuthasson olyan helyekre, ahol még nem jutott el, és senki sem használja. Számos kísérletem volt, amelyek közül a leghíresebb valószínűleg az volt, amikor sikerült C # -et kapnom a Windows 3.11-en.

Ez az érdekes teljesítmény azért van, mert a Windows 3.11 1991-ben jelent meg. A C # első verziója azonban csak körülbelül 10 évvel később érkezett meg. Még a C # fejlesztői sem gondolták, hogy ez a programozási nyelv egyszer bekerül az amúgy is elavult és nem használt rendszerbe.

Mitől specifikus a C #?

Ezt több lépés előzte meg. A C # elvileg másképp működik, mint a C vagy a C ++ programozási nyelv. Ezek a programozási nyelvek "hagyományosak" abban az értelemben, hogy a beléjük írt kódot a feldolgozás során közvetlenül a célprocesszor architektúrájának és az operációs rendszernek a gépi kódjává fordítják. Ezért, ha az x86 Windows programot C ++ kódból hozza létre, akkor nem futtatja ARM64 androidos telefonon.

A C # ebben a tekintetben inkább hasonlít a Java-ra vagy a Kotlinára. Amikor a kódot a C # számba fordítja, nem kap utasításokat valamilyen fizikai processzor "megértésére". Futtatásához virtuális processzorra van szükség. Ilyet nem lehet a boltban vásárolni. A virtuális processzor futásidejű környezet, amelyen keresztül az adott processzor és operációs rendszer képes végrehajtani a program szemantikáját C # nyelven.

Mely C # operációs rendszereket támogatják?

Ha Windows Vista vagy újabb, akkor már rendelkezik ezzel a virtuális processzorral. Ez az operációs rendszer része.

2014-ben a Microsoft bejelentette a .NET Framework nyílt forráskódú utódját .NET Core néven. 2016-ban kibővítette a "hivatalos" .NET-et más támogatott platformokkal: Linux és macOS. Ugyanakkor a forráskód megnyitása lehetővé tette, hogy bárki más operációs rendszerek és processzorok számára támogatást adjon.

A Microsoft megalapította a .NET Alapítványt is. Nem a Microsoft irányítja. A .NET Core-hoz kapcsolódó projekteket áthelyezték alatta, hogy a közösség ne érezze többé a platformot zártnak és egy céghez tartozónak. A .NET a lehető legtöbb eszközre és platformra szeretett volna kerülni.

Ami a C # és a Windows 3.11 kísérletemet illeti, a meglévő nyílt forráskódú .NET Core technológiát használtam. De azokat olyan formára kellett módosítanom, amelyet a Windows 3.11 is támogat. Ez a gyakorlatban nem nagyszerű. Nagyon sok parancsikont készítettem a prototípusban, így a Windows 3.11-en biztosan nem minden .NET.

Célom az volt, hogy kiderítsem a C # kód futtatásának valóban minimális követelményeit.

Hogyan jutott el kifejezetten a Windows 3.11-hez? Kihívásnak fogta fel?

A Windows 3.11 nem volt a cél az elején. Azzal kezdtem, hogy megpróbáltam meghatározni a C # kód futtatásához szükséges minimális követelményeket. Azonnal egyértelmű volt, hogy a minimális követelményeket a futási környezet határozza meg. A legegyszerűbb és legprimitívebb alkalmazásoknak is, amelyek csak számot vagy karakterláncot nyomtatnak, szükségük van erre a virtuális gépre, hogy megértsék az utasításokat.

Ebben a szakaszban segítettem magam egy Microsoft kísérleti projektben, amelyet szintén nyílt forráskódú licenc alatt publikáltak. Ez egy alternatív futási környezet. Nem az, amivel a .NET Core hivatalosan együttműködik.

Előnye, hogy a virtuális gép mellett tartalmaz egy másik fordítót is. Le tudja fordítani a C # kódot közvetlenül a kiválasztott hardverplatform és operációs rendszer "érthető" gépkódjává. Hasonló a gyakran fordított forráskódhoz C vagy C nyelven++.

A C # -be írt kódot ezután kétszer lefordítják. A futásidejű utasítások végrehajtják a virtuális processzort a programozó által írt C # programsorokból. Egy másik fordító ezeket a virtuális utasításokat gépi kódokká alakítja egy adott kiválasztott platform, például az x86 Windows számára. Laikus kifejezéssel élve lefordítja a számítógép fizikai processzora által értett "nyelvre".

És maga a .NET Core sem tudja ezt?

Lehetőség van egy "önálló alkalmazás" létrehozására is a .NET Core-ban. Megvalósítja a virtuális processzor megvalósítását egy adott operációs rendszer számára, és "hordozza a processzort". Ezért már nem igényel külön támogatást a .NET-hez az operációs rendszerben. Ennek a virtuális processzornak a megvalósítása azonban viszonylag kiterjedt.

A kísérleti projekt, amelyről beszélek, viszont ezt a környezetet kihagyja az összeállítás során. Mint mondtam, ehelyett az írott alkalmazást közvetlenül natív kódra fordítja a kiválasztott processzor számára.

A .NET futási idő kihagyásával a nyelv elveszíti egyik előnyét az olyan statikusan lefordított nyelvekkel szemben, mint a C és a C ++. Új programkód generálható a program futtatása során. Nos, nagyon jó kezdő lépésnek láttam. Sikerült kiküszöbölni az első "felesleges" komponenst az egész folyamatból, vagyis a virtuális gép és a futási környezet használatának feltételét.

Ez azonban nem volt elég?

Nem. Az igények minimalizálása érdekében tovább összpontosítottam a C # nyelv egyes funkcióit és futási környezetét. Az említett kísérleti projekt előnye éppen az, hogy a futási környezet egyes komponensei nem kötelezőek. A programozó "kattinthat" arra, amit ki akar zárni. Ez nem nagyon támogatott, de van, és működik.

Tehát egy teljesen egyszerű játékot készítettem ilyen kígyóval. Úgy terveztem, hogy a futásidejű környezet lehető legkevesebb összetevőjétől függjön, és feleslegeseket lecserélhetek.

Először a "szemétgyűjtővel" kezdtem foglalkozni, vagyis az automatizált memóriakezeléssel. Megint ez egy olyan terület, ahol a C # közelebb van a Java-hoz, mint a hagyományos C.

A normál C-ben a változó használata előtt a programozónak memóriaterületet kell kérnie hozzá, lefoglalva. Éppen ellenkezőleg, amikor már nincs rá szüksége, nem szabad megfeledkeznie a memória felszabadításáról. Nagyobb projekteknél ez óriási probléma, és a fejlesztő könnyen eltévedhet a memóriakezelésben. Ezután az alkalmazás feleslegesen sok erőforrást használ fel, összeomlik vagy más módon nem működik megfelelően.

Tehát hogyan működik a C #?

C # esetén a programozónak nem kell manuálisan kérnie és felszabadítania a memóriát. A futásidejű környezet (virtuális processzor) ezeket a feladatokat intelligensen és szükség szerint elvégzi. A fejlesztő azonban kevésbé ellenőrzi a rendszer erőforrásait. Maga a kód azonban sokkal kevésbé bonyolult, és problémák esetén könnyebben diagnosztizálható.

A "szemétgyűjtő" egy viszonylag bonyolult kódrészlet. Nyomon követi, amikor egy program utoljára elérte a memóriát, és így tovább. De lenyűgözött, mert elméletileg "el lehet dobni". Csak újra magammal kell kezelnem a memóriát.

Megcsináltam a program bemenetének és kimenetének rendszerével is, amelyet kicseréltem saját kis megvalósításommal. Fokozatosan mindent lecseréltem egyszerűbb újratelepítésekre, amelyek kevésbé függenek az operációs rendszertől.

Ennek eredményeként kaptam egy alkalmazást, amelynek kígyója C # -be volt írva, amely mindössze 8 kilobájt volt, és teljesen független a futási környezettől.

Mi volt az eredmény?

Így "játszottam" vele több hétvégén. Ennek eredményeként kaptam egy játékot azzal a kígyóval, amely C # -ba volt írva, amely csak 8 kilobájt volt, és teljesen független a futó környezettől. Az egész virtuális gép szükségtelenné vált. A forráskódom minden parancsát és bájtját közvetlenül lefordították és nyomon követték az eredményül kapott .EXE fájlban.

Készítettem kígyós játékot szöveges módhoz ("konzolos alkalmazás"). Ez nem volt bonyolult, mivel a legtöbb operációs rendszer, beleértve a Windows rendszert is, olvasási és írási funkcióval rendelkezik a konzolon. C # -ről is hívhatók. A probléma azonban az volt, hogy ezeket a szolgáltatásokat jóval a Windows 3.11 után adták hozzá a Windows rendszerhez.

Tehát a Windows 3.11-hez kellett igazítanom a céljaimat. A kígyóval való játék helyett inkább egy egyszerű szöveges üzenetet próbáltam megjeleníteni két gombbal. Ehhez azonban néhány kígyó építőelemet használtam. A legújabb Windows 10-en egy ilyen alkalmazás azonnal gond nélkül működött, de a régi Windows 3.11-tel még mindig nem volt szerencsém.

Nem volt probléma az alkalmazás natív kódra történő lefordításával?

Meg kellett küzdenem a kísérleti projekt korlátaival, amelyekkel a kezdetektől fogva dolgoztam. Csak 64 bites operációs rendszereken működik. Nem fog működni 32 vagy akár 16 bites rendszeren.

Itt egy történelmi érdekességre bukkantam. A Windows 3.11 16 bites operációs rendszer volt, de a következő 32 bites Windows 95 bevezetésével a Microsoft elérhetővé tette a Win32s nevű kis kiegészítést ehhez a régebbi rendszerhez.

A Win32s lehetővé tette néhány könnyű és kicsi 32 bites alkalmazás futtatását 16 bites Windows 3.11 rendszeren. Ezért nem a 64 bittől a 16-ig történő áttéréssel kellett foglalkoznom, hanem "csak" a 32. A Win32-ek nagyon jó alapként szolgáltak számomra, mert akkoriban támogatták és integrálták a különféle fejlesztői környezetekbe.

Mielőtt folytatnánk az utolsó lépést, jó megemlíteni, hogyan működik a programok natív kódra történő fordítása. A natív kód fordító úgynevezett "objektum fájlokat" generál. Ezek a fájlok tartalmazzák a program natív kódját, de nem futtathatók, mert nem teljesek. Hivatkozásokat tartalmaznak más objektumfájlokban definiált más szimbólumokra.

Futtatható fájl létrehozásához egy linker nevű eszközt használnak, amely több objektumfájlt egyesít egy futtatható egységben.

A kódomat egy 2020-as fordító segítségével objektumfájlokba állítottam össze. Ezután 1994-től összeköttem őket egy linkerrel.

Hogyan használta ezt a "köztes lépést"?

Az alkalmazásomat az említett kísérleti projekt segítségével objektumfájlokká fordítottam. A 32 bites kimenet megszerzése egy kísérleti fordítótól nem jelentett ilyen problémát, mert a .NET Core támogatja a 32 bites operációs rendszereket. Az alkalmazott kísérleti projekt a .NET Core alapú. A fennmaradó néhány apró részletet egy kísérleti fordítóba programoztam. Be is integráltam őket a projektbe, hogy mások számára elérhetővé tegyem őket.

Ezt követően linkerként használtam az 1994-ből származó link.exe fájlt, a programom primitív volt és függőségektől mentes, de mégis meglepődtem, hogy kompatibilis volt a régi linkerrel. A fájlformátum azonban azóta sem változott sokat, így a linkelőnek a legkisebb problémája sem volt vele. És mivel a Windows 3.11-gyel egy időben jött, a kódomat más objektumfájlokhoz kapcsolta, amelyek a megfelelő időben jöttek.

Az így kapott program továbbra is működik, és Windows 10 rendszeren futtatható. De működik a Windows 3.11-en is, amely ma már több mint 26 éves.

Később még a játékot is sikerült futtatnom MS-DOS 5-en.

Nem próbáltál "tovább" menni?

Később még az MS-DOS 5-en is sikerült futtatnom a játékot. De most nincs időm hasonló partikra. Akkor szülői szabadságon voltam, így kicsit több időm volt. Most a gyerek mellett a munkát is irányítanom kell.

Más 16 bites rendszerek vagy a Windows 3.11-nél régebbi platformok több munkát igényelnek, mint ahová hajlandó vagyok befektetni. A Windows 3.11-ben az előny a Win32s eszköz volt. Ellenkező esetben például magával a natív kódgenerátorral kellene foglalkoznom, és ez sokkal több munka lenne. Nem lehetetlen, csak nagyon időigényes.

Eközben a kísérleti .NET projekt egyik közreműködője átvette a játékomat, és minden operációs rendszer nélkül átdolgozta. A csapat valóban bebizonyította, hogy a C # felhasználható az operációs rendszerek maguk létrehozására is.