mboost-dp1
Suk.
Det er ikke C++ men maskinkode (svjv pt. x86 og "ARM") der køres "direkte" i en sandbox. Der er altså ikke nogen C++-fortolker i browseren -.- Derudover er C og C++ ikke det samme, selvom C++ er nogenlunde bagudkompatibel med C.
Derudover er jeg ret sikker på at det ikke udelukkende er for C og C++.
Rettelse indsendt.
#3
At gå tilbage til CPU-specifik kode gør det på ingen måde bedre.
Det er ikke C++ men maskinkode (svjv pt. x86 og "ARM") der køres "direkte" i en sandbox. Der er altså ikke nogen C++-fortolker i browseren -.- Derudover er C og C++ ikke det samme, selvom C++ er nogenlunde bagudkompatibel med C.
Derudover er jeg ret sikker på at det ikke udelukkende er for C og C++.
Rettelse indsendt.
#3
At gå tilbage til CPU-specifik kode gør det på ingen måde bedre.
Det er ikke til webprogrammering.-N- (3) skrev:Det lyder som et af de bedste tiltag siden WWW, webprogrammering er simpelthen den største gang kaos af forskellige typer af kode, måske dette tiltag kan gøre op med den tradition og lave én hjemmeside, ét sprog.
Det er for at du kan lave apps/spil til Chrome. Så du kan bruge Chrome i stedet for dit OS. Det må være mest målrettet Netbooks.
-N- (3) skrev:Det lyder som et af de bedste tiltag siden WWW, webprogrammering er simpelthen den største gang kaos af forskellige typer af kode, måske dette tiltag kan gøre op med den tradition og lave én hjemmeside, ét sprog.
Og det sprog er så lige x86 eller x64 maskinkode; jeg ser det som et stort tilbageskridt hvis det er tænkt til generel brug. Hvis det mere er til Chrome-specifikke apps/spil etc. er det vel fint.
Men det er godt nok den forkerte vej, mens verden ellers går mod managed sprog og maskinneutral kode (som JavaScript, .NET, diverse scriptsprog etc.)
Assembler direkte i browseren... bare tanken får mig til at krølle tæer.
Ikke at jeg har noget imod maskinkode (som jeg faktisk har kodet i i årevis), men det er lidt vanvittigt at lave support for det i en internet browser. Må lige læse nærmere om det her når jeg kommer hjem til min egen computer, og har bedre tid...
Ikke at jeg har noget imod maskinkode (som jeg faktisk har kodet i i årevis), men det er lidt vanvittigt at lave support for det i en internet browser. Må lige læse nærmere om det her når jeg kommer hjem til min egen computer, og har bedre tid...
tentakkelmonster (9) skrev:Assembler direkte i browseren... bare tanken får mig til at krølle tæer. Ikke at jeg har noget imod maskinkode (som jeg faktisk har kodet i i årevis)...
Så undrer det mig, at du sidestiller assemblersprog med maskinkode. Assemblersprog er lige et niveau over maskinkode, går jeg ud fra du godt ved???
#4+8 Når det skal afvikles i browseren er det vel ikke et tilbageskridt, og det bliver vel ikke OS el. CPU specifikt.
Der står jo, at den har en speciel kompiler.
Hvis det er rettet til netbooks som i fremtiden både vil være risc og x86, så er tanken vil netop, at det skal være CPU og OS uafhængigt.
Der står jo, at den har en speciel kompiler.
Hvis det er rettet til netbooks som i fremtiden både vil være risc og x86, så er tanken vil netop, at det skal være CPU og OS uafhængigt.
http://code.google.com/chrome/nativeclient/docs/te...
Native Client modules are operating system independent, but they are not (yet) processor independent. Therefore, you must compile separate versions of a Native Client module for x86-32-bit, x86-64-bit, and other instruction sets.
Native Client modules are operating system independent, but they are not (yet) processor independent. Therefore, you must compile separate versions of a Native Client module for x86-32-bit, x86-64-bit, and other instruction sets.
Jeg har aldrig kigget på koden, men så vidt jeg ved er den første validering af koden meget lig den der foretages når java byte code indlæses i en VM.
Groft sagt har man defineret et instruktionssæt som er en delmængde af IA32 eller AMD64 instruktionssættet.
Nogle instruktioner er ufarlige og kan uden videre tillades. Andre er altid farlige og tillades overhovedet ikke.
Tilbage er nogle få problematiske instruktioner, som kan være farlige afhængige af kontekst. Man kan ikke bare tillade dem, og på den anden side kan man heller ikke helt undvære dem.
Der har man så defineret en enkelt ny instruktion som består af en kombination af to native instruktioner hvoraf den ene ikke er ufarlig i sig selv.
Det vil sige at kodevalideringen ser dette som en enkelt ufarlig instruktion. Men CPUen vil afvikle det som to instruktioner.
I princippet giver denne validering i sig selv altså samme sikkerhed som den validering der foregår af java kode. En fejl i validering af java byte code kunne tillade kode at beskadige JVM datastrukturerne, og koden kan dermed overtage kontrollen over JVM. En fejl i valideringen af NaCl kode kunne tillade kode at afvikle usikre instruktioner og på den måde bryde ud af det første niveau af sandkasse.
Det vil sige at sikkerhedsmæssigt NaCl og JVM instruktionssættene altså lige gode. På performance har NaCl en fordel. På fleksibilitet og portabilitet har JVM en fordel. Til gengæld skulle C og C++ compilerne gøre det muligt at compilere eksisterende kildekode og bruge det i NaCl.
Man kan også compilere andre sprog til NaCl eller for den sags skyld skrive maskinkode direkte. Man skal blot vide hvad valideringen tillader.
Groft sagt har man defineret et instruktionssæt som er en delmængde af IA32 eller AMD64 instruktionssættet.
Nogle instruktioner er ufarlige og kan uden videre tillades. Andre er altid farlige og tillades overhovedet ikke.
Tilbage er nogle få problematiske instruktioner, som kan være farlige afhængige af kontekst. Man kan ikke bare tillade dem, og på den anden side kan man heller ikke helt undvære dem.
Der har man så defineret en enkelt ny instruktion som består af en kombination af to native instruktioner hvoraf den ene ikke er ufarlig i sig selv.
Det vil sige at kodevalideringen ser dette som en enkelt ufarlig instruktion. Men CPUen vil afvikle det som to instruktioner.
I princippet giver denne validering i sig selv altså samme sikkerhed som den validering der foregår af java kode. En fejl i validering af java byte code kunne tillade kode at beskadige JVM datastrukturerne, og koden kan dermed overtage kontrollen over JVM. En fejl i valideringen af NaCl kode kunne tillade kode at afvikle usikre instruktioner og på den måde bryde ud af det første niveau af sandkasse.
Det vil sige at sikkerhedsmæssigt NaCl og JVM instruktionssættene altså lige gode. På performance har NaCl en fordel. På fleksibilitet og portabilitet har JVM en fordel. Til gengæld skulle C og C++ compilerne gøre det muligt at compilere eksisterende kildekode og bruge det i NaCl.
Man kan også compilere andre sprog til NaCl eller for den sags skyld skrive maskinkode direkte. Man skal blot vide hvad valideringen tillader.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund