Certyfikaty na Symbiana

Jednym z najbardziej kontrowersyjnych tematów wśród posiadaczy komórek jest podpisywanie aplikacji na Symbiana. Inżynierowie tworzący Symbiana spodziewając się problemów z masowym tworzeniem niebezpiecznego oprogramowania na komórki, postanowili zabezpieczyć się przed tym. Pierwsze zabezpieczenie to wprowadzenie mechanizmu wymogu podpisywania paczek instalacyjnych certyfikatami. A drugie zabezpieczenie to mechanizm uprawnień dostępu do plików w komórce i do pewnych bibliotek poprzez programistyczne API.

Warto przypomnieć z artykułów Symbian Foundation Security Blog kilka faktów: tworzenie infrastruktury opartej na certyfikatach nie było prostym zadaniem dla firmy tworzącej system operacyjny Symbian. W tej sytuacji postanowiono przekazać te zadania do zewnętrznych podmiotów. W 2004 roku postanowiono, że certyfikatami będzie zarządzać Verisign, testowaniem Capgemini, a Symbian będzie tylko zarządzał portalem do rejestracji oprogramowania i certyfikatów. Potem doszedł w 2007 roku TC TrustCenter, który faktycznie przejął główną rolę dostarczyciela certyfikatów dla twórców oprogramowania na Symbiana. Skutkiem takiego podejscia oznaczało że developerzy musieli sami się obsłużyć i generowało dodatkowe koszty tworzenia oprogramowania. A producentom komórek taki model był bardziej na rękę bo przenosił odpowiedzialność za oprogramowanie do komórek na programistów i organizacje testujące. Wkrótce okazało się, że zaczęły się pojawiać zagrożenia, ze strony niebezpiecznego oprogramowania. W tej sytuacji postanowiono jakoś zabezpieczyć się na poziomie systemu operacyjnego. Więc inżynierowie z Symbiana postanowili tak zaprojektować system, żeby wymuszał instalację tylko podpisanego i zaufanego oprogramowania z certyfikatem. Tak więc od 2006 roku mamy pierwsze komórki oparte na Symbianie 9.x, które posiadały mechanizm zarządzania uprawnieniami dostępu do programistycznego API.

Uprawnienia dostępu do API oznacza tylko tyle co wolno robić danemu programowi użytkownika. Zanim program zostanie uruchomiony zawiera informacje o tym jakie uprawnienia dostępu do API potrzebuje. Podczas instalacji najpierw jest sprawdzany czy paczka ma poprawny certyfikat, następnie sprawdzany jest rodzaj certyfikatu. Certyfikat może być wygenerowany na konkretna komórkę według posiadanego numeru IMEI, albo wg informacji o właścicielu certyfikatu (tzw z Publisher ID). Można też wyróżnić certyfikaty po kątem sposobu w jaki mogą zostały wygenerowane: własny (self-signed), developerski (devcert), z uprawnieniami (cert with manufactured capabilities).

Do nauki programowania Symbiana wystarczy w większości przypadków certyfikat własny (selfsigned). Instrukcja zrobienia takiego podpisu z linii poleceń wymaga zainstalowania SDK i przerobienia tej instrukcji. Natomiast, żeby wygenerować podpis developerski trzeba wcześniej mieć wykupiony certyfikat typu Publisher ID z firmy TC TrustCenter. Ten certyfikat kosztuje 200$ na rok czasu. Następnie trzeba zarejestrować się na stronie Symbian Signed. Pobrać program Developer Certificate Request i na bazie certyfikatu z Publisher ID wygenerować plik certyfikatu developerskiego w programie Open Signed Offline na konkretny numer IMEI.

Dla kogoś komu zależy na nauce programowania na Symbiana może też sobie używać do woli programu Open Signed Online, dzięki któremu będzie mógł wysłać swoją paczkę sis do podpisania przez nich certyfikatem dla IMEI danej komórki. Trzeba tylko pamiętać żeby UID3 był w zakresie 0xE0000000...0xEFFFFFFF. Podpisując w innym zakresie UID3 trzeba pamiętać o tym że inni nie będą mogli podpisywać poza Tobą danej aplikacji, bo dany UID3 będzie przypisany do danego adresu email osoby, która zażyczyła sobie dany UID3.

W takiej sytuacji dużą popularnością cieszą się chińskie usługi on-line do tworzenia developerskich certyfikatów. Są to: iMobile czy Opda.

Natomiast jak zależy na wprowadzeniu oprogramowania do masowej dystrybucji to czeka jeszcze sporo wydatków i pracy. Pierwszym to jest zakup certyfikatu PublisherID. Następnie zarejestrowanie się w programie Express Signed gdzie można kupować identyfikatory dla zawartości. Jeżeli zależy na tym, żeby twoja paczka sis z zawartością miała chroniony identyfikator UID3 to trzeba kupić PayPalem tak zwany ContentID. Następnie trzeba podpisać aplikację z certyfikatem i kluczem z TC TrustCenter. kolejną rzeczą jest wysłanie tego pliku sis do podpisania certyfikatem Symbiana (Root B). W programie Express Signed można podpisywać zawartość pasywną (multimedia, motywy) i jak aplikacje. Z tym, że trzeba wcześniej samemu sprawdzić czy aplikacja spełnia warunki testów. Po wysłaniu trzeba odczekać jakiś czas, a po wstępnej weryfikacji na koncie będzie podpisana przez Symbiana aplikacja. Czasami losowo występuje audyt twoich aplikacji. Jeżeli aplikacja nie będzie spełniać testów to konto zostanie zablokowane aż do momentu wysłania aplikacji spełniającej wymogi testów.

