5 Kasım 2012 Pazartesi

Native Client Teknik Bakış -1



Herkese Yeniden Merhaba !

Web konusunda çok heycan verici yeniliklerin kapısındayız. (yine mi ? :) Her yeniliğin yeni bir fırsat olduğunu da düşünürsek heycanımız daha da artırıyor! Araştırılacak ve yazılacak çok ama çok şey var...  Bugün Google Native Client teknolojisine biraz daha (çok fazla değil) derinlemesine gireceğiz; genel teknik alt yapısından ve de kurulumundan bahsedeceğiz.


Native Client in ne olduğundan daha önceki yazımızda bahsettiğimiş ve demiştik ki: browser içinde hiçbir plugin gerektirmeden 3D ortamı sunan Google in heycan verici teknolojisidir. Bu makaleyi okumadan önce ilk yazıya bir gözatmanızı öneririm.


Temel Özellikler:

  • Native Celient bir open-source projesidir ve NEW BSD (BSD 3) lisanslıdır; browser ortamında gerçek 3D oyun deneyimi sunmak için Google in ürettiği bir teknolojidir. Aslında sadece oyunlar değil, her türlü video editing, multimedia yazılımları, ve normal yollarla mümkün olmayan görsellikte her türlü 2D / 3D web uygulamalası artık olağan hale gelecektir.

  • Bunlar geçmişte de hayal edilmiş ve bir çok başarısız girişim ile daha önce denemişti: ActiveX, Java, Shockwave 3D, türlü çeşitli browser pluginleri vs... (özellikle Java ve ActiveX in web maceraları tam anlamı ile faciha ile sonuçlanmıştır.) Google geçmişten dersler çıkararak geliştirdiği bu teknolojide hiçbir kurulum ya da plugin gerektirmeden browser ortamında neredeyse normal masaüstü programların / oyunlarının 3D deneyiminin aynını sunuyor. Üstelik platform (işletim sistemi) bağımsız bir şekilde!

  • Native Client, normal masaüstü yazılımlarına oranla en fazla %5 lik performans kaybı ile istemci bilgisayar donanımının tüm 3D grafik kartı, Ses kartı, multithread (çoklu görev), klavye / mouse / game pad girdileri, hafıza erişimi ve sınırlı bir miktar disk depolama özelliklerini kullanır. Browser a hiçbir plugin veya yazılım kurmayı gerektirmez. Bu şekilde sisteme en çok yük bindiren konsol oyunlarının bile browser dan oynanması sağlanabilir. FullScreen desteği ile bir web sayfasında olduğumuzu dahi düşünemeyeceğimiz anlar olacak.

  • Bu insanların web uygulamalarından artık beklediği şeydir. Web uygulamaları geleceğin yegane ortamı olacağına göre, basit bir baloncuğu hoplatmak için yüzlerce satır javascript kodu yazmanın gerektiği günümüz web ortamından fazlası gerekiyor artık. Her şey webe kayacaksa, neden bilgisayar donanımını hiçbir şekilde kullanamayan basit script lere razı olalım? :)

  • Native Client, sunucudan gelen derlenmiş (binary) kodu browser ortamında güvenli bir şekilde çalıştırır. Bütün Chrome larda çalışan bu standart kod işletim sistemlerinden bağımsızdır. Yani chromun olduğu her yerde aynı Native Client kodu çalışır. Ancak şimdilik işlemci bağımlılığı vardır (yani bazı işlemciler şimdilik desteklenmiyor).

  • Bir Native Client uygulaması C / C++ ile geliştirilmiş bir modülü ve o modülü içeren html js css web dosyalarından meydana gelir. SDK sında C ve C++ dilleri doğal yolla desteklenir. Diğer diller üzerinde çalışılmaktadır, örneğin: C# gibi. Kodlar GNU / GCC evrensel derleyicilerinin çok benzeri bir ortamda derlenir. Native Client ortamında bir kez derlenen kodlar tekrar derlenmeksizin kolayca uygulamadan uygulamaya taşınabilir.

  • Bugüne kadar sayısız desktop uygulaması için sayısız yazılım firması milyonlarca satır kod üretildi. Bu kodların pek çok kısımları da çok fazla bir değişikliğe maruz kalmadan Native Client ortamına aktarılabilir (port edilebilir). (başlıca değişmesi gereken kısımlar kullanıcı arabirimi event handling kısımlarıdır.)

  • Normalde desktop uygulamalarını bilgisayarlara tek tek install etmek veya browser plugini yüklemek çok ciddi güvenlik açıkları yaratır ve de efor kaybettirir. Bunları kurup kaldırmakla geçen zaman bir yana dursun; eğer windows kullanıyorsanız sonu eninde sonunda karışan sisteminiz ile beraber “format c:” dir! Native Client da ise web ortamında ise install / uninstall yoktur. Web ortamından kolayca yüklenen ve işi bitince kolayca çekip giden derlenmiş kodlar vardır.

  • Native Client gerek derleme anında, gerekse çalışma (runtime) anında sürekli kontroller ve kısıtlamalar yapar, bunlar güvenlik amaçlıdır. Chrome in içerdiği Sandbox-Safe sayesinde kötü niyetli yazılımlar özellikle istemci tarafında amacına ulaşamaz. Derleme aşamasında da zaten bi çok kısıtlama uygulanmaktadır. Dahası Native Client uygulamaları ancak Google Web Store üzerinden yüklenebilir. Aksi durumda Chrome zaten çalıştırmaz. Burada da denetleme mekanizmaları mevcuttur.

  • Native Client kullanıcı verilerini de güvenceye almak için karmaşık kriptolama algoritmaları da içerir. Kullanıcı bilgileri network ortamında okunabilir gitmez.

  • Sesleri işlemek için codecler, imaj ve video araçları, network api leri, 3D için OpenGL ES API si, programlanabilir shadder lar vs.. sayısız yardımcı araçlar içerir.

  • Native Client uygulamaları Google Web Store dan kolaylıkla yüzmilyonlarca kişi ile buluşturulur. buradan Chroma bir tık ile yüklenir, ve bir tık ile anında kaldırılır. Ve uygulamalar kullanıcının müdahalesine gerek kalmadan update edilebilir.

  • Native Client SDK kullanılarak uygulamalar geliştirilir, bu SDK GNU-GCC,   C / C++ derleyicilerinin bir miktar değiştirilmiş bir versiyonunu, GNU ve Unix tabanlı “Binutils” yardımcı araçlarının bir kısmını, iki open source C / C++ kütüphannesini (glibc, newlib), ve tabiki Native Client framework leri, ki google framework yerine “Pepper” tabirini kullanıyor. (bunları ilerde açacağız.)




