Google activeert Native Client in Chrome 14

Google heeft in de bètaversie van Chrome 14 de Native Client-feature geactiveerd waardoor native applicaties binnen Chrome kunnen draaien. Ook ondersteunt de browser OS X Lion en de op Javascript gebaseerde Web Audio-api.

Met Native Client kunnen binnen de browser naast webapplicaties ook applicaties draaien die voor een specifiek platform zijn geschreven. Volgens Google is zijn 'application programming interface' vooral geschikt voor applicaties die in C en C++ zijn geschreven. De code wordt binnen de sandbox-omgeving van Chrome vertaald naar de html 5-api van Chrome, een mechanisme dat door Google 'Pepper' is gedoopt.

Google hoopt dat ontwikkelaars met Native Client aan de slag gaan om zo veeleisende applicaties en games aan te passen zodat deze binnen Chrome draaien. Dit is voor de zoekgigant met name belangrijk voor Chrome OS, een besturingssysteem dat geheel opgebouwd is rondom de gelijknamige webbrowser.

De Google-ontwikkelaars experimenteren al sinds 2008 met Native Client. Na de nodige aanpassingen worden ook 64bit-besturingssystemen ondersteund, terwijl experimentele ondersteuning voor ARM-computers en -mobieltjes in de maak is. Voorlopig is Native Client alleen beschikbaar voor applicaties die in de Chrome Web Store zijn opgenomen, maar Google wil de mogelijkheden in de nabije toekomst vergroten.

Chrome 14 krijgt ook ondersteuning voor de Web Audio-api. Via deze api kunnen webontwikkelaars geluid manipuleren, bijvoorbeeld door het toevoegen van 3d-effecten. Ook biedt deze api volgens Google meer mogelijkheden voor spelontwikkelaars.

Mac-gebruikers die inmiddels OS X Lion geïnstalleerd hebben, kunnen binnen Chrome 14 meer vingerbewegingen gebruiken. Ook is een printpreview beschikbaar, maar de full screen-modus van Lion wordt nog niet ondersteund.

Reacties (45)

mendel129 15 augustus 2011 12:21

C++ naar html5 dat terug naar cpp ofzo gaat... WTF?
En dat met een vertragingsfactor van 500% zeker?

(Doet me denken aan die mopjes met xzibit-mopjes

)

kidde @mendel129 • 15 augustus 2011 12:48

Natuurlijk niet, bij conversie is er toch geen sprake van 'native' meer!

Het hele idee is dat er drie delen zijn:
-Native module in machine code, een soort uitvoerbaar .exe bestandje (.nexe wordt 't), resultaat van compileren van C naar machine code.
-API 'brug', genaamd Pepper: API in C gemaakt door Google zodat de .nexe de browser interface kan aanspreken,
-Browser interface, alleen deze is gemaakt in HTML / JS.

Natuurlijk wil de .nexe misschien met de Javascript communiceren, en daarvoor is dus de Pepper-API.

@hAl: Omdat je ze kan combineren, HTML/JS voor de interface en native voor rekenintensieve taken. Verder beweert Google dat andere browsers dezelfde technologie kunnen gebruiken. Maar uw strijd voor open standaarden en cross-browser technologie valt natuurlijk van harte toe te juigen, dat is in het verleden anders geweest;) Ik ben hier niet meer nodig merk ik al.

[Reactie gewijzigd door kidde op 25 juli 2024 08:08]

Anoniem: 80466 @kidde • 15 augustus 2011 13:16

Waarom zou iemand een native client bouwen die alleen werkt in chrome en met beperkingen van een html5 API.
Je kunt beter kiezen om of een native app of een HTML 5 apps te bouwen.
Dan heb je of een snelle app of een platform onafhankelijke app.

Beter dan een soort van afzonderlijke half snelle app die afhankelijk is van de html5 beperkingen van een specifieke chrome browser API.

Bosmonster @Anoniem: 80466 • 15 augustus 2011 13:28

Je moet het voordeel vooral zien in combinatie met canvas. Zo kun je eenvoudiger bestaande software ombouwen tot canvas-apps, zonder deze helemaal te moeten herschrijven in interpreted javascript.

roy-t @Bosmonster • 15 augustus 2011 14:40

Ik snap er niets van, als ik een programma wil maken of verbouwen zodat het een HTML5 gebaseerde interface heeft, dan zorg ik er toch gewoon voor dat mijn programma een mini webserver draait en HTML5 uitspuugt, dan werkt het tenminste *overal en kun je zelfs nog over het netwerk werken. (Er zijn zat mini servers die je zo in je programma kan integreren).

Wat is nu het nut van alleen Chrome?

.oisyn Moderator Devschuur® @roy-t • 15 augustus 2011 15:40

Wat heb je aan een HTML interface voor je game?