Natomiast w programie Certified Signed warto uzyskać podpisanie aplikacji pod kątem bezpieczeństwa i dostępu do zastrzeżonych uprawień API. Jest to dość kosztowny audyt, ale dzięki temu że zewnętrzni audytorzy sprawdzą działanie programu sprawi też że można uzyskać pewność że aplikacja jest bezpieczna dla użytkowników.

Nokia w programie dla firm Forum Nokia Launchpad wymaga, żeby firma biorąca udział w tym programie już posiadała Publisher ID. Natomiast dla własnych potrzeb mają dział który zajmuje się przygotowywaniem aplikacji do przetestowania wg dodatkowych kryteriów testów przez zewnętrzne firmy posiadające uprawnienia do testowania aplikacji. Dodatkowe kryteria są opisane w dokumencie Nokia Test Criteria for Symbian C++ Applications v2.1. Firmy, które zajmują się testowaniem aplikacji na Symbiana przed przyznaniem im zaufanych certyfikatów ną nazywane "Test Houses" Są to: Digia, Flander, Mphasis, NSTL, Sogeti.

Dla programistów midletów w technologii MIDP2.0 sytuacja też nie jest klarowna. Twórcy Java Mobile w sytuacji gdy inżynierowie Symbiana tworzą zręby pod zabezpieczenia ich systemu operacyjnego postanowili przejąc model wymagania podpisu w sytuacji dostępu do określonego API. Gdy liczba pakietów dostarczanych dla Java Mobile zacząła lawinowo rosnąć do ciała standaryzujacego, wymusiło to na producentach komórek wdrożenie mechanizmów bezpieczeństwa. W praktyce to polega na tym że każdy niepodpisany midlet w komórce nie może wykonywać potencjalnie niebezpiecznego API. W praktyce każdy producent urządzeń definiował to jakie API będzie wymagał podpisania.W praktyce wyszło że firma Verisign wdrożyła program Java Verified, któy miał podpisywac midlety Javy aby były one zaufane. Aby aplikacja Javy Mobile stała się zaufana to trzeba dokonać zakupu certyfikatu do podpisywania midletów typu PublisherID. Ten certyfikat jest inny niż ten który jest używany do podpisywania aplikacji Symbiana. Następnie trzeba zarejstrować się w programie Java Verified i wysłać podpisanym zakupionym certyfikatem w celu uzyskania podpisanej wersji zaufanej w celach testowych. W praktyce to oznacza że możesz w ciągu tygodnia czasu przetestowac aplikację w komórce majac dostęp do trusted API. Aby aplikacja Java Mobile mogła być uruchomiona w każdej komórce to jest potrzebne wysłanie midletu do organizacji testującej. Po opłaceniu testów otrzymujesz wynik testów i pliki midletu podpisane podpisem organizacji testujacej. I potem znowu z witryny w programie Java Verified otrzymujesz midlet podpisany który możesz już dystrybować aplikację.

Wkrótce sytuacja stała się taka, że wysokie koszta zaczęły generować ośrodki testujące aplikacje przed dopuszczeniem aplikacje Javy Mobile do oficjalnego podpisywania. Wystawiały one testy w zależności od ilości modeli komórek do przetestowania. Testy odpowiadały na pytanie czy aplikacja Java Mobile spełnia testy opisane w dokumencie Unified Testing Criteria (PDF). W tym przypadku głównym problemem okazał się dla większosci hobbystów i zaawansowanych użytkowników komórek fakt posiadania Publisher ID. Pośrednio to przyczyniło się do spadku zainteresowania technologiami Java Mobile przez programistów i zaawansowanych uzytkowników, w szczególności w Stanach Zjednoczonych co pokazują takie wpisy na blogach: Ivana Kuznietsova, czy J2MESecrets ( trochę nie bez powodu w Stanach Zjednoczonych komórki Nokii są mało popularne).

Z perspektywy czasu patrząc na rynek oprogramowania na Symbiana sytuacja jest dość dziwna. Restrykcyjne zasady tworzenia oprogramowania na Symbiana sprawiają że wiele osób chciałoby coś zaprogramować i udostępnić światu, muszą liczyć się z tym że mało ludzi umie podpisać aplikacje na Symbiana, czy wyrobić certyfikaty na własną komórkę. Obecnie w dobie popularności zaawansowanych komórek rośnie rola tych którzy łamią i obchodzą zabezpieczenia (dla Apple iPhone są to jailbreaki), natomiast w przypadku Symbiana oprogramowanie które dodaje dostęp do ukrytych folderów i jak wyłącza sprawdzanie uprawnień API podczas instalacji (np: HeliOX).

W komórce jest repozytorium certyfikatów są tam certyfikaty rożnych firm które otrzymały możliwość dodawania swojego certyfikatu jako zaufanego. Ale i tak hakerom czasami udaje się wgrać odpowiednie własne certyfikaty. Dodanie własnego certyfikatu sprawia że można podpisywać aplikacje własnym developerskim certyfikatem. Inną możliwością jest patchowanie pliku swpolicy,ini w plikach ROM (tak zwanej pamięci gdzie są przechowywane pliki potrzebne do uruchomienia podczas restartu). Głównie łamaniem komórek interesują Ci ludzie, którzy chcą mieć pełną kontrolą nad tym jak działa Symbian w ich komórkach.