Native Client Open Source mi ? nasıl yani ??


Bilgidğiniz gibi Google kendi çekirdek sistemlerinde Unix kullanıyor. Dolayısı ile ürünlerini de çoğu durumda Unix ile sistemi ile büyük oranda uyum gösteren ve ücretsiz olan open-source dünyasından tercih edebiliyor. Böylece hem de kendisi tekerlekleri yeniden icat etme derdinden kurtularak kısa zamanda önemli işler başarabiliyor, hem de standartlar korunuyor. Ayrıca Linux / Open-Source dünyasındaki geliştiricileri de doğal yoldan yanına alıyor. Bu birliktelik her iki tarafa da yarıyor, bu denli büyük bir şirketin desteğini ile open-source dünyası karmaşadan bir nebze daha kurtuluyor, (evrensel anlamda) markalaşıyor (standartlaşıyor), daha bilinir, daha kalıcı, daha yaygın ve de özgür olmayan yazılımlar karşısnda daha etkili oluyor! Kısaca Google özgür yazılım dünyasını aktif bir şekilde kullanıyor ve bu dünyaya da doğrudan destek veriyor... Örneğin Android sisteminin çekirdeği Linux tur. Chrome OS işletim sistemi de yine Linux un Google makyajlı halidir. Aynı şekile Native Client (NaCl) da open-source dünyasının yazılım geliştirme derleyici ailesi olan GNU-GCC (GNU Compiler Collection) temelli olacak şekilde tasarlanmıştır. Bugüne değin sadece open-soruce dünyası tarafından çok iyi bilinen bu derleyici Google Native Client in tabanında yer alması ile artık çok daha geniş bir kitle tarafından kullanılmaya başlanacaktır.



SDK Kurulumu:
Şimdi gelin biraz da Google Native Client bir SDK sının kurulumundan bahsedelim. SDK içeriğine sonra gözatarız. Kurulum zaten oldukça basit. Önce nacl_sdk.zip dosyasını indirin ve bilgisayarımızın C:\  root klasörüne açın. Yani,

c:\nacl_sdk

sonra bul foldera giriş yapın,

c:\cd nacl_sdk
c:\nacl_sdk> _


