Google natív kliens
Játszottam egy kicsit a Google Native Client - egy böngésző plugin (támogatott a Firefox, az "Opera", "Safari" és a "Chrome" és a Windows platform, Mac és Linux x86, x86-64 és ARM).
Ez a plugin, amely képes végrehajtani a bináris (!) Kódot a böngészőben. Bizonyos értelemben ez olyan, mint az ActiveX. Írsz egy bináris kódot, fordítsd le a gcc speciális verziójába, majd egyszerűen beágyazd az EMBED címkét a böngészőbe.
Érdeklődtem, hogy a biztonságot hogyan tartják fenn. Lot kódot tilos (sőt, minden megengedett - ez a hatékony processzor, a többi kell menni a böngésző segítségével NPAPI vagy SRPC (Simple RPC)), de a fejlesztők a sok beszéd, amely lehetővé tette inline szerelvény.
A koporsó, ahogy kiderül, egyszerűen és meglehetősen szellemes. Először is, a fejlesztőnek tilos néhány konstrukciót használni, például INT (megszakítási hívás) és mások. Másodszor, az átmeneti parancsok módosulnak, és ez a legérdekesebb.
Nem tudom, hiszen az ARM processzorok és x86 parancsok különböző hosszúságú, bármilyen «PUSH AX» foglal byte «MOV AL, 41" - két,«MOV AX, [BP + 8]”- három, és így tovább. Ha egy átmenet nem az első byte a csapat (például a második byte a parancs «MOV AL, 41„), úgy tűnik, hogy a maradék (esetleg bájtok megy tovább) is jelent valamit (abban az esetben, «MOV AL, 41 "második bájt lesz" 41 ", ez az" INC CX "parancs.
Ez lehetővé teszi a parancs belsejében tiltott parancsok maszkolását és végrehajtását, így az átmenet nem az első bájtra történik. Hogyan védi meg tőlünk a Google Native Client? Nagyon egyszerű.
A második veszély a kód az adatokban, mert szinte minden bájtsor egyfajta gépi kód, így könnyen elrejtheti a kódot a szövegben, majd ezt a szöveget. Nyilvánvaló, hogy az átmenetek korlátozásának képességével ez a probléma könnyen megoldható - a kódot és az adatokat a szegmensek különböző regisztereire terjesztjük, és nem adjuk át a kódot az adatoknak. Nincs semmi bonyolult, az első eset érdekesebb volt.
Érdekes, hogy a kód, amely ellenőrzi a biztonságot és végrehajtja az SRPC-t, kiderült, hogy nagyon kicsi, a videó a YouTube-on, a fejlesztő mond valamit 6000 sort, majd körülbelül 6000 byte. Mindenesetre mindkettő egy kicsit. Ott (a videóban) megjelent a Ruby-tolmács a böngészőben. Érdekes, de nem érdekes, hogy a kódot a C (vagy a C ++-ban, nem számít) nagyon kicsit változtatni kellett ahhoz, hogy újra fordítsák a Google natív kódját.
Azt hiszem, ez egy érdekes projekt.
Ez nem egy szabvány, hanem egy tervezet. Amennyire én tudom, az embed tag nem szerepel a HTML szabványban. Ez csak egy másik, nem skype / mozil
A VIDEO nem is szabvány, azonban minden modern böngészőben van. Nos, nem csoda, hogy vannak távoli és közeli csaták. A processzor gyorsítótár is, azt hiszem, nem fogja elfogadni a kódkötetek súrlódását szinte nagyságrenddel.
Bármi is volt, nincs mit vitatkozni, a fejlesztők már bejelentették a számokat. Nézd. szinte az összes C # kód Silverlightben használható. És mi a C-kód része a NPAPI vagy az SRPC-n keresztül? Számomra úgy tűnik, hogy még sok mindent meg kell újítani az új platformra
Ez a lényeg, hogy a változások minimálisak. Ezt megerősíti például a Quake for Native Client. Még mindig pletykáknak nevezném. Ismét furcsa, hogy a Microsoftról szóló pletyka az egyetlen olyan eset, amikor az IA-128-at említik.
Nos, nem érdekel. Mindenesetre a 128 bites átmenetet az ilyen fejlesztési ütemekkel fogják megvalósítani a következő 5-7 évben.