Ponieważ Fundacja Symbiana widzi coraz większe zapotrzebowanie na rozwój ich aplikacji, pozostaje przed dylematem jak rozwiązać mechanizmy dystrybucji aplikacji. Obecny model miałby sens gdyby nie było certyfikatów deweloperskich. Sytuacja przypomniałaby sytuację twórców aplikacji na iPhone. Zakup certyfikatu PublisherId, a potem zakup hurtowej ilości ContentID jest nie do przyjęcia dla większości programistów którzy robią i piszą aplikacje dla własnych potrzeb.. W tej sytuacji korzystniejszym modelem byłoby "fundowanie" opensourcowych aplikacji poprzez PublisherId w zamian za to, że autor aplikacji może rozwijać się w tworzeniu aplikacji na Symbiana. Wystarczy jakiś system podobny do tego jak Git, gdzie system podczas rejestracji proponował podanie IMEI komórki użytkownika. W zamian za to że ktoś tam opublikuje kod źródłowy to otrzyma UID3. Jak użytkownik zamieści tam swoją niepodpisaną paczkę sis, to system wygeneruje certyfikat na IMEI komórki użytkownika. Inni użytkownicy, będą mogli sobie pobrać kod źródłowy i skompilować go u siebie a następnie odesłać razem z kodem na serwer w celu uzyskania podpisu. Opcjonalnie byłaby kompilacja kodu na serwerach (za opłatą oczywiście). W ten sposób może to się rozwijać w stronę IDE on line dla programistów. Wiadomo że ten model raczej będzie cieszył się uznaniem tych którzy będą mieli dostęp do podpisanych sisów rożnych wersji tego samego programiku. Z jednej strony taki otwarty model trzymania kodu źródłowego może zachęcić programistów do robienia swojej wersji programiku "Witaj Świecie" na komórki jak zobaczą jak wielu innych też dzieli się swoim kodem. Nokia dala już dostęp ludziom do kodów biblioteki Qt i fajnie jest jak potencjalni uzytkownicy mogą obserwować zmiany w kodzie źródłowym bibliotek Qt. Im więcej darmowego oprogramowania na Symbiana i tym więcej kodów źródłowych będzie korzystnie wpływać na wizerunek Symbiana i producentów komórek z Symbianem. Im więcej stron dla początkujących jak nauczyć się programowania na Symbiana C++ pisanych przez uczących się to tym lepiej dla wszystkich.

Qt for S60 - Tower

Jeszcze dobrze nie poznałem możliwości Qt for S60 "Garden" to już mamy kolejną wersję Qt for S60 "Tower" tak więc mamy już zaimplementowane następujące moduły: QtCore, QtTest, QtGui, QtNetwork, QtScript, QtSvg, QtXML

Do nowych API doszło: Phonon, QtSql and QtWebkit, obsługa softkeys i API do metod wprowadzania tekstu. Moduł Phonon jest w trakcie tworzenia i owszem można już pisać kod i go kompilować ale nie oznacza to że zadziała. Moduł QtSql opiera się na binarnej wersji pod SQLite3. Natomiast wersja QtWebkit jest dość eksperymentalna.

Warto przejrzeć Changelog, aby dowiedzieć się o największych zmianach w API i jak listę problemów z którymi mogą zetknąć się uzytkownicy nowszej wersji. Jedna z najciekawszych rozwiązań które zastosowano w tej wersji jest konwersja z poziomu makr C++ z tradycyjnego leaves z Symbiana na standardowe z C++ wyjątki.

Instalacja po stronie komórki wymaga odinstalowania poprzednich wersji Qt i jak bibliotek współpracujących. Przed instalacją nowszej wersji Qt for S60 trzeba zainstalować: pips_s60_1_5_5b.sis, openc_ssl_s60_1_5_5b.sis, stdcpp_s60_1_5_5b.sis. (są to biblioteki Open C++ i Open C).


Warto obejrzeć wprowadzenie do Qt for S60


i przykład jak zrobić pierwszą aplikację w Qt for S60


Pozostało poczekać na aktualizację Qt for S60 Developer Library na Forum Nokia i na nową wersję Mobility Extensions APIs.

Chinski Symbian

Szukając informacji o programowaniu na Symbiana S60 zauważam bardzo dynamiczny rozwój stron o programowaniu na Symbiana w języku chińskim. Duża w tym zasługa tego, że na rynku chińskim jest coraz więcej komórek z Symbianem. Ponieważ Fundacja Symbian przykłada duża uwagę do tego żeby w Chinach rozwijać programistów od Symbiana więc utworzono odrębną witrynę dla programistów z Chin. Fundacja także prowadzi chińskojęzycznego bloga. Najwięcej zasług zrobiła Nokia zakładając w Pekinie centrum badawczo rozwojowe. Chińczycy z Nokii prowadzą badania nad nowym interfejsem użytkownika i nad interakcją z otoczeniem (ang. rich context modeling). W tym centrum pracują tacy badacze jak Zhen Liu, Xia Wang, Jilei Tian, Kongqiao Wang, Hao Wang, Zhanjiang Song, Jian Ma. Obecność tych badaczy w centrum badawczo rozwojowym sprzyja dobrym kontaktom na poziomie uniwersyteckim. Takim uniwersytetem w Chinach, który bierze udział w pracach badawczych i edukacji studentów jest Uniwerytet Tsinghua. Zainteresowanie Symbianem wśród programistów jest bardzo duże o czym mogą świadczyć prężnie działające fora dyskusyjne Forum Nokia w języku chińskim. Nie da się ukryć faktu, że Chińczycy lubią łamać zabezpieczenia czy dostarczają reszty światu certyfikaty developerskie. Efektem takiej sytuacji jest też, że sporo Chińczyków pisze na swoich blogach o programowaniu na Symbiana. Przykładowe blogi na których pisze się po chińsku o programowaniu: 颠三倒四的传说, Zhang Lei, milefo95, 郭先东, 我的博客, simbalg, 松林的博客- songlin0512, 亚北 - guanyabei1981, hzb1983, Corner Boy鐨勫涔犳棩蹇 - richiechyi, 忆云 - lwr0312, poseidonwain, mindy1978, lunix-w, wenly8384, 非藉秋风 - shixuehuiab, c_linuxsymbian, 福音使徒 - fuyinshitu, fhz1980 i wiele innych.