Bu noktada bilinmesi gereken en önemli nokta SDK içinde bir çoğu Python ile yazılmış scriptlerden oluşan araçlar vardır. Dolayısı ile makinemizde Python 2.6 yada 2.7 kurulu olmalıdır. Pyhthon 3 henüz desteklenmiyor. Eğer elinizdeki sistem bir Linux veya Mac ise büyük ihtimalle Python zaten doğal bir biçimde mevcuttur. Ama windows kullanıyor isek python u kendimiz yüklemeliyiz. (eskiden uzaylılar dışındaki tüm canlılar windows kullandığı için başka sistemleri düşünmek zorunda kalmazdık. Artık hiçkimse tek, yanlız ve rakipsiz değil; ve bunlar bilişim dünyasının heycan verici gelişmeleridir...) Python yüklemek için http://www.python.org/download adresinde gidin ve 2.6.x veya 2.7.x versiyonlarından birini yükleyin.

Kolay kullanım açısından Python uda yine C:\ kök dizinine kurun yani : C:\Python27 şeklinde. Instal ettikten sonra "python ‑V" prompt penceresinden komut verilip 2.6 veya 2.7 nin kurulduğu test edilebilir. (büyük harf V)


şimdi tekrar nacl_sdk dizinine dönelim,

SDK nın root dizininde SDK yı ilk kullanım için hazırlayan, güncellemeleri yükleyen bir script mevcuttur. nacl_sdk kök dizini altında naclsdk.bat ismi ile bulunan bu script aslında python ile yazılmış kodlardan oluşur. Dolayısı ile bu komut python derleyicisinin yolunu arayacak, bulamazsa çalışmayacaktır. Python derleycisi c:\python27\python.exe yolundda bulunduğundan dilerseniz rahat çalışmak için önce path tanımlayıp python derleyicisinin yolunu belirtelim, yani şöyle :

c:\nacl_sdk> path c:\python27
Artık python.exe her bulunamadığında doğrudan bu yolda aranacak.



Devam edelim,
Şimdi Native Client SDK bakım aracımızı çalıştırabiliriz, ekrana doğrudan :

C:\nacl_sdk> naclsdk.bat

yazarsak bu komutun hangi parametreler ile çalışacağını belirten bir liste gelecektir. Ben burada sadece bazı temel işlemleri anlatacağım.

indirdiğimiz nacl sdk ile birlikte hangi pepper ların bilgisayarımıza yüklendiğini kontrol etmek için:

c:\nacl_sdk> naclsdk list

komutu ile yüklenen pepper ları (bir anlamda frameworkleri), stabillik aşamalarını da belirten şekilde listeler. Bazı ilk pepper versiyonları zaten ilk download da yüklü gelebilir. Burada listelenen pepper versiyonlarının tamamı kullanılabilir durumdadır, ancak bazıları henüz beta aşamasında olduğu için listelemelerde yanlarında tavsiye edilmez anlamında recomended : no yazabilir.