roy-t @.oisyn • 15 augustus 2011 19:41

waar zie jij game?

.oisyn Moderator Devschuur® @roy-t • 16 augustus 2011 11:52

Ik geef een voorbeeld van een programma dat niets heeft aan een HTML interface

mxcreep @roy-t • 15 augustus 2011 16:39

Je hebt helemaal geen webserver nodig, browser engine kan ook gewoon html laden uit een string of uit een statische file die je genereert. QT Webkit bijvoorbeeld is ook zo te gebruiken...

MSalters @Anoniem: 80466 • 15 augustus 2011 14:57

Waarom? Kijk naar een programma als TomTom HOME; dat is eenzelfde HTML5/C++ hybride. Weliswaar op basis van FireFox/XULRunner in plaats van Chrome/NaCl, maar op architectuurnivo is het vergelijkbaar.

De technische voordelen zijn o.a. een standaard en portable GUI, standaard resource management, en eenvoudige web update voor content.

Het grote voordeel van NaCl boven Chrome lijkt dat Google iets meer verstand heeft van interface design; XulRunner is echt niet mooi.

Woy Moderator PRG/SEA @mendel129 • 15 augustus 2011 12:43

Dat gaat alleen over de API, de programmatuur draait gewoon als native applicatie, maar dan in een sandbox. Voor de presentatie en dergelijke kan dan gebruik gemaakt worden van de API

Deddiekoel 15 augustus 2011 12:31

Ik vind dit een rare stap. Doet me sterk aan het verfoeide ActiveX van MS denken.
Het strookt in mijn optiek ook niet met Google's 100% Web gedachte...

marnix.klooster @Deddiekoel • 15 augustus 2011 13:31

Doet me sterk aan het verfoeide ActiveX van MS denken.

ActiveX en Native Client hebben heel weinig met elkaar te maken.

Ik baseer dit op een artikel hierover, geschreven door het NaCl team, in Communications of the ACM (ACM lidmaatschap vereist): Native Client: A Sandbox for Portable, Untrusted x86 Native Code.

Een paar citaten:

"Each component runs in its own private address space. Inter-component communication is based on Native Client's reliable datagram service, the IMC (Inter-Module Communications). For communications between the browser and a NaCl module, Native Client provides two options: a Simple Remote Procedure Call (SRPC) facility, and NPAPI, both implemented on top of the IMC. The IMC also provides shared memory segments and shared synchronization objects, intended to avoid messaging overhead for high-volume or high-frequency communications.

The NaCl module also has access to a "service runtime" interface, providing for memory management operations, thread creation, and other system services. This interface is analogous to the system call interface of a conventional operating system."

"The Native Client architecture was designed to support pure computation. It is not appropriate for modules requiring process creation, direct file system access, or unrestricted access to the network. Trusted facilities such as storage should generally be implemented outside of Native Client, encouraging simplicity and robustness of the individual components and enforcing stricter isolation and scrutiny of all components. This design choice echoes microkernel operating system design."

"Perhaps the most prevalent use of native code in Web content is via Microsoft's ActiveX. ActiveX controls rely on a trust model to provide security, with controls cryptographically signed using Microsoft's proprietary Authenticode system, and only permitted to run once a user has indicated they trust the publisher. This dependency on the user making prudent trust decisions is commonly exploited. ActiveX provides no guarantee that a trusted control is safe. Even when the control itself is not inherently malicious, defects in the control can be exploited, often permitting execution of arbitrary code. In contrast, Native Client is designed to prevent such exploitation, even for flawed NaCl modules."

[Reactie gewijzigd door marnix.klooster op 25 juli 2024 08:08]

sokar24 @Deddiekoel • 15 augustus 2011 12:37

Hoezo een rare stap? In het artikel staat toch de rede waarom google dit doet? Ze willen ervoor zorgen dat Chrome OS applicaties niet beperkt blijven tot simpele plugins maar de mogelijkheid bieden om volwaardige software te draaien in de browser.

Google hoopt dat ontwikkelaars met Native Client aan de slag gaan om zo veeleisende applicaties en games aan te passen zodat deze binnen Chrome draait. Dit is voor de zoekgigant met name belangrijk voor Chrome OS, een besturingssysteem dat geheel opgebouwd is rondom de gelijknamige webbrowser.

Edit; Er staat een typo in het artikel. het moet zijn "binnen Chrome draaien"

[Reactie gewijzigd door sokar24 op 25 juli 2024 08:08]

mashell @sokar24 • 16 augustus 2011 17:19

maar de mogelijkheid bieden om volwaardige software te draaien in de browser

Klinkt als de natte droom van elke malware maker. Dit is in beginsel een gevaarlijk iets net als ActiveX dat is.

marnix.klooster @mashell • 19 augustus 2011 15:57

Nee, ActiveX en NaCl zijn twee heel verschillende technieken. Zie mijn eerdere reactie.