Czuję pewien respekt, że skoro Chińczycy tak chętnie prowadzą blogi o tym jak uczą się programowania na Symbiana C++ to jednak mam niedosyt odpowiedników angielskojęzycznych takich, które by na przykład do znudzenia pisały o budowie HelloWorld w Symbian C++ czy o idiomach w kodowaniu. Jeszcze podziwiam tempo w jakim oni piszą i uczą się Symbiana C++. Godne podkreślenia jest to, że chętnie piszą o tym w swoim ojczystym języku nie podporządkują się modzie pisania po angielsku, bo piszą o tym dla swoich. Mają szacunek do tradycji i swojego języka.

Problemy z Carbide.c++

Faktycznie, mogłem się spodziewać dość dużego zainteresowania poprzednim wpisem. Rzecz w tym że sporo zapytań dotyczy problemu pierwszych kroków z pracą na Carbide.C++. Istnieje pewien problem dla wszystkich rzeczy wspólny:

zainstalowanie niewłaściwej wersji Perla
zainstalowanie niewłaściwej wersji S60 SDK
niepoprawnie działanie kompilatora
brak rejestracji emulatora z S60 SDK
niepoprawne skonfigurowanie Carbide.C++
brak ścieżek do zmiennej środowiskowej PATH

Jeżeli już ktoś instalował i mu nie działa, albo kiedyś tam instalował i potem "wrócił" to musi sprawdzić czy wszystko działa z linii poleceń. To wtedy będzie oznaczało, że problem jest po stronie Carbide.C++. A co się stanie jak kompilator nie skompiluje? Albo emulator nie zechce uruchomić się?. Trzeba wszystko przeinstalować ponownie. Z apletu dodaj i usuń programy usuwamy (znakami xxx oznaczam to że mogą być różne wersje):

Carbide.c++ xxx
CSL ARM Toolchain (arm-symbianelf) 2005-Q1C
S60 3rd Edition xxx SDK for Symbian OS
Active Perl x.x.x Build xxx

Istotne jest też usunięcie fizyczne folderów gdzie to były rzeczy zainstalowane (przy założeniu że wszystko jest na C: na Windows XP bo na Windows Vista jest trochę inaczej):
C:\Program Files\Nokia\Carbide.c++ v2.0\
C:\Program Files\Common Files\Symbian\
C:\Program Files\CSL Arm Toolchain\
C:\Symbian\
C:\Perl\

Rejestrujemy się na Forum Nokia, login i hasło przyda nam się potem przy rejestracji emulatora i przy ściąganiu SDKów.

Najpierw instalujemy ActivePerl 5.6.1.638, potem Carbide.C++ 2.0 Podczas instalacji Carbide.C++ wybieramy wersję Developer, (wersji Professional i OEM nie polecam początkującym). Po instalacji nie uruchamiamy go jeszcze. Następnie instalujemy któreś S60 SDK. Użytkownicy Windows Visty muszą zainstalować wersję co najmniej S60 3rd Edition FP2 SDK for Symbian OS. Podczas instalacji S60 SDK zostaniemy poproszeniu o zainstalowanie CSL Arm Toolchain. Użytkownicy Windows Visty mogą otrzymać komunikat o tym że do kompilacji potrzebne jest używanie odpowiedniego pliku wsadowego. Im też polecam dodanie do zmiennych środowiskowej PATH pewnych wartości ( z tej strony).

Teraz możemy uruchomić Carbide.C++. Pierwszą rzeczą jest poprawne skonfigurowane IDE do kompilacji. Najpierw możemy uruchomić
Start -> Programy -> Carbide.c++v2.0 -> Configure environment for WINSCW command line.
Ten plik wsadowy konfiguruje emulatora do pracy z Carbide.c++
Teraz możemy uruchomić Carbide.C++
Start -> Programy -> Carbide.c++v2.0 ->Carbide.c++v2.0
Uruchaniając IDE trzeba pozmieniać pewne domyślne ustawienia. Z menu Carbide.c++v2.0 wybieramy Windows -> Preferences. Pojawi się okno Preferences, po lewej stronie mamy takie drzewko i wybieramy stamtąd węzeł Carbide.c++ i podwęzeł Platform Filtering Preferences.
Przy EKA2 Platforms pozostawiamy tylko Emulation (WinSCW) i GCCE (wszystko co ma w nazwie ARM odznaczamy).
Następnie sprawdzamy czy Carbide.C++ wykryło odpowiednią wersję S60 SDK to wybieramy węzeł SDK Preferences i tam mamy listę zainstalowanych SDKów.
Zamykamy i uruchamiamy z menu Carbide File -> New -> Symbian OS C++ Project i pojawi się okno z którego wybieramy węzeł S60 -> GUI Application i przechodzimy krok po kroku wszystkie okna kreatora.
Jak kreator zrobi całą strukturę folderów to w menu wybieramy Project -> Build Configuration -> Manage... to pojawi się okno Add/Remowe Carbide Build Configuration i zaznaczamy tylko Emulator Debug i Phone Release dla SDK którego chcemy użyć.
Zanim zaczniemy kompilację to trzeba będzie ustawić zakładkę Console na aktywną i wybrać z menu Projekt Build All Configurations. Wtedy Carbide.c++ skompiluje kod na wersję na komórkę oraz zrobi paczki w folderze sis a także zrobi wersję binarną dla emulatora. Komunikaty podczas kompilacji można zaobserwować w zakładce Console. Aby uruchomić emulator trzeba wybrać z menu Run ->Run. Po kilku minutach uruchomi się emulator wraz zaleceniem żeby zarejestrować go. W tej sytuacji trzeba podać hasło i login do forum Nokii.
Trzeba liczyć się z tym że przy każdym uruchamianiu emulatora może pojawiać sie komunikat Alertu zabezpieczeń systemu Windows o pozwolenie na uruchamianie aplikacji w emulatorze.
Po uruchomieniu emulatora klikamy w przycisk menu i pojawi się widok Menu i wtedy trzeba przejść do ikonki Installations. w po wybraniu powinno widać tą aplikację.
W folderze sis znajduje się plik *.sisx tej aplikacji, który możemy wgrać na komórkę.