.NET için framework versiyonu ne anlamda ise buradaki pepper versiyonu da o anlamda kullanılıyor. Geliştirmemizi yaparken tek bir pepper versiyonu seçip ona mutabık kalacağız. (Türkçesi ile “biber” anlamına gelen bu pepper kelimesindeki alakayı kuramadımsa da uzunca bir teffekürün ardından alakanın da olması gerekmediğini farkettim :D

Devam edelim,

c:\nacl_sdk> naclsdk install

komutu kurulumu başlatır, gerekli paketleri bilgisayarınıza kurmaya başlar. bitene kadar bekleyin.

c:\nacl_sdk> naclsdk update

Yeni bir update varsa yüklemek içindir. Tavsiye edilen (recomended) güncellemeleri yükler. Komuttan sonra yaptığı yenilikleri ekranda listeler. İlk kullanımda mutlaka bu update komutunu verip güncelleştirmeleri yüklemenizi öneririm. Sonradan da ara ara bu komutu vermekte fayda vardır.

c:\nacl_sdk> naclsdk update all

komutu tüm varolan pepper versiyonlarının güncelleştirmelerini kontrol ederek varsa yükler.
Update komutu yankızca recomended paketleri yükler. Eğer sadece belli bir paketi yüklemek istersek :

c:\nacl_sdk> naclsdk update pepper_19

gibi bir komut verebiliriz. Ve tekrar list komutu vererek güncelleştirmeyi yapıp yapmadığını görebiliriz.
Eğer zaten yüklenmiş olan bir paketin yeni versiyonu var ise naclsdk.bat bizi uyarır; ya da bazen elimizdeki dosyalar silnebilir / bozulabilir ve SDK tarafından güncel olduğu sanıldığı için güncellenmeyebilir. Böyle bir durumda Varolan klasörün üzerine yazarak güncelleştirmeyi yapması için:

c:\nacl_sdk> naclsdk update --force


komutu ile yapının tümüyle yeniden güncelleştirilmesini sağlarız.
Sadece belli bir pepper i güncellemeye zorlamak için :

c:\nacl_sdk> naclsdk update pepper_20 --force

Evet bu naclsdk.bat aracı SDK nın kök dizininde yer alan, güncellemeleri yapan ve SDK paketlerinin güncelliği / kullanılabilirliği bilgisini veren python tabanlı temel araçtır. Kabaca kullanımı yukarıdaki gibi. SDK yı indirdikten hemen sonra bir update yapmakta ciddi fayda var. Dahası sık sık update komutu vermenizi de halishane öneririm. Çünkü bu SDK üzerinde sürekli çalışılıyor ve güncelleniyor.




Peki SDK İçinde Neler Var ?
c:\nacl_sdk dizininde naclsdkbat dosyasından başka iki temel klasör daha vardır bunlar :
sdk_cache ve sdk_tools.


sdk_cache altında json formatında bir belge ve bu belge içinde de yüklenmiş paketlerin (bundles) listesi ve detaylı bilgisi bulunur, yani şurada :

C:\nacl_sdk\sdk_cache\naclsdk_manifest2.json

diğer dizin sdk_tools de ise SDK mızın güncelleme / yükleme işlemlerinin yapıldığı bir anlamda SDK nın bakım araçlarının yer aldığı klasördür. Bufadaki komutların çoğunun python derleyicisi ile çalıştığını lütfen unutmayın. Ve buradaki araçları tek tek ezberlemek zorunda değiliz; naclsdk.bat scriptimiz bizim için buradaki araçların çoğunu çağırır.
.
SDk update aracını da çalıştırdıktan sonra folder yapısı bende resimdeki şekilde görünüyor. Pepper versiyonlarının her birinin ayrı bir folder a yerleştiğiniz görebilirsiniz. En altta naclsdk.bat yardımcı aracımız da görünüyor.



Buradaki her bir Pepper versiyonu içinde yazılımların geliştirileceği kütüphanelerin ve derleme araçlarının olduğu framework lerdir. Bilmemiz gereken ilk şey uygulamamızı geliştirirken hangi pepper versiyonunu kullanmış isek, onu çalıştıracak Chrome browser bunu desteklemelidir. Yani eğer uygulamamızı pepper_22 de yazmış isek uygulamamızı çalıştıracak minimum Chrome versiyonu da en az 22 olmalıdır.

vs_addin klasörü geliştirme ortamı olarak Visual Studio kullanmak isteyenler için şık bir eklentidir. Bu konuya ileride detaylı değineceğim.

pepper_canary dizini ise halen hazırlanmakta olan pepper_24 e işaret ediyor.

Son olarak her bir pepper versiyonunda ne gibi yenilikler olduğunu görmek için de releasenotes dosyalarına gözatabiliriz.



PEPPER YAPISI :

Şimdi biraz da pepper içinde neler var ona bakalım. Pepper lar Native Client framework leridir demiştik. Uygulamalarımız bir pepper versiyonu için yazılır ve o pepper klasörü içinde derlenir. SDK içinde her bir versiyon için bir pepper klasörü mevcuttur. Ve üretilen modüller farklı versiyonlardaki peper lar için olabilir. Yani modüllerin pepper versiyonu kavramı vardır. Google bu olaya “particular pepper platform” adını vermektedir. Yani bir anlamda .NET in framework versiyonlarına da benziyor diyebiliriz bu yönüyle.

Nasıl ki .NET te uygulamanın yazıldığı framework ü sunucu desteklemek zorundadır, Native Client ta ise uygulamanın yazıldığı pepper versiyonunu istemci tarafındaki Chrome browser desteklemek zorundadır. Yani uygulama web sunucusunda değil bizzat istemcinin bilgisayarında (browser üzerinde) koşmaktadır. Pepper lar yüklemeleri chrome içinde hali hazırda bulunur ve sessiz ve derinden güncellenir. Örneğin bir native client uygulaması Pepper_22 ile yazılmışsa chrome içinde bu versiyon yüklü olmak zorundadır. Yani pepper_22 dizininde derlenen uygulama Chrome22 ve üzerinde ancak çalışabilir. Bu derleme versiyon kurallarını esnetmek için extra derleme parametreleri üzerinde çalışılmaktadır.

Aşağıdaki resimde pepper_23 ün içi görüntüleniyor:


toolchain klasörü Native Client in kalbinin attığı kilit yerlerden biridir. Bu klasörde iki C kütüphanesi bulunur : Glibc, Newlib. Open-source dünyasının çok yakından tanıdığı bu iki C kütüphanesi Native Client SDK sına çok az değişime uğratılarak dahil edilmiştir. Her iki kütüphane de kendi içinde hem 32 bit hem de 64 bitlik derleyiciye ve araç kümelerine sahiptir. Bu araçlar da yine bir open-source cu arkadaşların çok yakından tanıdıkları GNU araçlarının çok az modifiye edilmiş halleridir. Özellikle Glibc dünya genelinde çok yaygın ve de standart bir C kütüphanesidir. Newlib de red-hat firmasının ürettiği başka bir şık open-source C kütüphanesidir.


examples klasörü örnek Native Client uygulamalarının yer aldığı yerdir. Buradaki örneklere gözatarak bir nacl uygulamasının yapısı hakkında çok şey öğrenebiliriz. Her Native Client uygulamasında (örneklerde de görüleceği üzere) sunum aşamasında web sayfası .html, uygulama hakkındaki bilgileri tutan bir ayar (config) yani manifiest dosyası (.nmf), Native Client kaynak kodlarımızın yer aldığı C veya C++ dosyaları (.c ve .cc), bu dosyalara ait başlık tanımları yani header dosyaları (.h), ve bir de uygulamayı kolay yoldan derlemeyi sağlayan make.bat /makefile script dosyaları mevcuttur. Bu dosyaların çoğu bir Native Client uygulamasında olur, özellikle makefile ve make.bat her bir examples klasöründe mevcuttur. Ve içinde bulundukları klasörü derler. Derleme sonucu kaynak kodlarından yine aynı klasör içinde yürütülebilir native client (.nexe) dosyaları oluşur.
Pepper ların altındaki bir diğer klsör olan TOOLS klasöründe de o pepper versiyonu için yardımcı araçlar vardır. bunlardan bazıları exe bazıları ise python scriptidir.


Şimdi bir Native Client uygulamasını oluşturan dosya türlerine daha yakından bir gözatalım ve kısa açıklamalarını yazalım:


.C / .CC kaynak (source) dosyaları :
derleme aşamasından sonra yürütülebilir .nexe dosyalarına dönüşecek olan C ve C++ kod kdosyalarıdır. Kod yazarken Open Source dünyasının gayet iyi bildiği GlibC ve NewLib C kütüphanelerini temel olarak kullanılırlar. Asıl kütüphane tercih edilen Pepper_x versiyonunun pepper API sidir. Bunun yanı sıra Native Client için emre amade sayısız API ve bulabileceğimiz diğer paylaşımlı kütüphaneleri (shared libaries) kullananılabilir.

Derlenen kod modülleri browser içindeki pepper da koşarak istemci bilgisayarda sistem kaynaklarını doğrudan kullanır. Pepper burada kod modülleri ile browser arasında bir köprü görevi görür. Bir anlamda ara framework tür. Bunu bir yönü ile java sanal makinesi JVM lere de benzetebiliriz. Aradaki fark nerede ise hiçbir yavaşlama olmamasıdır. Pepper in dorudan o sistemin işlemcisine özel kodları koşturmasıdır.





.NMF:
.nmf dosyası uygulama hakkındaki bilgileri içeren bir manifiest dosyasıdır. Yani bir ayar / yapılandırma dosyasıdır. Bunu .NET deki web.config dosyaları gibi düşünebiliriz. Build aşamasında yapılandırılırlar, ve uygulamanın bağlı olduğu kaynakları belirtirler. Örneğin aşağıda examples dizininde bulunan fullscreen_tumbler uygulamasının .nmf manifiest dosyası (fullscreen_tumbler.nmf) gösteriliyor :
{
"program": 
"x86-64": {"url": "fullscreen_tumbler_x86_64_dbg.nexe"},
"x86-32": {"url": "fullscreen_tumbler_x86_32_dbg.nexe"}
}
}

