Natywny klient Google

„Google NaCl” przekierowuje tutaj. Aby zapoznać się z biblioteką Networking and Cryptography, patrz NaCl (oprogramowanie) .

Natywny klient Google
Deweloperzy Google , inne
Pierwsze wydanie 16 września 2011 ; 11 lat temu ( 16.09.2011 )
Wersja stabilna
SDK: Pepper 45 / 10 lipca 2015 ; 7 lat temu ( 10.07.2015 )

Klienci: tak samo jak Google Chrome

Magazyn
Napisane w C , C++
System operacyjny Windows , Linux , macOS , ChromeOS
Platforma x86 , ARM , MIPS
Następca WebAssembly
Typ Piaskownica w przeglądarkach internetowych dla kodu natywnego
Licencja Nowy BSD
Strona internetowa programista .chrome .com /docs /klient-natywny / Edit this at Wikidata

Google Native Client ( NaCl ) to technologia piaskownicy służąca do uruchamiania podzbioru natywnego kodu Intel x86 , ARM lub MIPS albo przenośnego pliku wykonywalnego w piaskownicy. Umożliwia bezpieczne uruchamianie natywnego kodu z przeglądarki internetowej niezależnie od systemu operacyjnego użytkownika , dzięki czemu aplikacje internetowe działają z prędkością zbliżoną do natywnej, co jest zgodne z planami Google dotyczącymi systemu operacyjnego Chrome . Może być również używany do zabezpieczania wtyczek przeglądarki oraz części innych aplikacji lub pełne aplikacje, takie jak ZeroVM .

Aby zademonstrować gotowość technologii, 9 grudnia 2011 r. Firma Google ogłosiła dostępność kilku nowych wersji gier znanych tylko z przeglądarki Chrome , w tym Bastion ( nieobsługiwany już w Chrome Web Store ). NaCl obsługuje akcelerację sprzętową grafiki 3D (przez OpenGL ES 2.0), lokalne przechowywanie plików w piaskownicy, dynamiczne ładowanie , tryb pełnoekranowy i mysz schwytać. Były też plany udostępnienia NaCl na urządzeniach przenośnych.

Portable Native Client (PNaCl) to wersja niezależna od architektury. Aplikacje PNaCl są kompilowane z wyprzedzeniem . PNaCl jest zalecany zamiast NaCl w większości przypadków użycia. Ogólna koncepcja NaCl (uruchamianie natywnego kodu w przeglądarce internetowej) została już wcześniej zaimplementowana w ActiveX , który, będąc nadal w użyciu, ma pełny dostęp do systemu (dysk, pamięć, interfejs użytkownika, rejestr itp.). Native Client unika tego problemu, używając piaskownicy.

Alternatywą Mozilli był asm.js , który umożliwia również kompilowanie aplikacji napisanych w C lub C++ do uruchamiania w przeglądarce, a także obsługuje kompilację z wyprzedzeniem, ale jest podzbiorem JavaScript, a zatem jest wstecznie kompatybilny z przeglądarkami, które nie wspieraj go bezpośrednio.

W dniu 12 października 2016 r. Komentarz do narzędzia do śledzenia problemów z Chromium wskazywał, że zespoły Google Pepper i Native Client zostały pozbawione personelu. W dniu 30 maja 2017 r. Google ogłosił wycofanie PNaCl na rzecz WebAssembly . Chociaż początkowo Google planowało usunąć PNaCl w pierwszym kwartale 2018 r., a później w drugim kwartale 2019 r., zostało ono usunięte w czerwcu 2022 r. (wraz z aplikacjami Chrome ).

Przegląd

Native Client to projekt typu open source rozwijany przez Google . Do tej pory Quake , XaoS , Battle for Wesnoth , Doom , Lara Croft and the Guardian of Light , From Dust i MAME , a także system przetwarzania dźwięku Csound zostały przeniesione na Native Client. Native Client został udostępniony w przeglądarce Google Chrome przeglądarka internetowa od wersji 14 i jest domyślnie włączona od wersji 31, kiedy to został wydany Portable Native Client (PNaCl, wymawiane: szczyt).

