Wywiad z Szymonem Ulatowskim, autorem aplikacji Przewodas

W roku 2022 opublikowałem gawędę o Transportoidzie (tutaj transkrypcja), mobilnym rozkładzie jazdy komunikacji miejskiej dla kilkudziesięciu polskich miast. Był to program na platformy Android i Windows Phone. Źródłem inspiracji dla Transportoida był jednak Przewodas, program rozwijany w latach 2002-2004 i dostępny na urządzeniach z systemem PalmOS.

W listopadzie 2025 odwiedziłem imprezę Games & Vintage Days, gdzie spotkałem Szymona Ulatowskiego, twórcę Przewodasa. Niemal ćwierć wieku temu wysyłałem mu rozkłady jazdy dla Wrocławia, jednak dopiero teraz mieliśmy okazję porozmawiać na żywo. Zapraszam na wywiad z Szymonem – wspominamy pionierskie czasy pierwszych urządzeń mobilnych, archaicznych interfejsów użytkownika oraz… programowania rysikiem na ekranie dotykowym.

Szymon Ulatowski – programista, niegdyś amigowy, potem palmowy, obecnie linuksowo-iphonowy. Lubi gry (grać i programować), literaturę fantastyczną, elektronikę i inne przejawy technologii

---

Tomasz Zieliński: Zacznijmy od podstaw – czym był Przewodas i skąd pomysł na taki program?

Szymon Ulatowski: Pomysł na program zrodził się z potrzeby chwili. Mieszkałem wówczas w Warszawie i codziennie spędzałem dużo czasu w autobusach – stąd szczególne zainteresowanie godzinami odjazdów i przyjazdów. Pisałem program z rozkładami, którego sam będę używał, więc nie unikałem tworzenia funkcji trudnych do zrealizowania. Miał być dobry i wygodny w użyciu. („– Pamiętajcie chłopcy, na tej budowie robimy solidnie i bez fuszerki, bo budujemy dla siebie! – A co tu będzie panie majster? – Izba wytrzeźwień!”)

TZ: Czy to prawda, że Przewodas był pisany na… palmtopie? Przecież PalmOS był pozbawiony ochrony pamięci, dowolny błąd mógł skończyć się zawieszeniem systemu i utratą danych!

SU: Zgadza się, większość kodu pierwszej wersji programu była pisana bezpośrednio na Palmie, w autobusie! PalmOS nie tylko nie miał tego, co dzisiaj nazywamy ochroną pamięci, ale nie miał nawet „pamięci nieulotnej” i wszystkie przechowywane w pamięci dane użytkownika znikały po wyjęciu baterii. Ale istnieją granice tego szaleństwa: obszar RAM-u pełniący funkcje „dysku” był jednak chroniony przed przypadkowym nadpisaniem i mogły go modyfikować tylko funkcje systemowe. Błędny program mógł bez trudu zawiesić system, lecz to tylko drobna niedogodność, po resecie wszystko znowu działało.

TZ: Dołączone oprogramowanie pozwalało na zrobienie pełnego backupu danych użytkownika po kablu, więc w razie wypadku istniała możliwość uratowania przynajmniej części zasobów.

SU: W tamtych czasach tylko ROM palmtopów (zawierający system) był pamięcią flash, co pozwalało na aktualizacje systemu. Nieulotna pamięć dostępna dla użytkownika (do zapisu danych) pojawiła się na tej platformie wiele lat później, już za czasów procesorów ARM.

TZ: Jak w ogóle możliwe było programowanie na urządzeniu bez klawiatury, z wyświetlaczem o rozdzielczości 160×160 pikseli oraz procesorem będącym spadkobiercą Motoroli 68000? Przecież kod w języku C jest pełen kropek, nawiasów i innych znaków, które trudno było bezbłędnie „maznąć” piórkiem?

SU: Dało się zaskakująco dobrze! Ten system wprowadzania znaków powstał jako uproszczenie, kompromis – kształty kreślone rysikiem jeszcze jako tako przypominały litery ale były łatwe do rozpoznania nawet przez tak słaby procesor. Ale takie uproszczenie oznacza również (gdy już oswoimy się z alfabetem) że znaki pisze się szybciej niż gdyby miały pełną formę graficzną. „Zbyt głupi” procesor, który nie potrafi ze stuprocentową dokładnością odróżnić „u” od „v”, wymusił rozwiązanie, w którym trzeba pisać te litery jedną od lewej do prawej, a drugą od prawej do lewej strony.

To skandal wymagać, by człowiek dostosowywał się do wydumanego sztucznego pisma? Może i tak, ale gdy już się go nauczymy, to nigdy nie nastąpi błędne rozpoznanie. Podobne zasady obowiązują dla potrzebnych w języku C znaków specjalnych: ; < > [ ] { } * # %. Każdemu z nich odpowiada unikalny kształt, nie zawsze idealnie odzwierciedlający obrys, ale kojarzący się z nim.