kodlarda kullanıcının bilgisayarındaki browser mimariye göre hangi derlenmiş nacl modülünü yükleyeceğine (86x32 / 86x64) bu dosya ile karar verir. Aynı zamanda uygulamada kullanılacak dosyaların kota sınırı ile ilgili bilgiler de yine nmf içinde tanımlanır. SDK yı ilk kurduğunuzda örnek uygulamaların içinde .nmf dosyalarını göremeyebilirsiniz. Bu dosyaların build aşamasında .nexe lerle birlikte oluşturulduğunu lütfen unutmayın. Nmf dosyaları aynı zamanda Glibc kütüphanesi ile birlikte desteklenmeye başlanan shared libaries, yani paylaşılmış kütüphaneleri yükelemek için bilgi dosyalarıdır.

Native Client SDK si ile birlikte iki farklı C kütüphanesinin (toolchain) geldiğini söylemiştik : bunlar GNU GlibC (bir diğer dökümantayonu), ve RedHat firmasının ürettiği yine open source olan NewLib idi. Ve eğer NewLib kütüphanesi kullanmış isek .nmf dosyası aşırı derecede basittir; elle de yazılabilir. Glibc nin kullanılması durumunda bazen .nmf lerimizi kendimiz manuel yazmamız gerekebilir. Nmf lerin glibc ve shared libary lerde de otomatik yaratılması için yardımcı bir araç üzerinde çalışılmaktadır; ki siz bu makaleyi okurken dahi üretilmiş olabilir.