Symbian C++ z linii polecen

Od pewnego czasu rośnie mi ilość ludzi którzy wpadają do mojego bloga, żeby poczytać o programowaniu na Symbiana. Fakt że niewielu w Polsce ludzi zna się na programowaniu na Symbiana. Myślę, że coraz więcej ludzi będzie chciało poznać to jak programuje się na ich komórkę. Symbian w zależności od wersji która jest zainstalowana w komórce to ma różne możliwości. W tej sytuacji największe możliwości mają programiści C++, którzy dzisiaj mogą programować w Symbian C++, OpenC, OpenC++ i od niedawna w Qt for S60.
Większość ludzi myśli, że jak zainstalują oprogramowanie IDE np: Carbide.C++ to od razu będą mogli już pisać kod i testować aplikacje, zakładając, że wszystkie działania zostaną podjęte przez środowisko programistyczne. Tutaj mogą się spodziewać problemów z pracą w Carbide.C++ ponieważ nie znają tego jak działa cały proces tworzenia aplikacji do Symbiana.

Warto jest poświęcić sporo czasu na zrozumienie tego.
Najpierw istotna jest kolejność instalacji. Instalujemy wszystko na jednym dysku w miarę możliwości. Ja wybrałem dysk E. W tej sytuacji przyda się bardzo duży dysk twardy. W praktyce zainstalowanie wszystkich SDK czy IDE używanych do programowania na komórkę zajmie w sumie kilkadziesiąt GB danych i trzeba poświecić na to sporo czasu. Oczywiście że zakładam że instalujemy to na Windows XP. Windows Vista wymaga dodatkowej pracy przy konfiguracji.

Najpierw trzeba zarejestrować się na Forum Nokii
Pobieramy wersje instalacyjne i instalujemy po kolei:

Carbide.C++ 2.0 zainstalowało mi się to na E:\Program Files\Nokia\Carbide.c++ v2.0
ActivePerl 5.6.1.638 - zainstalowałem to na E:\Perl
Paczki z S60 SDK
SDK S60 3.2 (razem z kompilatorem gcce dla ARM), SDK S60 5.0, SDK S60 for N97
Z tych paczek zainstalowały mi się w E:\Symbian, skrypty kompilacyjne na C:\Program Files\Common Files\Symbian, a kompilator na E:\Program Files\CSL Arm Toolchain
Potem polecam ściągnięcie Qt 4.5 for Windows (zawiera QtCreator), który zainstalował mi się w E:\qt\2009.02\ , oraz pobrałem Qt for S60 "Garden"

Ponieważ teraz już wszystko zainstalowane to trzeba sprawdzić czy działają polecenia z linii poleceń.

Robimy plik r.bat a w nim piszemy cmd i zapisujemy go w
E:\Symbian\9.3\S60_3rd_FP2\S60Ex\HelloWorld
uruchamiamy go: wpisujemy perl -v
powinno być informacja że mamy wersję

This is perl, v5.6.1 built for MSWin32-x86-multi-thread
Binary build 638 provided by ActiveState Corp.

Jeżeli nie pojawi się informacja to trzeba dodać do zmiennych środowiskowych PATH ścieżkę E:\Perl\bin\

Następnie wpisujemy polecenie: devices
Pojawi się się lista SDKów jakie mamy zainstalowane, istotna jest wiedza który z nich jest domyślny, bo to zależy który emulator i które SDK bierze udział w procesie tworzenia aplikacji. Brak rozeznania może spowodować tym że emulator nie zechce działać dobrze.

Gdyby okazało się że to polecenie nie działa (co jest mało prawdopodobne w sytuacji gdy dobrze zainstalowaliśmy SDKi) to oznacza że trzeba ponownie zainstalować albo dodać ścieżkę do zmiennej środowiskowej PATH C:\Program Files\Common Files\Symbian\Tools

Kompilatory GCCE dla ARM pod Symbianem są zainstalowane w E:\Program Files\CSL Arm Toolchain\bin tak więc trzeba sprawdzić czy ta ścieżka jest w zmiennej środowiskowej PATH.

Pozostało sprawdzenie czy zainstalowaliśmy Qt 4.5.1 to wpiszemy qmake -h wtedy pojawi się pomoc do polecenia qmake. Jeżeli to polecenie nie dało wyników to trzeba poszukać pliku E:\qt\2009.02\bin\qtenv.bat i uruchomić go. W sytuacji gdy uruchomienie tego pliku nie dało efektu dla qmake -h to należałoby ręcznie wprowadzić zmienne środowiskowe

QTDIR=E:\Qt\2009.02\qt
Zmienne które należy dopisać na początku
PATH=E:\Qt\2009.02\bin;E:\Qt\2009.02\mingw\bin;
i zmienną
QMAKESPEC=win32-g++

Następna rzecz to wypakowanie paczki z Qt 4.5 for S60 "Garden" w E:\Qt\4.5.0-garden
Dodajemy do zmiennej środowiskowej PATH kolejną ścieżkę na początku E:\Qt\4.5.0-garden\bin