Gdy uwzględnimy fakt, że można pisać jedną ręką (paznokieć zastępuje rysik) i to w pewnym stopniu bezwzrokowo (kształty rysuje się zawsze w tym samym miejscu poniżej ekranu), to niektóre fragmenty kodu w C da się szybciej napisać na Palmie niż na współczesnym telefonie z klawiaturą dotykową, która w takiej sytuacji wymaga ciągłego przełączania znaków specjalnych i kontroli poprawności wyboru klawisza.

Natomiast mały ekran rzeczywiście był problemem. Programy pisane w tych warunkach miały specyficzne formatowanie, jak najkrótsze nazwy zmiennych i minimalną ilość komentarzy.

TZ: Wyjaśnijmy młodzieży, że ówczesne ekrany dotykowe LCD były wykonane w technologii rezystywnej, co wymuszało używanie rysika (stylusa). Elementy interfejsu użytkownika mogły być względnie małe, bo użytkownik nie zakrywał ich palcem.

SU: Tak, możemy to porównać do precyzyjnego klikania myszką na komputerze. Gdy w smartfonach pojawiły się ekrany dotykowe w powszechnej dzisiaj technologii pojemnościowej, miało się wrażenie, że wszystko jest takie wygodne, płynne i responsywne i w ogóle nastała nowa era – ale jednak trochę żal, że oto teraz aplikacje muszą pokazywać człowiekowi swoją „głupszą” twarz, uproszczoną, ogołoconą z wielu funkcji trudnych do obsługi palcem.

TZ: Jak układała ci się współpraca z zewnętrznymi dostawcami rozkładów?

SU: Współpraca była bardzo miła. Oczywiście wszystko nieoficjalnie i na zasadach koleżeńskich. „Dostawcą” był człowiek, który scrapował stronę lokalnego przewoźnika i tworzył z tego odpowiednio ustrukturalizowany plik wejściowy, z którego specjalny konwerter tworzył bazę danych dla Przewodasa. Mówię to, bo ktoś mógłby sobie pomyśleć że „zewnętrzny dostawca rozkładów” to może przedsiębiorstwo komunikacyjne z danego miasta 😉 Nie, użytkowników palmów było za mało, aby ich istnienie przedostało się do mainstreamowej świadomości.

Gdy wszystko szło gładko, to dostawałem tylko informację „cześć, zrobiłem bazę dla miasta X, załączam plik” i ten plik umieszczałem na stronie WWW. Czasem, przy nieprzewidzianych kombinacjach danych wejściowych, wychodziły jakieś błędy lub ograniczenia – wówczas trzeba było kombinować. Zajrzałem teraz do starych maili i takim wyzwaniem naginającym założenia programu była próba wrzucenia do Przewodasa całego rozkładu jazdy PKP.

TZ: Jesteś w stanie określić, jak popularny był Przewodas? Prowadziłeś takie statystyki? Na bazie liczby pobrań mojej bazy dla Wrocławia szacowałem, że w tym mieście Przewodas miał kilkunastu użytkowników.

SU: Nie mam pojęcia… ale nawet gdyby wszyscy posiadacze Palma w kraju używali Przewodasa to dzisiaj ta liczba wyglądałaby śmiesznie 🙂

TZ: Twoje rozkłady dla ZTM Warszawa pojawiały się do końca roku 2004, czemu tak krótko? Fan Przewodasa z Krakowa dostarczał aktualizacje dla swojego miasta aż do roku 2008!

SU: Nie pamiętam już teraz dokładnie – ale chyba wtedy przeprowadziłem się z Warszawy do Krakowa, więc warszawskie rozkłady przestały mi być potrzebne.

TZ: Jakich funkcji użytkownicy domagali się najbardziej? Czego w tamtych czasach nie dało się zrobić?

SU: Myślę że najwięcej emocji wzbudzała funkcja wyszukiwania połączeń z przesiadkami. Była, bo musiała być, choć z góry wiedziałem, że nie będzie idealna, że nie wystarczy mocy na pełne przeszukanie wszystkich możliwych kombinacji. Co prawda na pocieszenie było też szybkie i optymalne przeszukiwanie z jedną przesiadką, bo do tego wystarczył prosty algorytm, ale to jednak jakieś rozczarowanie, że niby komputer taki mądry i ma wszystkie dane, a nie umie znaleźć idealnego połączenia w każdej sytuacji.