Makefile / Make.bat:
Native Client derleme işlemlerinde yardımcı araç olarak kullanılmaktadır. Make, bizi bir çok derleme aşamasından, uzun ve sıkıcı derleme komutlarını tekrar tekrar yazmaktan, aynı derlenmiş nesneleri tekrar derlemekten ve hatta .nmf dosyasının yaratılma işiden kurtaran yine open-soruce ve Unix sistemleri ile uğraşan arkadaşların çok iyi bildikleri bir yardımcı dost script tir. (Bu konuda detaylı bilgi için GNU 'make' manual sayfasına gözatınız.) Make in biraz değiştirilmiş ama çok benzer bir versiyonu Native Client a dahil edilmiştir. GNU derleme araçları gibi onun parametreleri de çok büyük ölçüde tamamen aynıdır. Exampes altındaki make.bat dosyalası aslında pepper_X/tools altındaki asıl make komutuna kısayol içerir. Asıl make.exe ye neyi nasıl yapacağını söyleyense makefile dosyasının içinde bulunan toplu komutlardır. Dilerseniz examples altındaki her bir makefile i bir metin editöründe açıp içeriğine gözatabilrisiniz. Eğer make.bat ı çalıştırırsanız o uygulamanın kaynak kodları derlenecek ve 32 bit ve 64 bit olarak iki farklı .nexe olulacaktır. Bununla da kalmayacak, oluşan .nexe leri tanımlayan bir .nmf manifiest dosyası da yapılanmış bir şekilde oluşacaktır.

Newlib kütüphanesini kullanan uygulamalarımız makefile / make.bat ile derlendiğinde C:\nacl_sdk\pepper_20\toolchain\win_x86_newlib yolundaki kütüphane ile derlenir. Diğer kütüphane de yine toolchain altında bulunan diğer bir klasör olan win_x86_glibc dir.

Makefile in open-source dünyasında yaygın kullanılan bir derleme yardımcı aracı olduğunu,, derleme işlemlerini otomatikleştirerek kolaylaştırdığını, ama ille de şart olmadığını şimdilik bilmemiz yeterli. Çünkü makefile in kendisi bir derleyici değildir; sadece yardımcı scripttir. Make ile ilgili derinlemesine bilgi sahibi olmak için GNU Make kaynaklarına bakılabilir. Derlenen kaynak kod dosyaları (.c ve .cc) .nexe uzantılı atık yürütülebilir dosyaya dönüşür. Hem 32 bit hem de 64 bit e derlenmiş iki yürütülebilir durumdaki nexe uygulamamızın klasöründe yer almalıdır. Bunlar embed tagı ile web sayfasına gömülecektir. Örneğin :


   <embed name="nacl_module"
     id="hello_tutorial"
     width=0 height=0
     src="hello_tutorial.nmf"
     type="application/x-nacl" />