Aby się upewnić że emulatory z SDK są poprawnie zainstalowane trzeba przed konfiguracją Qt for S60 sprawdzić. W tym celu warto sprawdzić to tam gdzie jest zainstalowane Carbide.C++ i uruchomić ten plik: E:\Program Files\Nokia\Carbide.c++ v2.0\configuration\run_env_update.bat

W folderze E:\qt\4.5.0-garden robimy plik c.bat z tekstem cmd oraz plik b.bat z tekstem configure -platform win32-mwc -xplatform symbian-abld
i zapisujemy a następnie uruchamiamy c.bat i wpisujemy b.bat i następuje konfiguracja środowiska Qt pod kątem kompilacji tego na Symbiana

Następnym krokiem jest wypakowanie plików Qt for S60 do odpowiedniego SDK Do 3.x S60 SDK zawartość z E:\qt\4.5.0-garden\qts60binaries\3.x\qtlibs-4.5.0-garden.exe wypakowujemy do E:\Symbian\9.2\S60_3rd_FP1_2\ Natomiast zawartość E:\qt\4.5.0-garden\qts60binaries\5.0\qtlibs-4.5.0-garden.exe wypakujemy w E:\S60\devices\S60_5th_Edition_SDK_v1.0\

Właściwie teraz już zainstalowaliśmy to co jest potrzebne w pracy. Zanim przejdziemy do konfiguracji Carbide.C++ trzeba sprawdzić jak będzie wyglądała kompilacja z linii poleceń.

Prawie każdy projekt Symbiana C++ składa się z odpowiedniej struktury podkatalogów:
group - tam są pliki odpowiedzialne za strukturę projektu bld.inf i *.mmp
inc - są tan pliki nagłówkowe dla projektu w C++
src - są tam kody źródłowe w C++
data - są tam pliki zasobów odpowiedzialne głównie podczas tworzenie wersji wielojęzycznych i jak też opisują budowę UI
gfx - przechowuje pliki graficzne
sis - zawiera pik *.pkg z którego można stworzyć pliki sisx (z podpisem)
Opcjonalnie mogą być podfoldery:
doc - zawiera dokumentację projektu
help - zawiera informacje potrzebne do wygenerowania pliku pomocy który będzie instalowany razem z aplikacją

W tej sytuacji warto zobaczyć to na przykładzie E:\Symbian\9.3\S60_3rd_FP2\S60Ex\HelloWorldBasic

Wchodzimy w E:\Symbian\9.3\S60_3rd_FP2\S60Ex\HelloWorldBasic\group
a tam trzeba zrobić plik wsadowy c.bat z poleceniem cmd i zapisać go
robimy następny plik b.bat z poleceniem bldmake bldfiles
a w końcu plik k.bat z poleceniem abld build gcce urel. Uruchamiamy plik c.bat potem wpisujemy b.bat i uruchamiamy. Pojawi się plik ABLD.BAT, następnie wpisujemy k.bat. Zaczyna się właściwa kompilacja. W efekcie skompilowane pliką są w E:\Symbian\9.3\S60_3rd_FP2\Epoc32\release\gcce\urel\HelloWorldBasic.exe
pliki zasobów są w
E:\Symbian\9.3\S60_3rd_FP2\Epoc32\data\z\resource\apps\HelloWorldBasic.rsc
natomiast plik z informacją o grafice jest w E:\Symbian\9.2\S60_3rd_FP1\Epoc32\Data\z\resource\apps\helloworldbasic_aif.mif

Man nadzieję, że kompilacja poszła gładko pomimo, że wyświetlało w oknie dużo komunikatów o ostrzeżeniach.

Kolejna rzecz to zrobienie sobie paczki instalacyjnej. W folderze sis przeważnie jest plik *.pkg, który zawiera informacje o tym co ma być w tej paczce.

W folderze sis jest helloworldbasic_gcce.pkg trzeba zrobić plik c.bat z poleceniem cmd a następnie drugi plik b.bat z poleceniem makesis helloworldbasic_gcce.pkg. uruchamiamy plik c.bat a następnie wpisujemy b.bat wykonujemy go. Zrobił się plik helloworldbasic_gcce.SIS.

Z tym plikiem trzeba jeszcze podpisać. Następnie trzeba sobie postarać się o certyfikat developerski albo samemu sobie go wygenerować

Jak się ma pliki certyfikatu self-sign lub certyfikatu developerskiego *.cer i *.key w tym folderze to można sobie zrobić plik p.bat z następującym poleceniem

signsis -s helloworldbasic_gcce.SIS helloworldbasic_gcce_pod.SISX 305978-306701.cer 305978-306701.key 12345

Po uruchomieniu pliku p.bat powinno pojawić się plik helloworldbasic_gcce_pod.SISX i ten plik można by sobie spokojnie zainstalować w komórce.

Na koniec "wyczyścimy" to co zrobiliśmy. W folderze E:\Symbian\9.3\S60_3rd_FP2\S60Ex\HelloWorldBasic\group zrobimy plik u.bat z poleceniem abld reallyclean gcce urel . a następnie wykonamy go.

Ten powyższy przykład dotyczył tego jak sprawdzić czy wszystkie podstawowe narzędzia do kompilacji działają. Z punktu widzenia programisty istotne jest sprawdzenie czy kod który napisał zadziała w emulatorze. W folderze E:\Symbian\9.3\S60_3rd_FP2\S60Ex\HelloWorldBasic\group zrobimy plik w.bat z poleceniem abld build winscw udeb
, a następnie wykonamy go. Skompilowaliśmy przykład dla kompilatora. Kolejną rzeczą jest uruchomienie emulatora. W tym folderze robimy plik e.bat z poleceniem epoc i wykonujemy go.
Zostanie uruchomiony emulator. W tym emulatorze wciskamy klawisz menu, a potem przewijamy do Instalations i wtedy to wybieramy ikonkę HelloWorldBasic