Druga rzecz, o którą często pytano, to mapa przystanków i linii. W zasadzie dałoby się jakąś formę mapy tam wcisnąć, ale nigdy nie doszedłem do etapu poważnego rozważania, w jakiej formie powinno to być zrobione. Pewnie byłoby to fajne – choć pożytek z mapy byłby mniejszy, niż dzisiaj, bo urządzenia nie miały GPSa.

TZ: Jakie były największe ograniczenia PalmOS? Czy to prawda, że pierwsze wersje nie miały nawet dostępnego dla użytkownika systemu plików?

SU: Ha ha, to jest pytanie o ajfona! Wiele lat minęło zanim użytkownicy zobaczyli na nim pliki, mimo że od początku w środku jest coś unixopodobnego. W obu przypadkach tarcie na styku własnego świata i świata zewnętrznego wymuszało stopniową akceptację faktu istnienia plików – wbrew początkowemu założeniu, że zwykły użytkownik wiedzy o nich nie potrzebuje.

W przeciwieństwie do iPhona, gdzie „brak plików” był tylko doktryną interfejsu użytkownika, na Palmie było to rzeczywiste ograniczenie. Tradycyjnie rozumianych plików („nieustrukturalizowane ciągi bajtów w hierarchicznej strukturze katalogów”) nie było ani na wierzchu ani w środku.

Czy to dokuczliwa wada? Taka a nie inna organizacja danych wynikała z potrzeby jak najbardziej efektywnego wykorzystania szczupłych zasobów. Pierwszy Palm, jeszcze nie firmy Palm tylko USRobotics, miał „aż” 128 kilobajtów pamięci (łącznie pamięci operacyjnej i „dysku”). Palmowe ustrukturyzowane „bazy danych” (zastępujące pliki) i ich API są lepiej dostosowane do takiej specyfiki sprzętowej niż tradycyjny filesystem. Coś za coś.

Programista musi się bardziej postarać i dostosować do wymagań systemu, ale to dzięki temu system PalmOS mógł zaistnieć. W miarę, jak rosła wielkość pamięci i wydajność CPU (w późniejszych modelach był to procesory ARM) optymalizacje i skrajnie oszczędne gospodarowanie zasobami miały w praktyce coraz mniejszy wpływ na wydajność. Dla mnie najbardziej wkurzający był limit wielkości pojedynczego rekordu w bazie (64 kilobajty), który wywodzi się z od najstarszych Palmów i przetrwał do końca.

Patrząc z perspektywy dzisiejszych systemów szokujący wydaje się – wspomniany już – brak ochrony pamięci. Oczywiście konsekwencją było to, że byliśmy zmuszeni pisać programy bezbłędne, żeby nie zawieszać systemu 😁

Dzisiaj to by już nie wystarczyło – brak ochrony pamięci to również możliwość czytania dowolnych danych jednego programu przez drugi.

TZ: Ile masz urządzeń z rodziny Palm? Czy jeszcze działają?

SU: Palm III – pierwszy jaki miałem – ale nie ten sam egzemplarz, kupiłem go później jako pamiątkę. Co ciekawe, działa na baterie paluszki, więc nie dotyczy go problem starzenia się wbudowanej baterii. Działa jak nowy! Do starych urządzeń w którymś momencie może już się nie dać kupić nowego akumulatorka.

Treo 650 – ostatni jaki miałem. Bateria trzyma 20 sekund ale z podłączoną ładowarką da się używać. Gdyby mu dać nową baterię, to ciągle mógłby być po prostu telefonem do dzwonienia i smsów, ale w pozostałych obszarach boleśnie widać upływ czasu. Kto by chciał telefon bez współczesnej przeglądarki, bez współczesnych apek i z aparatem robiącym zdjęcia o rozdzielczości 640×480? Chociaż… w czasach permanentnej inwigilacji niektóre osoby są zmuszone do korzystania ze „starej nokii”. Więc może w takiej sytuacji lepszy byłby „stary palm”? Bo to co prawda nie z tej epoki, ale jednak smartfon 🙂

TZ: Które elementy ekosystemu Palma chciałbyś zobaczyć w Androidzie czy iOS? Mi najbardziej brakuje globalnego wyszukiwania w zasobach wszystkich programów naraz oraz możliwości podmiany widżetów systemowych, jak np. wybierak daty i godziny.

SU: Hmmm, jakieś globalne wyszukiwanie w iOS-ie jest, chociaż najczęściej nie potrafi odnaleźć tego czego szukam 😆. Ogólnie mam wrażenie, że stopniowo wszystko, co kiedyś znaliśmy z Palma, przeniknęło do dzisiejszych systemów. Czasem wyglądało to trochę zabawnie, na przykład Apple się chwali, że oto wprowadzają jakiś rewolucyjnym nowy mechanizm, na przykład powiadomienia. Wszyscy im wytykają, że przecież pomysł został bezczelnie zerżnięty z Androida – podczas gdy dawni palmowcy tylko kiwają głowami…