Blokker_1999

Browsers
Google

@Deddiekoel • 15 augustus 2011 12:38

Niet alleen dat, met ajax en html5 hebben ontwikkelaars vandaag al veel mogelijheden om apps te laten draaien in de browser en als dat onvoldoende is zijn er ook vandaag al mogelijkheden om native te draaien. Kijk bijv. maar naar Quake live.

Floor @Deddiekoel • 15 augustus 2011 12:40

Juist wel. Het staat zelfs letterlijk in het artikel.

Dit is voor de zoekgigant met name belangrijk voor Chrome OS, een besturingssysteem dat geheel opgebouwd is rondom de gelijknamige webbrowser.

Nu heb je:
- Hardware
- OS
- Browser
- Webapplicatie

In Chrome OS hebben ze de Browser en OS ineen geschoven. Je zal toch zaken lokaal moeten blijven afhandelen. C en C++ zijn krachtige talen met goede debugging, zeker in vergelijking met PHP.
Eerlijk gezegd vind ik dit een fantastische ontwikkeling. Ik hoop ook dat Microsoft en de andere OS aanbieders hetzelfde pad gaan volgen. Het huidige model is gewoon voor de toekomst een achterhaald idee.
Hier werken we al bijna volledig webbased. Ideaal. Ik wil niet terug naar de oude situatie. We hebben (veel) minder downtime dan het vorige bedrijf waar ik werkte (en nog steeds veel contact mee heb). Nee, dit is zeker logisch en ik schat in zelfs een kritische succes factor voor ChromeOS.
_{edit: nog wat tekst toegevoegd}

[Reactie gewijzigd door Floor op 25 juli 2024 08:08]

Dreamvoid @Deddiekoel • 15 augustus 2011 13:00

Doet me sterk aan het verfoeide ActiveX van MS denken.

De implementatie van ActiveX was natuurlijk beroerd, maar in feite is het de directe voorloper van de huidige RIA technologieen als Flash, JavaFX, Silverlight en HTML5. Het is weer een in het rijtje van Microsoft technologieen die uiteindelijk door iemand anders wel groot gemaakt worden (Channels, touchstreen smartphones, tablets, Terraserver, Surface, etc).

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 08:08]

joopykoopy 15 augustus 2011 12:22

Hmm, leuke verbetering. Zou dit in theorie kunnen betekenen dat we alles uit windows kunnen gaan slopen, en alles in chrome kunnen draaien? Ik denk alleen dat het vertalen wat CPU kost. We zullen zien, ik vind het een leuke verbetering

Jegorex @joopykoopy • 15 augustus 2011 12:25

Zou dit in theorie kunnen betekenen dat we alles uit windows kunnen gaan slopen, en alles in chrome kunnen draaien?

Dat heeft Google al gedaan, ze noemen het Chrome OS

TvdW @Jegorex • 15 augustus 2011 13:41

Chrome OS had ooit als voordeel dat het gewoon een webbrowser was en daardoor alle webapplicaties kon draaien. Wat we met de komst van deze Native Client gaan krijgen is dat er OS-specifieke (browser, eigenlijk) webapplicaties komen waardoor we weer terug zijn bij het oorspronkelijke probleem: het werkt niet op alle computers.

Ik vind dit dan ook een slechte "vooruitgang".

-edit-
Zie overigens ook Flash, Java en Silverlight. Deze worden ook steeds meer door developers afgeschoten omdat het niet overal werkt. Native Client is een stap achteruit.

[Reactie gewijzigd door TvdW op 25 juli 2024 08:08]

RielN @TvdW • 15 augustus 2011 22:51

Dit is niet waar, want Chrome werkt op mac, windows en linux.

'En op ChromeOS', om het simpel te zeggen.

Je native client apps draaien in die browser. Of dat nu je chromebook is of niet. Google wil ons IN de browser houden en dit is voor hun doelstellingen een LEAP voorwaarts!

[Reactie gewijzigd door RielN op 25 juli 2024 08:08]

TvdW @RielN • 16 augustus 2011 02:21

Da's niet wat ik bedoel. Ik bedoel dat ik geen Chrome wil gebruiken, net als ik geen Windows wil gebruiken. Het is een stap terug door te zeggen dat een specifieke applicatie slechts in één browser werkt.

RielN @TvdW • 16 augustus 2011 10:54

Daar heb je wel een punt, maar In de praktijk is het wel anders: je applicatie werkt op veel meer apparaten. En ja, het is een nieuw OS waar dus nieuwe applicaties voor gemaakt worden. Alleen dit OS draait eenvoudig op alle andere OS-sen, dat is iets wat nog niet bestond. Dat je native apps maakt voor een OS is al sinds jaar en dag zo...toch?