Implementacja ARM została wydana w marcu 2010 r. Obsługiwane są również x86-64 , IA-32 i MIPS .

Aby przenośnie uruchomić aplikację pod PNaCl, należy ją skompilować do niezależnego od architektury i stabilnego podzbioru kodu bajtowego pośredniej reprezentacji LLVM . Pliki wykonywalne nazywane są plikami wykonywalnymi PNaCl (pexy). Łańcuch narzędzi PNaCl tworzy pliki .pexe; Pliki NaCl Toolchain .nexe. Magiczna liczba plików .nexe to 0x7F 'E' 'L' 'F', czyli ELF . W przeglądarce Chrome są one tłumaczone na pliki wykonywalne specyficzne dla architektury, dzięki czemu można je uruchomić.

NaCl wykorzystuje wykrywanie błędów oprogramowania i izolację do piaskownicy na x86-64 i ARM. Implementacja Native Client x86-32 wyróżnia się nowatorską metodą piaskownicy, która wykorzystuje rzadko używaną funkcję segmentacji architektury x86 . Klient natywny konfiguruje segmenty x86, aby ograniczyć zakres pamięci, do którego może uzyskać dostęp kod piaskownicy. Używa weryfikatora kodu, aby zapobiec użyciu niebezpiecznych instrukcji, takich jak te, które wykonują wywołania systemowe. Aby zapobiec przeskakiwaniu kodu do niebezpiecznej instrukcji ukrytej w środku bezpiecznej instrukcji, Native Client wymaga, aby wszystkie pośrednie skoki były skokami do początku 32-bajtowych wyrównanych bloków, a instrukcje nie mogą przekraczać tych bloków. Z powodu tych ograniczeń kod C i C++ musi zostać ponownie skompilowany, aby działał w Native Client, który zapewnia dostosowane wersje zestawu narzędzi GNU , w szczególności GNU Compiler Collection (GCC), GNU Binutils i LLVM .

Native Client jest licencjonowany w stylu licencji BSD .

Native Client używa Newlib jako swojej biblioteki C , ale dostępny jest również port GNU C Library (GNU libc).

Pieprz

Zobacz też: NPAPI § PPAPI

NaCl oznacza chlorek sodu , zwykłą sól kuchenną ; jako gra słów używano również nazwy pieprz . Pepper API to wieloplatformowy interfejs API typu open source do tworzenia modułów Native Client. Pepper Plugin API lub PPAPI to wieloplatformowy interfejs API dla wtyczek do przeglądarek internetowych zabezpieczonych przez klienta natywnego, najpierw oparty na NPAPI firmy Netscape , a następnie przepisany od podstaw. Został użyty w Chromium i Google Chrome , aby włączyć wersję PPAPI Adobe Flash i wbudowaną przeglądarkę plików PDF .

PPAPI

W dniu 12 sierpnia 2009 r. Strona w Google Code wprowadziła nowy projekt, Pepper, i powiązany Pepper Plugin API (PPAPI), „zestaw modyfikacji NPAPI, aby wtyczki były bardziej przenośne i bezpieczniejsze”. To rozszerzenie zostało zaprojektowane specjalnie w celu ułatwienia implementacji wykonywania wtyczek poza procesem . Ponadto celem projektu jest zapewnienie ram do tworzenia wtyczek w pełni międzyplatformowych. Rozważane tematy obejmują:

  • Jednolita semantyka dla NPAPI we wszystkich przeglądarkach.
  • Wykonywanie w oddzielnym procesie od przeglądarki renderującej.
  • Standaryzuj renderowanie za pomocą procesu tworzenia w przeglądarce.
  • Definiowanie zdarzeń standaryzowanych i funkcji rastrowania 2D.
  • Wstępna próba udostępnienia grafiki 3D.
  • Rejestr wtyczek.

Pepper API obsługuje również gamepady (wersja 19) i WebSockets (wersja 18).