Jak już jestęsmy z tego zadowoleni to po zamknięciu emulatora możemy wyczyścić to poleceniem abld reallyclean winscw udeb i w ten sposób mamy porządek w emulatorze.


Warto też sprawdzić jak kompiluje się z linii poleceń projekty Qt for S60:
Wejdziemy w E:\qt\4.5.0-garden\examples\script\context2d i zrobimy w nim plik c.bat z poleceniem cmd i uruchamiamy go. Wpisujemy qmake. To polecenie wygeneruje nam wszystkie potrzebne pliki do kompilacji. Następnie wpisujemy make release-gcce i skompilujemy swój kod. Następnie trzeba zrobić paczkę do zainstalowania w komórce. Wpisujemy createpackage -i context2d_gcce_urel.pkg

Po zainstalowaniu odpowiedniej wersji biblioteki Qt for S60 na komórkę E:\qt\4.5.0-garden\qts60binaries można zainstalować skompilowaną paczkę context2d_gcce_urel.sisx
Na koniec warto sobie wyrobić nawyk sprzątania po kompilacjach i wpisujemy make distclean i wykonujemy to.

To wszystko powinno wystarczyć żeby upewnić się czy cały proces tworzenia aplikacji jest dobrze skonfigurowany i wtedy można przejść do konfiguracji Carbide.C++

Przyszłość Symbiana

Zakup wszystkich udziałów w firmie tworzącej system operacyjny Symbian przez Nokię, a potem przekształcenie firmę w fundację odpowiedzialną za rozwój tego systemu to tendencja bardzo korzystna. A także wzięcie kredytu od europejskiego banku na rozwój tego systemu. W sytuacji gdzie wszyscy rywalizują o to który system będzie coraz bardziej popularny zależy od programistów i zaawansowanych użytkowników. Media mają znaczenie, o tyle ile posiada się dobrze zorganizowany dział marketingowy, który odpowiada za promocję.

W tej sytuacji wobec konkurencji ze strony Google (Android) Apple(iPhone), Microsoft (Windows Mobile) Fundacja Symbiana musi prowadzić kampanię agresywną skierowaną dla developerów Symbiana. Problem w tym że Symbian nie ma zbyt wyraźnej marki, która by wyróżniała wobec konkurencji. Od tego powinni wyjść żeby programiści chętnie pisali o tym systemie na blogach, na forach dyskusyjnych, w serwisach społecznościowych. Wykorzystując potencjał informacji z Forum Nokia pozwoli to na lepszą komunikację pomiędzy programistami i ludźmi zainteresowanymi tymi technologiami. Głównym kanałami komunikacji tak naprawdę stały się blog Facebook i Twitter. Wprowadzenie nowej witryny internetowej fundacji wraz z nową witryną dla programistów (w wersji beta) sprawi że w przyszłości ciężar dyskusji będzie przesuwał się na stronach forum dla programistów Symbiana, bądź dojdzie do integracji z Forum Nokii (bardziej zależy to od rozwoju Wiki ze strony ochotników).

Jednak w odróżnieniu od konkurencji postanowiono dostarczyć mapę drogową rozwoju Symbiana. Jedną z tych cech jest zmiana nazewnictwa kolejnych wersji. Obecna aktualna wersja Symbian 9.4 po połączeniu z S60 edycji 5 otrzymuje nazwę Symbian^1 . Ma to pokazać iteracyjność powstawania kolejnych wersji Symbiana oraz przejrzystość tego czego mają się spodziewać programiści w ciągu następnych 3 lat.

Symbian^2 będzie miał możliwość obsługę widgetów prosto z poziomu interfejsu systemu (obecnie widgety są uruchamiane jako programy). Teoretycznie będzie możliwe uruchamianie tego systemu na dowolnym wyświetlaczu VGA. Producenci pokażą komórki z S60 edycji 5.1 na końcu tego roku, a klienci będą mogli kupować komórki w 2010 roku.

Symbian^3 będzie opierał się na koncepcji zwanej Screenplay która zakłada używanie OpenVG, sprzętowej akceleracji grafiki 2D, nagrywania video wysokiej jakości 720p HD, kontekstową wykorzystanie GPS, obsługę wielokanałowego dźwięku. W praktyce pierwsze tego komórki pojawią się w drugiej połowie 2010 roku, a rynek dopiero to przyjmie w 2011 roku. Interesujące byłoby uruchamianie Symbiana w laptopach z procesorem ARM w tym czasie. Przypuszczam że perspektywa tego co będzie w Symbianie^4 może skłonić do migracji z Linuksa na Symbiana.

Symbian^4 przypuszczam że będzie miał już zupełnie inna architekturę opartą na Qt4.6 wraz z rozszerzeniem zwanym "Orbit UI" który będzie pozwalał programistom tworzenia zaawansowanych aplikacji działających podobnie jak strony internetowe, czy aplikacje RIA. Dojdzie do tego zmiana wyglądu aplikacji który będzie bardziej opierał się na silniku 3D dla UI zwanym "DirectUI", a użytkownik będzie mógł przełączać się pomiędzy widokiem 3D a tym tradycyjnym.
Pierwsze rozwiązania zostaną pokazane pod koniec 2010 roku, natomiast na rynek wprowadzą pod koniec 2011, a ludzie zaczną używać w 2012 roku.