peki Native Client her yerde çalışacak mı ?
.nexe dosyaları şimdilik yalnızca x86 işlemci ailesinde (32 bit ve 64 bit) koşabilir. Yani Native Client şu aşamda platformlardan (işletim sistemlerinden) bağımsız olsa da işlemciye bağımlıdır. Ve şu aşamada sadece x86 işlemciler destekleniyor. Ancak henüz yeni olan bu teknolojiye biraz zaman tanımalıyız. Çünkü çok yakında ARM işlemcilerine destek gelecek, bu işlemcilerin Android başta olmak üzere pek çok mobile işletim sistemine hayat verdiğini düşünürsek Native Client çok yakında neredeyse tüm mobiliteyi (!) de kapsayacak diyebiliriz. Native Client in daha ileriki versiyonları ise tüm işlemcilerde çalışacak şekilde evrim geçirecek. Bu durumda derleme aşamasında her türlü mimari için bir standart gelecektir. Yani her işlemci tipi için ayrı ayrı dosya üretmeye gerek kalmayacak. Ve tüm işlemciler desteklenecek. Adına PNACl (Pinnacle Native Client) bu teknoloji üzerinde çalışılıyor, ancak biraz zaman.....)

Examples dizinindeki her hangi bir uygulamanın alt dizinindeki make.bat ını çalıştırırsanız o uygulama derlenir demiştirk; ancak examples ana dizinindeki make.bat ı çalıştırırsanız bütün uygulamalar derlenir.


.html .js .css :
temel web dosyaları; nacl modülünün içinde koşacağı gösterim alanı olan bir web sayfası (*.html)
web sayfası da malumunuz HTML, JavaScript, CSS dosyalarından oluşur. Nexe dosyası embed tagı ile html içinde tanımlanır. Böylece .nexe sayfa içinde (browser desteği ile) koşar.


Javascript ile Native Client iletişimi :
browser içinde (nacl modülü ve javascript arasındaki) bu iletişim iki yönlüdür. Javascript kodu Native Client modülüne mesaj yollayabilir; ve aynı şekilde modül de JavaScript i tetikleyecek mesajı dönebilir. Her durumda bu iletişim asenkrondur. Yani mesajı yollayan taraf bir beklenti içinde olmaz, cevap beklemez ! Çalışmaya aynen devam eder. Bu mantık web deki client/server mimarisine kısmen benzer. Örneğin çağrıyı alan sunucu çıktı olarak sayfayı istemciye yollar ve bağlantısını tamamen keser. Native Client - Javascript iletişimi de böyledir. Bu mesajlaşma sistemi Pepper API sinin bir parçasıdır. Ve detaylı bir konudur...


Güvenlik nasıl sağlanacak?
Değişik güvenlik önlemlerinden bahsettik, değişikliğe upratılmış GCC derleme araçları, Chrome içindeki Peper oynatıcı gibi.. Bunlardan biri de Native Client uygulamalarına sadece Google Web Store dan yüklenmesine izin verecek olmasıdır. Chrome aksi durumda yüklemeyecek. Chrome daki bazı ayarlamalar ile bu kısıtlama kaldırılsa bile hiçbir şekülde sürükle bırak ile bu modülleri çalıştıramayız. En azından bir web sunucusundan yüklenmelidir. Geliştirme sürecimizde bu sıkıntı yaratmasın diye SDK basit bir Python web server içerir, böylece derlediğimiz uygulamalarımızı orada çalıştırabilir ve test edebiliriz.


Python Web Sunucusunu Başlatma :
bu basit web sunucusunu başlatmak için SDK içindeki uygulamamızı yazdığımız pepper versiyonunun dizinindeki examples alt dizinine gidilir ve httpd.py çalıştırılır. Örneğin pepper_20 kullanıyorsak sanal web sunucusu için çalıştıracağımız dosya : pepper_20/examples altındakidir. Command promptan bu dizine erişip : python httpd.py komutu verilir. Eğer özellikle port numarası belirtmez isek default olarak 5103 portu atanır. ve dolayısı ile sunucuya http://localhost:5103 şeklinde bir linkten artık erişebiliriz. Yeni python sunucumuz hayırlı olsun :) elbette SDK içindeki server i kullanmak zorunda değiliz. herhangi bir web sunucu ya da uygulamanın sunucudan geldiği konusunda browser i kandıracak, client-server mimarisini taklit edecek herhangi bir simülasyon program da aynı işi görür. Açıkçası sunucu NaCl geliştirme sürecinde çok elzem bir konu değil. NaCl nin client ortamında (kullanıcının browserinda) çalıştığını hatırlayın. Tabi bu makalede NaCl SDK sını incelediğimize göre bu SDK ile gelen araçları kullanalım derim.


o zaman gelin işe basit server görevi görecek Python Server Servisini çalıştırarak başlayalım :

python derleyicisinin yolunu belirtiyoruz,

c:\nacl_sdk> path c:\python27

pepper_20 versiyonlu kütüphanenin deneme uygulamaları folderine erişelim ve server i başlatalım

c:\nacl_sdk\pepper_20\examples> python httpd.py

