Szybki wstęp do programowania PalmOS, AD2003
Oczywiście temat programowania dla platformy PalmOS jest ogromny, dlatego pisząc ten artykuł przyjąłem kilka założeń.
Po pierwsze: środowisko pracy będziemy organizowali pod systemem Windows (jeśli uważasz, że Windows śmierdzi, poczekaj a w dalszej części przerobimy go na UNIXa :).
Po drugie: będziemy bazowali na jak największej ilości darmowego i łatwo dostępnego oprogramowania (tematy: CodeWarrior i Falch.net traktujemy tymczasowo jakby ich nie było).
Po trzecie: nastawiamy się, że będziemy kodować w ANSI C lub C++, tak jak to twórcy systemu PalmOS przykazali (nie zaprzeczam, że można pisać w językach innych, być może znakomitszych)
Po czwarte: w tym artykule dowiesz się nie tylko, co masz zainstalować i co w tym celu masz uczynić, ale także, co to jest i po co to robisz - innymi słowy - wszystko to, do czego namawia Cię ten artykuł, wykonasz z pełnym zrozumieniem, choćbym musiał Ci to wytłumaczyć na chłopski rozum.
Co będziemy potrzebowali - ogólnie.
Do tworzenia aplikacji będziemy potrzebowali następujących komponentów:
1 - Kompilator kodu źródłowego (C, C++; procesor Motoroli m68k)
Kompilator zasobów
2 - Software Development Kit (SDK) dla systemu PalmOS wraz z dokumentacją
3 - Emulator komputerków z systemem PalmOS + pliki ROM dla konkretnych platform
4 - Edytor dla kodu źródłowego
5 - Aplikację do projektowania zasobów
Co jest to?
ad. 1) Żeby z plików źródłowych C/C++ zbudować aplikację uruchamiającą się na komputerku Palm, potrzebujemy kompilatora obsługującego procesory Motoroli serii m68k. Nie jest więc to ten sam kompilator co w MS Visual Studio, czy kompilatory dostarczanie wraz z dystrybucjami Linuksa (to są kompiltory dla procesorów Intel x86 lub innych odpowiednich dla maszyny, na której został zainstalowany system). Kompilatory nam potrzebne są dostępne pod nazwą PRC-Tools i są w istocie przerobionym zestawem narzędzi z projektu GNU Compiler Collection.
PRC-Tools - strona domowa:
W momencie pisania tego artykułu dostępna jest wersja PRC-Tools 2.2 .
Od ostatniej wersji 2.0, PRC-Tools nie są już dostępne w postaci self-installera, a raczej jako pliki TAR (czyli bardziej po uniksowemu).
ad. 2) Plik .PRC (rozszerzenie programu wykonywalnego dla PalmOS) zawiera nie tylko instrukcje wykonywane przez system, ale również zasoby. Z zasobami należy utożsamiać formatki wyświetlane w aplikacji, menusy, teksty pomocy, grafiki, dzwieki, etc. Formatki w programie mogą być tworzone w locie przez kod programu, a mogą być przywoływane z zasobów, co jest znacznie wygodniejsze. Kompilator z zestawu narzędzi PRC-Tools jest w stanie zlinkować skompilowany kod programu ze skompilowanymi zasobami programu i potrafi wytworzyć końcowy plik .PRC, jednakże ktoś tych skompilowanych zasobów musi mu dostarczyć.
Z zasobami jest trochę jak z kodem programu. Kod programu może być napisany w każdym jednym języku. Tak samo formaty zasobów (tj. formaty wejściowe przed skompilowaniem) mogą być bardzo różne. Twórcy PalmOS i ich flagowe środowisko programistyczne CodeWarrior używają do zapisu zasobów binarnego pliku .RSRC (być może spotkasz się z nim przy okazji przeglądania jakiś przykładów dostarczanych wraz z SDK i nie będziesz wiedział, cóż z tym począć, a to właśnie zasoby). W świecie freeware'u niewątpliwie króluje produkt PilRC (Pilot Resource Compiler) Aarona Ardiri'ego. PilRC to tekstowy format reprezenatacji zasobów (pliki .RCP) i skojarzony z nim kompilator.
Oto kawałek definicji z pliku .RCP i odpowiadająca mu formatka wyświetlająca się w aplikacji.
FORM ID infoForm AT (2 2 156 156) MODAL
BEGIN
TITLE "About PilRC"
FORMBITMAP AT (8 16) BITMAP bitmapIcon
LABEL "http://www.ardiri.com/" AUTOID AT (52 PrevTop+4)
LABEL "Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript." AUTOID AT (54 PrevTop+11) FONT 1
LABEL "PilRC" AUTOID AT (15 PrevTop+8)
FORMBITMAP AT (88 PrevTop+14) BITMAP bitmapPalm
LABEL "Copyright 2000" AUTOID AT (8 PrevTop+10)
LABEL "Aaron Ardiri" AUTOID AT (8 PrevTop+12)
LABEL "All rights reserved" AUTOID AT (8 PrevTop+12)
LABEL "PilRC demo" AUTOID AT (8 PrevTop+20) FONT 1
LABEL "version 0.2beta" AUTOID AT (8 PrevTop+12) FONT 1
BUTTON "Ok" ID infoFormOkButton AT (CENTER 138 40 AUTO)
END
Oczywiście tworzenie formatego przez pisanie takiego kodu to żmudna praca, więc w dalszej części znajdziemy ku temu lepsze narzędzie.
Aarone Ardiri & PilRC - strona domowa:
W momencie pisania tego artykułu dostępna jest wersja PilRC 2.9 .
Wiele środowisk programistycznych dla PalmOS przechowuje swoje zasoby w plikach .RCP lub generują je na czas kompilacji programu.
ad. 3) Palm OS SDK (czyli Software Development Kit)
Wiemy już, że do skompilowania programu potrzebny jest kompilator znający się na budowie programu pod procesor taki jaki jest w Palmie. Ale kompilator, a przede wszystkim my, jako programiści, musimy wiedzieć nie tylko jaki procesor jest w Palmie, ale przede wszystkim jaki jest system i co on nam oferuje. SDK to właśnie taka paczuszka, w której z jednej strony jest coś do poczytania dla nas - programistów, z drugiej strony jest coś do poczytania dla kompilatora. Dla nas jest to wielotysięczna pod względem ilości stron dokumentacja. Niech ilość stron Was nie przeraża - ładnie poindeksowane PDFy to jest coś, co się ceni (przyda się drugi monitor do ich wyświetlania, co czyni akt programowania bardziej komfortowym). W dokumentacji do SDK jest napisane, jakie funkcje systemu są dla nas dostępne (w szczególności z zaznaczeniem, w których wersjach systemu się pojawiły - trzeba będzie to uwzględniać, jeśli chce się utrzymać kompatybilność ze starszymi komputerkami Palm) oraz informacje ogólne o budowie systemu i generalnie o tym, jak aplikację należy pisać. Odpowiednikiem tego co jest napisane w dokumentacji, są pliki nagłówkowe i wiązane na sztywno biblioteki (a więc nie te, które są współdzielone i dawno znajdują się w pamięci naszego komputerka, ale te, które są za każdym razem dołączane do binariów naszej nowej aplikacji). To pozwala kompilatorowi sprawdzić, ujmując po macoszemu, czy kod naszego programu odwołuje się do faktycznie istniejących funkcji w systemie i czy odwołuje się do nich poprawnie (kontrola typów, itd.).
SDK są wersjonowane, a numer ich wersji odpowiada wersji systemu, do którego zostały opublikowane. Musimy zdecydować, którego SDK będziemy używali do napisania i skompilowania naszego programu.
Czy jeśli napiszę program pod SDK4.0, czy będzie on działał na komputerkach z systemami PalmOS np. 3.0 - 3.5?
Tak, jeśli w kodzie programu nie zostaną użyte funkcje systemu, które pojawiły się dopiero w SDK4.0 - w dokumentacji te funkcje są wyraźnie zaznaczone.
Czy jeśli napiszę program pod SDK3.0, czy będzie on działał na komputerkach z PalmOS np. 4.0?
Tak, nowszy system zawiera w sobie wszystkie poprzednio dostępne funkcje.
Dlaczego więc niektóre stare programy nie chcą działać z nowszyi systemami?
W dokumentacji SDK zawsze jest wyraźnie podawane, że na przykład dana funkcja uwzględnia jakąś przyszłościową funkcjonalność (np. obsługi slotów kart pamięci, kiedy jeszcze na rynku takich produktów nie było), dlatego póki co trzeba jej podawać takie argumenty, a nie inne; wszelkie odstępstwa od dokumentacji mogą skończyć się jakąś przyszłą niekompatybilnością (nikt nie powiedział, że schodząc ze szlaku, nie dotrzesz do schroniska przed wszystkimi; nikt też nie gwarantuje, że na ścieżce, którą obrałeś nie spotkasz niedźwiedzia :)
Myślę, że na początek, do pierwszych projektów można obraź SDK w wersji 4.0 lub 3.5. Zagwarantuje to ogólną użyteczność aplikacji pod względem dostępnych platform oraz dobrą zawartą dokumentację.
PalmOS - strona domowa:
W chwili pisania tego artykułu na tej stronie dostępne są SDK do wersji 5.0 (pre-relase) oraz wszystkie poprzednie.
ad. 4) Emulator PalmOS i wszechposzukiwane pliki ROM
Emulator PalmOS (znany również pod nazwą POSE) to wirtualny komputerek Palm wyświetlany na naszym PC (win, linux, mac), na którym możemy uruchamiać i testować nową aplikację Palm. Dzięki emulatorowi możemy zapamiętać jakiś stan wejściowy systemu i szybko instalować nowe poprawione wersje aplikacji, testować ją, odrobaczać, itd. Testowanie aplikacji bezpośrednio na Palmie, było by zbyt dokuczliwe i czasochłonne (najpierw długi HotSync, potem resetowanie Palma po wpadce). Emulator pozwala robić screen shoty, ściągać z wirtualnego Palma bazy danych utworzone przez aplikację, przeprowadzić test idioto-odporności (emulator w ramach testu wykona kilkanaście tysięcy losowych operacji i ujawni wszelkie zaniedbania w kodzie, które mogą się przyczyniać do wyracania systemu).
Emulator jest również świetnym narzędziem, żeby sprawdzić jak nasza aplikacja zachowuje się pod różnymi wersjami systemu; na różnych kompuerkach; na ekranikach kolorowych, niekolorowych. Jednakże tutaj obnaża się zapotrzebowanie na wszechposzukiwane pliki ROM. Emulator do działania potrzebuje zawartość kostki ROM z komputerka Palm. Możesz ją ściągnąć ze swojego komputerkac za pomocą dostarczonych z Emulatorem programów (jeden na PC, drugi na Palma). To jednak pozwala Ci jedynie emulować komputerek, który posiadasz. Skąd wziąć natomiast inne pliki ROM?
Oficjalnym źródłem plików ROM jest sekcja Resource Pavilon na stronie domowej PalmOS. Dostęp do tej sekcji jest tylko dla zarejestrowanych programistów PalmOS. Podstawowa rejestracja jest bezpłatna, ale czasochłonna, gdyż faktycznie wymaga przesłania kilku papierów klasyczną pocztą ślimakową do USA i z powrotem. Nim dla zaspokojenia ciekawości dasz sobie przysłać zza oceanu wąglika do domu, pragnę uchylić rąbka tajemnicy i wylistować obecnie dostępne pliki ROM z Resource Pavilon (oczywiście nie będziesz mógł ich stąd pobrać). Dodatkowo jeśli na imię Ci Kuba lub podobnie do: Iraq, Iran, Libya, North Korea, Sudan, Serbia, Afghanistan lub Syria to i tak z ROMami nie wolno Ci mieć żadnych kontaktów, sorry! :)
Palm OS 1.0
Pilot 1000 & Pilot 5000 organizers. English, non-debug only.
Palm OS 2.0
PalmPilot Professional and PalmPilot Personal organizers. Language: English, with debug Professional ROM.
Palm OS 3.0
Palm III handheld. Languages: English, French, German, and Spanish, with a debug English ROM.
Palm OS 3.1
Palm III, IIIe, V handhelds and IBM Workpad. Languages: English, Japanese, French, German, Spanish, with debug English and Japanese ROMs.
Palm OS 3.2 (Palm VII)
English Palm OS 3.2 New York – non-EZ,
English Palm OS 3.2 US – non-EZ
Palm OS 3.5
English Palm VIIx and VII (EZ CPU),
English Palm VII (non-EZ CPU) DR2 prerelease
Palm OS 4.0
English All English Platform ROMs
EFIGS* All EFIGS Platform ROMs
Japanese All Japanese Platform ROMs
All All Platform ROMs
English Palm m505 ROM & debug ROM
Palm OS 4.1
English All English Platform ROMs (release)
English All English Platform ROMs (debug)
EFIGS* All EFIGS Platform ROMs (release)
EFIGS* All EFIGS Platform ROMs (debug)
Japanese All Japanese Platform ROMs (release)
Japanese All Japanese Platform ROMs (debug)
PalmOS 4.1.2 (contain Graffiti 2)
English and EFIGS Platform ROMs (release)
English and EFIGS Platform ROMs (debug)
oraz ROMy do HandSpringow:
Visor
Visor Prism, Platinum
Visor Edge
Visor Neo Pro
Treo 180
Treo 270
Treo 300
Treo GPRS
Uwaga! Firma przestrzega przed flashowaniem komputerków z ROMami dostępnymi na stronie - nie umiem powiedzieć, czym to grozi i czy na pewno się to nie uda.
Emulator - strona domowa:
wersje dostępne w chwili pisania tego artykułu to:
Emulator Application 3.5
Emulator Skins 1.9
Do emulowania HandSpringa jest potrzebny emulator dostarczany przez HandSpringa.
Palm OS 5, jest tematem osobnym, wymaga innego emulatora, wszystko dostępne jest na stronie PalmOS.
ad. 5 + 6) Edytor kodu i zasobów, czyli tak naprawdę IDE (Integrated Development Enviroment)
Naturalnie kodować można choćby w windowsowym Notatniku. Ale, żeby sprawnie pisać program przyda się dobrze zorganizowane środowisko programistyczne. Dobrze zorganizowane tzn. takie, z poziomu którego można by tworzyć kod, tworzyć zasoby (formatki), kompilować kod, odpalać emulatori debugować. Niestety takiego darmowego oprogramowania dostępnego nie ma. Sam proces kompilowania zapewne można pożenić z dostępnymi IDE innego przeznaczenia (w usenecie pojawiają się głosy odnośnie MS Visual Studio, czyli być może to samo dało by się zrobić np. z darmowym Bloodshed Dev-C++). Jednakże trzeba jeszcze mieć aplikacyjkę do budowania formatek.
Z tanich IDE dla PalmOS znam:
Monte Soft - PilotMag
najtańszy, użyteczny, ale potrafi być dokuczliwy, koszt 20$
Ole Grossklaus - VFDIDE
od 29EUR do 59EUR w zależności od udostępnionych funkcji, sprawia lepsze wrażenie od PilotMaga, ale jest już znacznie droższy i być może nie opłacalny w stosunku do Falch.net
Falch.net Developer Studio i PilRC Designer
z tego, co pamiętam, ten program był kiedyś dystrybuowany za friko, ale te piękne czasy minęły już bezpowrotnie
robi bardzo dobre wrażenie, integruje wszystkie potrzebne zabawki, wizualnie bardzo przypomina MS Visual Studio; korzysta ze wszystkich opisywanych w tym artykule narzędzi; wydaję się być trochę drogi (biorąc pod uwagę, że jest osadzony na open source'owym oprogramowaniu)
wersja podstawowa 129$
PilRC Designer (tylko projektowanie formatek) 29$
JEŚLI KTOŚ ZNA DARMOWĄ ALTERNATYWĘ APLIKACJI DO PROJEKTOWANIA FORMATEK TO NIECH ZARAZ DO MNIE PISZE, OK?!
Konfiguracja środowiska pracy
Teraz przystępujemy do zainstalowania tych wszystkich gratów. Wszyskie pliki, jeśli nie wskazano inaczej) są do pobrania z adresów wymienionych we wcześniejszej części artykułu lub z serwisu PalmPage.
1)
Zaczynamy od utworzenia katalogu C:/PalmDev/, gdzie będziemy trzymali narzędzia i projekty.
Jeśli masz własny pomysł na nazwę katalogu to zachowaj go dla siebie. Jakoś się tak przyjęło, że wszystkie narzędzia będą wypatrywały właśnie katalogu o takiej nazwie - jeśli chcesz uniknąć problemów podczas konfiguracji, zrób tak, jak napisałem albo przygotuj się na piekło ;)
2)
Zakładamy katalog na nasze projekty, czyli np. C:/PalmDev/projects/, (tutaj już dowolność)
3)
Instalujemy PilRC przez rozpakowanie pobranej paczki (pilrc_w32.zip) do katalogu C:/PalmDev/.
Uzyskujemy instalację w katalogu C:/PalmDev/pilrc-2.9/ (lub podobnie w zależności do wersji).
Możemy to teraz przemianować lub zlinkować na C:/PalmDev/pilrc/, co by było łatwiej w przyszłości podmieniać wersje na nowe - to taka metodologia unixowa. W Windows 2000/XP na NTFSie można robić hardlinki i symlinki. Do hardlinków wystarczy komenda fsutil, do symlinków trzeba mieć już jakiegoś Resource Kita albo wszechuzdolnionego FARa :) Od biedy mogą być zwykłe windowsowe 'Utwórz skrót do..'
4)
Instalujemy Emulator.
Tworzymy katalog C:/PalmDev/pose/ (lub C:/PalmDev/pose-3.5/ i linkujemy go do C:/PalmDev/pose/, analogicznie jak przy pilrc'u)
Rozpakowujemy paczkę 'emulator-win-35.zip' (numerek zależny od wersji).
Tworzymy podkatalog (lub znowu linkujemy) C:/PalmDev/Skins/ i do niego rozpakowujemy paczkę 'emulator-skins-1.9.zip'.
5)
Tworzymy katalog C:/PalmDev/ROM/.
Do tego katalogu rozpakowujemy paczkę z plikami ROM. Jeśli nie mamy takiej paczki ściagamy plik ROM z własnego Palma. Żeby ściągnąć ROM z własnego Palma, skorzystaj z narzędzi dostarczonych wraz z Emulatorem.
6)
Zainstaluj jedno lub więcej SDK, które Cię interesują. SDK są w postaci self-instalerów.
Po zainstalowaniu SDKów powinieneś mieć takie katalogi (w zależności od wersji).
C:/PalmDev/sdk-3.5/
C:/PalmDev/sdk-4/
Nie linkuj tych katalogów do postaci C:/PalmDev/sdk/ - wybór domyślnego SDK odbywa się inną drogą.
Jeśli dobrze zainstalowałeś SDK to znajdziesz jeszcze takie katalogi:
C:/PalmDev/sdk-4/include/
C:/PalmDev/sdk-4/lib/
to samo tyczy się pozostaływch wersji SDK
7)
Tworzymy katalog C:/PalmDev/doc/.
Tu umieszczamy wszelką dokumentację, a przede wszyskim PDFy dostarczone razem z SDK. Dokumentacja to podstawa wszelkiego działania - musi być pod ręką!
8) PRC-Tools i Cygwin (niespodzianka!)
Do tej pory było wszystko łatwe i mogłeś do tego szybko samemu dojść. Teraz będą przysłowiowe trzy schodki. Jak się teraz nie skupisz, to nic Ci się nie uda skompilować.
Musimy zainstalowac pakiet PRC-Tools. Pakiet PRC-Tools pracuje w środowisku Cygwin. PRC-Toolsy są pochodzenia uniksowego, dlatego będziemy teraz przerabiać nasze okienka na mroźny świat pingwinków Linusa Torvaldsa.
8a) Cygwin
Cygwin niegdyś dostępny był w postaci self-installera (publikowanego na stronie PalmOS). Jeśli takowego posiadasz - wyrzuć go. W postaci self-installerów były dostępne wersje beta tego środowiska, które miały tą dodatkową zaletę, że uwielbiały się na dzień dobry zwieszać.
Teraz pobieranie i instalowanie Cygwina odbywa się poprzez pobranie installera, który pobiera komponenty z Internetu i instaluje go na lokalnym komputerze (podobnie jak Microsoft publikuje nowe Internet Explorery).
Stwórz katalog tymczasowy, w którym zmagazynujemy pliki installera (np. c:/robol/cygwin/). Nie będziemy instalowali Cygwina bezpośrednio z Internetu, tylko najpierw zapiszemy wszystkie jego pakiety lokalnie, a potem będziemy dokonywali instalacji z lokalnego katalogu, bo jak się coś nie uda, to mmożna szybko próbę powtórzyć.
Wejdz na stronę http://www.cygwin.com .
Pobierz plik 'setup.exe' spod wszech obecnej ikonki 'Install Cygwin Now' i zapisz go w c:/robol/cygwin/. (jeśli spotkałeś się już z manierą nazywania katalogów roboczych c:/robol/ to serdecznie pozdrawiam :)
Uruchom 'setup.exe'.
Po ekranie powitalnym ('Dalej'), installer każe Ci wybrać spośród:
Install from Internet
Download from Internet
Install from Local Directory
Wybierz 'Download from Internet'.
Na następnym ekranie w pole 'Local Package Directory' wpisz nasz c:/robol/cygwin/.
Następny ekran będzie dotyczył możliwości połączenia przez proxy. Tu musisz wybrac sam, jak nie wiesz, po prostu wcińij 'Dalej'.
Następny ekran to lista mirrorów. Wybierz sobie jakiś. Ja gustuję w czeskich mirrorach, nie pytaj dlaczego.
Następnym ekranem będzie lista dostępnych pakietów. Default'owy zestaw całkowicie nam do szcześcia wystarczy - to około 8MB do ściągnięcia. 'Dalej'.
Teraz pakiety ściągają się na dysk lokalny. Potem instalator zakończy swe działanie.
Teraz ponownie uruchomisz 'setup.exe' i dokonasz instalacji właściwej.
Czyli 'Install from Local Directory', a potem 'Dalej', 'Dalej', 'Dalej' aż do skutku.
Instalator spyta na pewno, gdzie chcesz mieć zainstalowanego Cygwina. Choć niektóre tutoriale sugerują katalog C:/PalmDev/, to radziłbym pozostawić tak jak jest, czyli: c:/cygwin/.
Cygwin jest zainstalowany, pora go sprawdzić.
Odpalmy konsole systemową.
Start->Uruchom. Wpisz command (jeśli masz Win95/98/ME) albo cmd (jeśli masz WinNT/2000/XP) i ENTER.
Teraz w magicznym czarnym okienku ala DOS, musimy się dostać do katalogu cygwina i urochimć go.
cd c:/cygwin
cygwin
Uwaga! Twój windows zamienił się w uniksa! A tak naprawdę to tylko uniksowa powłoka rozpięta na framudze Twoich okienek.
W konsoli cygwinowej rządza komendy uniksowe i uniksowa logika dostępu do plików.
Jeśli znasz unixa/linuksa to dobrze. Jak nie to trudno - rób na głupa. Ta konsola nie będzie nam długo potrzebna.
napisz: mount i enter
na ekranie powinno pojawić się coś takiego:
C:/cygwin/bin/ on /usr/bin type system (textmode)
C:/cygwin/lib/ on /usr/lib type system (textmode)
C:/PalmDev/ on /PalmDev type system (textmode)
C:/cygwin/ on / type system (textmode)
c:/ on /cygdrive/c type user (textmode,noumount)
zauważ, że:
root-katalog (/) jest zmapowany na C:/cygwin/;
jesli napiszesz cd / to de facto działasz w katalogu C:/cygwin/;
jeśli chcesz się dostać do całego swojego dysku, to musisz zrobić cd /cygdrive/c;
Upewnij się czy został zmapowany katalog C:/PalmDev/ na /PalmDev. Narzędzia PRC-Tools, będa szukały tam SDK.
jeśli nie to napisz:
mount -tf C:/PalmDev /PalmDev
znaczenie opcji -tf (-t -f) zrozumiesz, gdy odwołasz się do helpa:
mount --help
gdyby coś nie wyszło, wiedz, że operacją odwrotną do mount jest umount.
Pozostaw sobie tak otwartą konsolkę cygwina i przejdź do punktu 8b.
8b) Instalujemy PRC-Toolsy.
PRC-Tools (wersja 2.2) są dystrybuowane w pliku o nazwie 'prc-tools-2.2-cygwin.tar.bz2'.
Pozostając jeszcze w okienkach przekopiuj sobie chwilowo ten plik do katalogu c:/cygwin/ - to znakomicie ułatwi nam pracę, jeśli uniksy, są Ci obce.
Powróć do konsoli Cygwina.
Przejdź do root-katalogu:
cd /
Poleceniem pwd (print working directory) możesz sprawdzić, gdzie naprawdę jesteś.
W tym katalogu jest nasz 'prc-tools-2.2-cygwin.tar.bz2'.
Żeby to sprawdzić, napisz:
ls (albo od biedy dir)
Rozpakuj 'prc-tools-2.2-cygwin.tar.bz2', czyli:
tar -jxf prc-tools-2.2-cygwin.tar.bz2
Jeśli nie lubisz wklepywać tasiemców, podpowiem, że klawisz TAB uzupełnia nazwy plików (czyli piszesz tar -jxf prc.. i w tym momencie naciskasz TAB i masz to co powyżej).
Tutaj mała uwaga dla strusiów pędziwiatrów, którzy wbrew wskazówką rozpakowali już 'prc-tools-2.2-cygwin.tar.bz2' po swojemu używając do tego WinZIPa lub WinRARa. Tak rozpakowane nie zadziała, a to przez dziwną konstrukcję montowań katalogów /usr/bin i /usr/lib, których tak naprawdę nie ma z punktu widzenia zwykłych windowsów. Rozpakowanie PRC-Tools z poziomu Windows utworzy te katalogi, ale zostaną one nadmontowane w momencie uruchamiania Cygwina i ich zawartość finalnie dostępna nie będzie.
PRC-Toolsy w tym momencie są już w zasadzie zainstalowane, ale pozostała do zrobienia jeszcze jedna rzecz. W PRC-Tools 2.2 ułatwiono życie programistą, zwłaszcza początkowym, którzy w dniu swojej inicjacji palm-os-owej są zalewani przez kompilator komunikatami o niemożności odnalezienia potrzebnych bibliotek. Otóż PRC-Toolsy potrafią sobie same przeszukać system pod kątem dostępnych SDK i wiedzieć na przyszłość, gdzie znajdują się wszystkie potrzebne zabawki.
Żeby zainicjować PRC-Toolsy, napisz:
palmdev-prep
powinno się pojawić coś na kształt tego:
Checking SDKs in /PalmDev
sdk-3.5 headers in 'include', libraries in 'lib'
sdk-4 headers in 'include', libraries in 'lib'
When GCC is given no -palmos options, SDK '4' will be used by default
Writing SDK details to target specs files...
...done
jeśli na doczepkę pojawiła się również linia treści:
palmdev-prep: installation problem: no prc-tools targets found
to znaczy, że jesteś strusiem pędziwiatrem - wymierz sobie karę cielesną i przeczytaj jeszcze raz punkt 8b.
9) Rozszerzenie ścieżki wyszukiwania
Żeby środowiska programistyczne dla PalmOS mogły łatwo odnaleźć swoje kompilatory, powinieneś jeszcze teraz z miejsca dodać kilka katalogów do ścieżki wyszukiwania.
Te katalogi to:
c:/cygwin/bin/
c:/PalmDev/prc-tools/bin/
c:/PalmDev/pilrc/
Za ścieżkę wyszukiwania odpowiada zamienna systemowa PATH. Pliki wykonywalne znajdujące się w katalogu uwzględnionym w zmiennej PATH, będą zawsze dostępne do wykonania, nie bacząc na to, z poziomu którego katalogu je wywołujesz.
Ścieżkę można rozszerzyć dopisując katalogi do zmiennej PATH w c:/autoexec.bat (dotyczy Win95/98/ME),
albo prawy-klik na 'Moj komputer' -> 'Właściwości' -> 'Zaawansowane' -> 'Zmienne środowiskowe' (dotyczy WinNT/2000/XP).
Jeśli masz Win95/98/ME to musisz zrestartować komputer. Jeśli masz WinNT/2000/XP wystarczy, że uruchomisz ponownie konsolę komend.
Żeby sprawdzić, czy faktycznie ścieżka wyszukiwania (PATH) została rozszerzona, napisz z poziomu konsoli (command/cmd) set.
W Win95/98/ME defaultowo jest ograniczenie na długość zmiennej PATH i nowe katalogi mogą się już nie zmieścić.
Żeby to zmienić, do c:/autoexec.bat trzeba dopisać gdzieś na początku:
SHELL=command.com /E:2048 /P
10) Instalujesz jakieś IDE.
Powiedzmy, że na początek będzie to PilotMAG.
W PilotMAGu otwierasz sobie nowy projekt i kompilujesz go (tam tylko w głownym pliku .C trzeba gdzieś na początku zmienić nazwę includowanego pliku, napisane jak wół, na pewno zobaczysz). Będziesz widział jakie polecenia wykonuje PilotMAG i czy wykonuje je poprawnie (tj. czy nie sypie błędami, że nie mógł znaleźć jakiegoś kompilatora, czy cuś).
11) Jeśli przejdziesz przez pierwszą kompilację, to teraz możesz zabrać się za dokumentację. Na początku sugeruję przejrzeć dokumentację pod kątem rozdziału o nazwie 'Application Loop' i porównanie go ze strukturą kodu, który pojawia się po wygenerowaniu nowego projektu w PilotMAGu. Potem możesz spokojnie bazować na tej strukturze, żeby zbudować na niej swoją pierwszą aplikację.
12) Bardzo dobrze będzie również, gdy przy tworzeniu kodu nabierzesz od razu zwyczaju wspomagania się oprogramowaniem do kontrolowania wersji.
Pociągnij WinCVS (vel YellowFish :) ze strony http://www.wincvs.org i dokładnie się z nim zapoznaj.
To co będziesz musiał zrobić to:
Wygenerować lokalne repozytorium.
Dodać do lokalnego repozytorium swój nowy projekt (pliki .c, .bmp, .rcp, ale żadnych tymczasowych) - import module.
Wyciągnąć z lokalnego repozytorium swój projekt - checkout - odtąd działasz wyłącznie na wersji wyciągniętej z repozytorium.
W momencie kiedy Twój program osiąga każde kolejne małe stadium (wyskakuje już napis 'Hello world!' co w wolnym tłumaczeniu przekłada się na 'Ala ma kota' i kod daje się skompilować) zmodyfikowany kod dogrywasz do repozytorium - commit.
Teraz w każdym momencie, kiedy z Twoim kodem jest coś nie hallo, a Ty już dostajesz kota, bo nie wiesz, co w swoim kodzie napsułeś, system kontroli CVS podpowie Ci, co się zmieniło od ostatniego commita i w razie potrzeby pozwoli przywrócić wybrany plik lub cały projekt do dowolnego poprzedniego stadium.
Co jeszcze powinieś wiedzieć:
Każdy program, który będziesz publikował musi posiadać unikalny CreatorID, który trzeba zarejestrować na stronie Palma (za friko).
Jeśli chcesz programować w C++ zapoznaj się z projektami:
Bear River's PAF: http://www.bearriver.com/developer/palm/
Teenee (ZenPlus C++): http://www.classactionpl.com/Teenee/index.htm
Powodzenia! :)