Przypuszczam że może dojść do dość dziwnej sytuacji w której kod napisany w Qt 4.6 może działać w poprzednich wersjach Symbiana ale trzeba będzie inaczej kompilować pod określone procesory (ARM czy Atom Intela, czy rozwiązania Nvidii / AMD dla OLPC). Gdyby inżynierom Symbiana udało się zrobić dystrybucje Symbiana praktycznie na każdy procesor, to przypuszczam że stałby się dość interesującą alternatywą dla Linuksa.

Tego czego najbardziej mogę dzisiaj spodziewać to duże zainteresowanie tym jaki będzie nowy interfejsu użytkownika w komórkach na bazie powstającej dzisiaj biblioteki Qt for S60. A pośrednio też tworzenie nowych aplikacji w C++ pod Qt. Jakbym spodziewał się większego zainteresowania tworzeniem aplikacji w Qt ze względu zmianę licencji i szukania innego rozwiązania niż platforma .NET czy Java.

Diagnostyka samochodowa

Od dłuższego czasu oprócz możliwości programowania w komórkach interesuję się też tym jakie możliwości programistyczne są w samochodach. Na razie jeszcze nie ma wersji Symbiana, która by zarządzała informacjami z układów w samochodach. Jedyne to co mogę zrobić to dokonywać diagnostykę w samochodach. Tutaj trzeba wiedzieć gdzie jest port OBD2, podłączyć kabel diagnostyczny i rozpocząć komunikację z układami kierowniczymi w samochodzie.

Najciekawszą rzeczą jest to że obok standardowego zestawu danych każdy producent samochodu może zawierać dodatkowe kody diagnostyczne i trzeba tylko wiedzieć jak można wysyłać dodatkowe polecenia. Na razie według mnie najlepszą bazą kodów diagnostycznych dysponuje program VAG-COM firmy Ross-Tech. Cała rzecz opiera się na tym żeby skorzystać z tego programu trzeba zakupić sprzęt czyli kabel diagnostyczny, który w wersji dla profesjonalistów kosztuje 899 dolarów. Tak naprawdę największą wartością jest baza 12000 kodów diagnostycznych. Pomimo, że w internecie jest już baza 7597 kodów. Ten program jest rozwijany już klika lat. Ale okazuje się, że coraz ważniejsze staje się na bieżąco dokonywanie auto diagnostyki samochodu w którym się jeździ. Z prostego powodu im więcej elektroniki i czujników tym większe prawdopodobieństwo awarii. Warto na bieżąco wiedzieć co się dzieje z elektroniką w samochodzie, a nie tylko w momencie awarii. Skoro istotne jest dokonywania diagnozy swojego samochodu to warto zaobserwować na rynku wysyp różnych urządzeń diagnostycznych skanerów OBD2 opartych na komunikacji z Bluetoothem gdzie odpowiednie oprogramowanie w komórce odbiera, komunikuje się z tym skanerem. Przykładem takiego urządzenia Elmscan 5 Wireless Bluetooth, jednakże kupowanie takich urządzeń ma sens jak mamy pewność, że te dane które otrzymamy wystarczą nam. Często jest tak, że wymieniamy części na nowsze i wtedy może okazać się że trzeba kupić nowy skaner z nową bazą kodów. W tej sytuacji można skonstruować własny skaner OBD2. Podzespoły do elektroniki są w miarę tanie. To co trzeba zrobić to zaprojektować układ który będzie pełnił tą rolę i oczywiście zaprogramować. Obecnie na rynku są dostępne mikroprocesory takie jak AVR czy 8058 dodatkowo wystarczy kupić układ Rayson BT, zrobić płytkę z wyjściem do komunikacji z portem OBD2. To co trzeba zaprogramować w AVR Studio kod który będzie kierował komunikacją z portem i jak z BT. Otóż komunikacja może obywać się na różnych protokołach. W diagnostyce samochodowej takimi protokołami są KWP-2000, KWP-6000 (CAN), KWP-7000(UDS). Znajomość budowy tych protokołów wystarczy do zaprogramowania mikroprocesora. Warto poczytać o tym z niemieckojęzycznej strony. Są też kody źródłowe do mikroprocesorów z których można by zanalizować pod kątem tego jak programuje się protokoły komunikacji Obdchip, Micronics czy Stern Technologies. Zrobienie takiego zestawu pozwoli na samodzielne badanie nowych kodów, z tego powodu że będzie można tworzyć własną bazę kodów diagnostycznych.

Jednak jest już dostępny układ scalony elm 327, który można sobie przystosować do zaprogramowania protokołów komunikacyjnych OBD2 na poziomie poleceń AT (w praktyce można poszukać sobie już gotowego rozwiązania z układem BT).

Od marca 2009 roku jest rozwijany opensourcowy projekt SymBtELM przez Owena Brotherwooda, Jest to skrypt napisany w Pythonie na Symbiana. Dzięki temu układowi elm 327 i modułowi BT można by nawiązać komunikację z komórką.

Podobny projekt rozwijają też Brazylijczycy tworząc aplikację do tego samego celu w Pythonie dla Symbiana i interfejs użytkownika w WebRuntime (WRT).

Byłem zainteresowany napisaniem takiego programu do komunikacji z komórkami, ale brak obeznania w programowaniu w elektronice i fakt, że do elektroniki trzeba mieć dobre wyczucie w precyzji. Trzeba wiedzieć jak zaprojektować płytkę, jak wygląda lutowanie, a potem używanie programatora, co to są fusebity. Do dobrego pomiaru danych w transmisji w celu sprawdzania działania komunikacji w danym protokole dobrze przydałby się oscyloskop. To wszystko jest interesujące, ale biorąc pod uwagę swoją niepełnosprawność to raczej zajmowanie się tym wszystkim w pojedynkę przekracza moje możliwości.