Na dzień 13 maja 2010 r. przeglądarka Google o otwartym kodzie źródłowym, Chromium , była jedyną przeglądarką internetową korzystającą z nowego modelu wtyczek przeglądarki. Od 2020 roku Pepper jest obsługiwany przez przeglądarki oparte na silnikach układu Chrome, Chromium i Blink, takie jak Opera i Microsoft Edge.

W sierpniu 2020 roku Google ogłosił, że obsługa PPAPI zostanie usunięta z Google Chrome i Chromium w czerwcu 2022 roku.

PPAPI w Firefoksie

Firefoksa oświadczyli w 2014 roku, że nie będą wspierać Peppera, ponieważ nie ma pełnej specyfikacji interfejsu API poza jego implementacją w Chrome, który sam jest przeznaczony do użytku tylko z silnikiem układu Blink i ma prywatne interfejsy API specyficzne dla wtyczki Flash Player, która nie są udokumentowane. W październiku 2016 Mozilla ogłosiła, że ​​ponownie rozważyła i bada, czy włączyć Pepper API i PDFium do przyszłych wydań Firefoksa, jednak nie podjęto takich kroków.

Aplikacje

Jedna witryna używa NaCL na serwerze, aby umożliwić użytkownikom eksperymentowanie z językiem programowania Go z poziomu ich przeglądarek.

Przyjęcie

Niektóre grupy programistów przeglądarek obsługują technologię Native Client, ale inne nie.

Zwolennicy

Chad Austin (z IMVU ) pochwalił sposób, w jaki Native Client może wprowadzić do sieci wysokowydajne aplikacje (z około 5% karą w porównaniu z kodem natywnym) w bezpieczny sposób, jednocześnie przyspieszając ewolucję aplikacji po stronie klienta, dając wybór używanego języka programowania (oprócz JavaScript ).

John D. Carmack z Id Software pochwalił Native Client na QuakeCon 2012, mówiąc: „jeśli musisz coś zrobić w przeglądarce, Native Client jest o wiele bardziej interesujący jako coś, co zaczęło się jako cholernie sprytny hack x86 w sposób że mogliby to wszystko ciekawie piaskować w trybie użytkownika. Teraz jest to dynamiczna rekompilacja, ale coś, co programujesz w C lub C++ i kompiluje się do czegoś, co nie będzie poziomem optymalizacji -O4 dla całkowicie natywnego kodu, ale cholernie blisko do natywnego kodu. Mógłbyś wykonywać wszystkie swoje pogonie za złymi wskaźnikami i cokolwiek chcesz robić jako twórca gier do metalu ”.

Krytycy

Inni specjaliści IT są bardziej krytyczni wobec tej technologii piaskownicy, ponieważ wiąże się ona z istotnymi lub merytorycznymi problemami z interoperacyjnością.

Wiceprezes Mozilli ds. Produktów, Jay Sullivan, powiedział, że Mozilla nie planuje uruchamiać natywnego kodu w przeglądarce, ponieważ „Te natywne aplikacje to tylko małe czarne skrzynki na stronie internetowej. […] Naprawdę wierzymy w HTML , i na tym chcemy się skoncentrować”.

Christopher Blizzard z Mozilli skrytykował NaCl, twierdząc, że kod natywny nie może ewoluować w taki sam sposób, jak sieć oparta na kodzie źródłowym. Porównał także NaCl do technologii Microsoft ActiveX , nękanej przez DLL Hell .

Håkon Wium Lie , CTO w Operze, uważa, że ​​„NaCl wydaje się„ tęsknić za złymi starymi czasami, zanim pojawiła się sieć ””, a „Native Client polega na budowaniu nowej platformy – lub przenoszeniu starej platformy do sieci [. ..] spowoduje to problemy ze złożonością i bezpieczeństwem oraz odwróci uwagę od platformy internetowej”.

Drugie pokolenie

Druga generacja sandboxingu opracowana w Google to gVisor . Ma zastąpić NaCl w Google Cloud , a dokładniej w Google App Engine . Google promuje również WebAssembly .

Zobacz też

Linki zewnętrzne

Przykłady

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Google_Native_Client&oldid=1135574709 ”