bu komut ile server çalışır, artık browserimizin adres satırına http://localhost:5103 yazarsak examples folderindaki uygulamaların bir listesi önümüze gelecektir. Üzerlerine tıklayarak basit örnek uygulamalara gözatabilirsiniz. Eğer uygulamalar görünmüyorsa dosyaların henüz source halde olmasından ve derlenmediğinden olabilir. Söylediğimiz gibi Native Client da istemci tarafına script kodları değil derlenmiş binary modül yolluyoruz. Eğer çalışmayan example örnekleri varsa dilerseniz dosyalarımızı tümden derleyelim.

c:\nacl_sdk\pepper_20\examples> make

Şimdi uygulama dizinlerine gözatarsanız .nexe dosyalarının olultuğunu görebilirsiniz. Her iki işlemci tipi içinde aynı programın farklı iki versiyonu oluşmuş. Yani istemcinin işlemci tipi ne ise o yollanacaktı hatırlayın. Şimdi tekrar browsera dönelim http://localhost:5103 ve examples örnek uygulamaları çalıştıralım. Artık çalışması lazım...


Eğer hala çalışmıyorsa  :)

1- öncelikle kullandığımız pepper versiyonunun Chromun versiyonundan ileri olmadığına emin olmalıyız. Örneğin pepper22 yi kullanıyorsak, oysa bilgisayarımızdaki chrome21 versiyonu yüklü görüntüleme olmaz. Chrome zaten otomatik update yapar. Böyle bir durum ancak çok yeni çıkan ve henüz beta aşamasında olan ve henüz elimizdeki chrome in desteklemediği bir pepper da olabilir. Bu durumda bir alt pepper versiyonunda çalışın. Tabi önce chrome versiyounu kontrol edin,, versiyonu kaç ise pepper o versiyonu geçmemelidir.

2- Chrome in NaCl ayarı chrome da aktif durumda olmalıdır. Natice Client, Chrome Web Store dan dağıtılan uygulamalar için default olarak zaten aktiftir. Ancak dağıtık olmayan (!)(?), yani lokal bilgisayarımızda yazıp derlediğimiz uygulamalar için de aktif olması için chrome adres satırına : chrome://flags yazın; karşınıza bir ayar tablosu gelecek. Burada,

"Native Client Mac, Windows, Linux, Chrome OS
Chrome Web Mağazası'ndan yüklenmiş olmasa bile, tüm web uygulamaları için Native Client'ı etkinleştir."  kısmını bulun, ve etkinleştirin. (eğer alt kısımda “devre dışı bırak” yazıyorsa zaten etkin demektir.) Ve Chrome u yeniden başlatın.

3- Yine olmuyor ise Chrome Cache ini disable edin. Çünkü chrome kaynakları çok güçlü bir biçimde cache ler. Ne zamanki bir Native Client uygulaması geliştirmiş isek crome un uygulamamızın yeni versiyonunu yüklemesi için cache i temizlemeliyiz. Bunun için de : ikonunna tıklayarak açılan menüden Araçlar > Geliştirici araçları (Tools> developer tools) kısmına girin. Ekranın sağ alt tarafındaki ikonuna basın. Açılan panelden General tabı altındaki "Disable cache" in seçili olduğuna emin olun. Seçili değilse seçin ve chromu yeniden başlatın.

4- eğer yine olmazsa bilgisayarınızı yeniden başlatın :) güldüğüme bakmayın,, ciddiyim...

5- yok gene olmadı ise google a sert bir mektup yazabiliriz... :D


Examples klasöründeki uygulamaların hazır çalışan hallerini görmek için :
http://gonativeclient.appspot.com/dev/demos/sdk_examples linkine gözatabilirsiniz. Buradakiler çok basit uygulamalar arkadaşlar, daha çok kod tarafında bizlere bir temel vermek için. Görsel şov için Native Client teknolojisini kullanan Bastion gbi örneklere gözatmanızı öneririm. Ve size söyliyim,, en az bir Doom3 kadar bomba 3D oyunlar yolda, üstelik Chrome içinde, ve üstelik hiçbir plugin gerektirmeden...


Evet bu makalede teknik yapıya biraz daha detaylı değindik, temel derleme yaptık ve örneklere gözatmak için de kısmi python sunucusunu çalıştırdık.

Yazacak ne çok şey var daha... :) ama bu yazı çok da fazla uzamanadan şimdilik burada bitirelim. Bir başka makalede tekrar görüşmek üzere hoşçakalın.


Yorum Gönder