Pewnie tak samo było, gdy w latach 80-tych użytkownicy komputerów domowych i pierwszych pecetów odkrywali dla siebie to, co poprzednie pokolenie robiło w latach 60-tych na dużych komputerach.

Ale wracając do porównania Palm / Android / iOS – niby wszystko jest, i to nieporównanie potężniejsze, szybsze i lepsze, a jednak mam wrażenie, że prosta czynność (dopisanie czegoś w kalendarzu albo liście do zrobienia) zajmowała na Palmie mniej czasu, niż na dzisiejszym telefonie. Jakoś tak dobrze tam było to wszystko wymyślone.

Przykład podmieniania wybieraka daty pokazuje, że na Palmie aplikacje mogły robić, co tylko chciały. Dzisiaj byłoby to możliwe tylko, gdyby producent przewidział taką możliwość w swoim systemie – ale nie ma ku temu wystarczająco ważnego powodu. Fajnie powspominać świat, w którym nie było zabezpieczeń a aplikacje mimo wszystko nie robiły krzywdy użytkownikowi. Jednak lepiej poprzestać na wspominaniu bo dzisiaj na pewno nie byłoby tak różowo.

TZ: Oprócz Przewodasa napisałeś też na Palma serię gier i programów, moim numerem jeden był Touch Tetris. W pewnym momencie musiałeś chyba zmienić jego nazwę?

SU: Zgadza się, nazwa „Tetris” jest wyjątkowo dobrze chroniona a sklepy dystrybuujące software tak wtedy, jak i dzisiaj, poważnie traktują listy od prawników, tak więc bardzo szybko gra musiała zmienić nazwę na „Touch Bricks” 😅.

Touch Tetris to taki Tetris, w którym klocki dają się przeciągać piórkiem a zastygają na miejscu dopiero chwilę po ostatnim dotknięciu. Dzięki temu można utrzymać „w ruchu” kilka klocków naraz i wcisnąć brakujący kształt mimo tego, że nie mógłby w pożądane miejsce opaść swobodnie.

TZ: TouchTetris miał licencję „giftware” – użytkownik był zobowiązany przysłać ci pocztą upominek. Czy dostałeś coś będącego prawdziwą niespodzianką?

SU: Nie! Dostałem chyba kiedyś jakąś pocztówkę lub dwie, nie pamiętam już dokładnie, ale ogólnie odzew był mały jak na grę, która zdobyła nieco popularności. Zupełnie inaczej, niż z Przewodasem, gdzie zdarzały się prezenty 🥳, może z powodu jego rzeczywistej przydatności w życiu codziennym.

Przez Touch Tetrisa dostałem też kiedyś potężny ochrzan od jednego z użytkowników! Poszło o to, że gra dopisywała do kalendarze wydarzenie „urodziny twórcy Touch Tetrisa”, by użytkownik wiedział, kiedy ma przysłać ten prezent. No i ktoś oburzył się, jakim prawem ośmielam się ingerować w jego kalendarz!

TZ: Jakie jeszcze gry i aplikacje wydałeś na Palma? Zyskały pewną popularność za granicą – dało się utrzymać z ich rozwoju, czy było to raczej „kieszonkowe”?

SU: Opublikowałem kilka mniejszych lub większych aplikacji w palmowych sklepach a największym sukcesem, również komercyjnym, okazała się gra „Bike or Die!”, czyli coś w rodzaju Elastomanii. Tak jak już mówiliśmy, rynek Palmowych aplikacji był mikroskopijny w porównaniu do dzisiejszych platform mobilnych, ale była też nieporównanie mniejsza konkurencja, a ceny 10 razy wyższe. Dało się więc zarobić. A gdy ktoś robił software tylko dla przyjemności, to i tak miał pewność, że ludzie to obejrzą, bo nowości pojawiało się mało. Jeżeli ktoś kupił Palma, to wiadomo, że należy do tego niewielkiego procenta populacji, który szuka nowego sposobu bawienia się technologią, więc będzie instalował aplikację za aplikacją. Dzisiaj typowy posiadacz „komputera w kieszeni” nie jest już poszukiwaczem.

TZ: Czym zająłeś się, gdy Palm zszedł z rynku?

SU: Z Palma przeszedłem wtedy płynnie na iPhona, przenosząc palmowego „Bike or Die!” na iOS. Potem przyszedł „Top Sailor” – tu jestem współtwórcą, to gra kolegi, co ciekawe również wywodząca się z Palma. I w sumie to tak to się do dzisiaj ciągnie.

---

Starsze i nowsze produkcje Szymona znajdziecie na stronie toyspring.com