Google heeft verschillende redenen om een ChromeOS te maken. Ik sta hier achter (geen onderhoud, gemak, veiligheid) etc. Ze houden deze strategie vast. Ik gebruik zelf een Chromebook en ervaar de voordelen wel. Wanneer ik deze Native Client applicaties verder overal kan gebruiken waar ik wil (op vakantie, op mijn chromebook, op mijn tablet etc) is dat net erg handig.

En het kan, indien de applicaties goed zijn, een extra boost zijn om Chrome en ChromeOS meer te gaan gebruiken: je hebt een goed aanbod nodig. Door middel van mogelijkheden als deze werkt Google hieraan.

Anoniem: 35352 @TvdW • 16 augustus 2011 00:09

Hangt er van af hoe het gebruikt wordt: is dit een standaard API voor OEM's & solution providers om bepaalde mogelijkheden van een machine beschikbaar te stellen in een GUI die 100% op webtechnologie gebaseerd is, of is het de bedoeling dat willekeurige 3rd parties dergelijke toepassingen op je Chrome OS netbook kunnen droppen?

Iblies @joopykoopy • 15 augustus 2011 12:27

Vraag ik me ook af.
Chrome draait op zowel x86 als op ARM. Twee verschillende platformen.

MSalters @Iblies • 15 augustus 2011 14:58

Ja, en? 't Draait zelfs op x86-64, dus je kunt ook zeggen dat het op 3 platformen draait.

HerrPino @joopykoopy • 15 augustus 2011 12:34

Idd ... alleen ben ik zelf bang dat dit een beetje vragen om problemen is. ActiveX is ook een bron van ellende en werd destijds ook veilig geacht.

Liever had ik gezien Google Java of .NET zien ondersteunen. 2 bestaande standaarden die feitelijk hetzelfde doen en niet browser afhankelijk zijn.

tweakerbee @HerrPino • 15 augustus 2011 13:09

Google en Java. Alsof ze nog niet genoeg rechtszaken met Oracle aan het voeren zijn...

90710 @HerrPino • 15 augustus 2011 13:13

.NET is van Microsoft. Google is niet zo goede vriendjes met MS.

Anoniem: 415197 @joopykoopy • 15 augustus 2011 12:53

Ja zou leuk zijn als we zelfs de browser in NaCl konden draaien

Einde compatibility headaches.

bozotheclown 15 augustus 2011 12:37

Ik heb 14.0.835.35 op mijn Lion Macs/Macbooks in gebruik en de full screen mode werkt gewoon en goed ook.

Als met wordt nog niet ondersteunt bedoeld wordt dat er geen support is dan vraag ik me af welk helder licht denkt dat er op een beta überhaupt support zit voor zover er bij Chrome sprake is van support;)

teek2

@bozotheclown • 15 augustus 2011 12:50

Dus full screen creeert een nieuwe desktop? En als je met de muis naar boven gaat komt de blauwe minimize button te voorschijn?

BobOldeHampsink @teek2 • 15 augustus 2011 13:56

In Chrome 15 werkt full screen native ja!

Wolfos 15 augustus 2011 12:39

Je kan hem sowieso al activeren door gewoon "about:plugins" te tikken en dan Chrome NaCI te activeren.

UmbraDei @Wolfos • 15 augustus 2011 12:42

Ja, maar in de nieuwe versie is het hernoemt naar 'Native Client' en staat het dus standaard enabled.

Ik vond persoonlijk het chemische grapje ook wat leuker, maar NaCl is niet voor iedereen even begrijpbaar

Anoniem: 387064 @UmbraDei • 15 augustus 2011 12:47

keukenzout

Anoniem: 415197 15 augustus 2011 12:49

Lijkt me handiger als ze de graphics API zo simpel hadden gehouden als OpenGL. Dan hadden we onze eigen browser kunnen implementeren in c++ zonder afhankelijk te zijn van webkit (of we hadden een open-source browser kunnen gebruiken).

Voordeel: als microsoft dan ook NaCl implementeert, dan werkt het tenminste overal hetzelfde, en zijn webdevelopers eindelijk verlost van compatibility ellende.

Maar ja, toch een leuke ontwikkeling dit.

danielsrje @Anoniem: 415197 • 15 augustus 2011 18:14

Stel dat deze architectuur echt goed aan slaat, komen Oracle en Microsoft (en zo) direct met precies-hetzelfde-maar-dan-anders techniek, die _bijna_ helemaal aan sluit. En noemen dat dan NaCl 1.1

Maar goed. Ik vind het hierboven niet helemaal eerlijk om de stokoude ActiveX techniek 'negatief' naar Microsoft te rekenen: het stamt uit een tijd dat nog niet iedereen (of eigenlijk: bijna niemand) permanent met Internet verbonden was en de computers nog nét niet de rekenkracht hadden van een huidige smartphone...