Aplikacja multiplatformowa za pomocą cross-kompilatora

Opublikowane przez Jarosław Zabiełło Thu, 10 Sep 2009 00:00:00 GMT

Od jakiegoś czasu interesuje mnie możliwość pisania aplikacji działających na różnych systemach operacyjnych. Rozwiązaniem najbardziej oczywistym jest oczywiście użycie Javy (może niekoniecznie samego języka jako takiego, ale na pewno platformy). Rozwiązaniem znacznie mniej znanym, ale ciekawym, jest użycie produktu firmy Real Software – RealBasic’a.

RealBasic to prosty język obiektowy (podobny do Visual Basica). RealBasic to jednak nie tylko język, to także ciekawe zintegowane środowisko programistyczne (IDE). Jest ciekawe, bo posiada wbudowany cross-kompilator – z jednej aplikacji można automatycznie wygenerować kod binarny dla trzech głównych platform: Mac OS-X, Linux i Windows. W przeciwieństwie do Javy nie ma tu żadnej wirtualnej maszyny. Kod wynikowy jest kodem binarnym dla danej platformy. Jedno kliknięcie i trzy wersje programu gotowe. Oczywiście IDE można uruchomić także na każdej z trzech w/w platform. Twórcy RealBasica podkreślają pewną przewagę takiego rozwiązania nad Javą.

Sam edytor jest ładny i intuicyjny w obsłudze (przypomina trochę Delphi). Dokumentacja jest dobra i przejrzysta. Standardowo obsługiwane są bazy danych takie jak PostgreSQL, MySQL a także oparty na SQLite – RealServer. Wszystkie bazy korzystają z identycznego API, więc można je łatwo zmienić bez większych zmian w kodzie źródłowym aplikacji.

Niestety, nie jest to rozwiązanie open-source, ale płatne (z wyjątkiem wersji Personal Edition for Linux która jest darmowa do projektów open-source). Lecz mimo to, jeśli ktoś chce prosto i szybko zmontować aplikację która natywnie będzie pracować pod kilkoma głównymi platformami, to może to być kusząca perspektywa. Tym bardziej, że całość jest po prostu łatwa w obsłudze.

Tagi , , , , , , ,  | 18 comments

Comments

  1. Avatar qoobaa powiedział about 7 hours later:

    Mówisz pan, że to lepsze niż GCC?

  2. Avatar marek powiedział about 7 hours later:

    A C++ i Qt?

  3. Avatar Red powiedział about 9 hours later:

    Ale to BASIC :/ ;)

    Wątpię by ten “kompilator” generował kod maszynowy.. Prawdopodobnie jest to jakiś kod pośredni, a więc jest i maszyna wirtualna, tyle że w odróżnieniu od Java dość lekka.

    Projekt jest zamknięty, więc trudno coś więcej na ten temat powiedzieć..

    Bardzo podobne rozwiązania spotykałem w przypadku Tcl, Lua, Ruby, Python.. Owe kompilatory łączyły kod aplikacji (czasami czysty tekst, czasami nie) wraz z bibliotekami i dodawały odpowiedni kod uruchamiający.

  4. Avatar Jarosław Zabiełło powiedział about 10 hours later:

    Red: Też nie przepadam za BASIC ale też nie przepadam za C++. RealBasic jest obiektowy i wygląda jednak dużo prościej. API jest też oszczędne, więc również łatwiej je opanować. Co do kodu wynikowego, nie sądzę aby tam była jakaś maszyna wirtualna, ale mogę się mylić. W każdym razie działa to wszystko bardzo prosto i wygodnie.

    marek: Nie wiedziałem, że wypuścili IDE na wszystkie główne platformy (QT kojarzył mi się głównie z samymi bibliotekami do GUI) Niestety, ale nie mogę skompilować żadnego przykładu pod Snow Leopardem, który najwidoczniej jeszcze nie jest wspierany. A do Windozy wymagana jest (nie wiadomo po co) instalacja kompilatora Ming (dziwne, że VS nie jest wspierany). Stworzyłem czysty projekt pod WinXP i kompilacja … nie działa. Jakoś C++ nigdy nie kojarzył mi się za dobrze ze słowem multiplatformowość.

  5. Avatar Jiima powiedział about 12 hours later:

    @JZ Odnośnie kjuta, obecnie wspierany jest chyba wyłącznie GCC w różnych mutacjach, nie próbowałem jeszcze nic pisać w wersji LGPL. Wcześniej Qt na windows było również w wersji płatnej (pare tysiaków jak się dowiadywałem w Trolltechu), która nie tylko obsługiwała vc, ale integrowała się z Visual Studio (specjalny template projektu, odpalanie qt designera dla plików GUI itp).

    Co do GUI crossplatform, to fakt że BASIC rzadko kiedy stosuje pełną kompilację. BTW, oprócz Real jest jeszcze coś co nazywa się KBasic, wciąż w wersji rozwojowej, ale wygląda ciekawie i oparte jest właśnie na Qt.

    Poza tym jest wxWidgets itp. Jest też coś takiego jak Lazarus, nie pamiętam czy obsługuje OSX, chyba nie, za to językiem jest o wiele przyjemniejszy od BASIC’a Object Pascal.

    Na koniec kamyczek – “kompilacja do binariów” to obecnie mit i fetysz, nic więcej. Przy obecnej mocy obliczeniowej mniej istotny jest kompilator, a bardziej to co napiszesz. Popatrz np. na Vistę i XP – obydwa systemy napisane w C, nawet przez tą samą firmę, a jaka różnica wydajności (na korzyść starszego XP). Popatrz na PaduPadu 4, napisane w C++ z użyciem Qt, no przepraszam, ale jakby w ten sposób napisano KDE (ta sama platforma, tyle że inny OS i inny stopień komplikacji), czy nawet Kadu (to samo zastosowanie i nawet ten sam protokół IM) to nawet ludzie umęczeni Vistą Basic nie spojrzeliby na to… Aplikacje napisane w Javie często są wydajniejsze od aplikacji w C++, a tym bardziej w Basic. Pomimo VM, która z resztą stosuje również kompilację do kodu maszynowego krytycznych sekcji (ba, w WebKit nawet JavaScript przechodzi podobną obróbkę dzięki silnikowi SF Extreme). Jak chcesz naprawdę przenośne GUI i nie jest to renderer 3d, to weź Pythona, WxWidgets (niestety PyQt wciąż jest tylko na GPL, pomimo iż Qt jest na LGPL) i szalej :)

  6. Avatar Jarosław Zabiełło powiedział about 13 hours later:

    Jiima: Zaletą RealBasica jest prostota i łatwość tworzenia aplikacji, potem jeden klik i mam wersje na 3 główne platformy. Nie zależy mi w tym wypadku na max. wydajności, ale na bardziej wygodzie. Bawiłem się kiedyś wxWidgets, mało intuicyjne i wygląd taki sobie, już QT ładniejsze (tylko że ten QTCreator niespecjalnie działa mi na Maku ani na Windozie).

    W sumie zależy mi aby aplikację zintegrować z silnikiem wyszukiwania pełnotekstowego. W gre wchodzi Sphinx z PostgreSQL (bo z MySQL jest płatny) lub darmowy Solr (oparty na Lucene). W tym drugim wypadku mógłbym użyć Scali lub Clojure. Z drugiej strony RealBasic kusi mnie po prostu swoją prostotą. A to wszystko dlatego, że robię sobie takie przymiarki do nowej wersji mojej wyszukiwarki biblijnej. Poza przebudową po stronie serwera chciałbym zrobić wersję desktopową, bo wiele osób mnie o to prosiło.

  7. Avatar marek powiedział about 15 hours later:

    @Jiima: Moim zdaniem mitem jest właśnie “czar” maszyn wirtualnych w aplikacjach desktopowych. Takie GUI w Javie działa wolno, poza tym każda platforma systemowa charakteryzuje się odrębnym look and feel – stąd fetysz słowa… native :-) Podałeś przykład przeglądarek – wszystkie najpopularniejsze pisane są… w C++. Przypominam, że mówimy o desktopach – to nie serwer, gdzie maszyna wirtualna się rozgrzewa – ma działać od razu, szybko.

    @JZ: Ktoś wspomniał o Lazarusie (http://www.lazarus.freepascal.org/). To takie Delphi tylko wolne (w sensie OpenSource ;-)) i multiplatformowe. Może warto sprawdzić?

  8. Avatar Jiima powiedział about 20 hours later:

    @Marek Co do “native” to takie jest SWT dla Javy, a nie jest np FOX czy GTK+ dla C/C++, więc jedno nie ma związku z drugim. Używam z racji swojej roboty trochę aplikacji napisanych w Javie – Eclipse, NB, SquirrelSQL, JEdit, Azureus (dobra, to nie w pracy) i nie narzekam. Na Windoze ostatnio coraz więcej softu jest w C# i też jakoś powodu do płaczu nie ma… A, przeglądarki pisane są w różnych językach. Na przykład firefox napisany jest… w Javascripcie. Poważnie – w C jest jedynie silnik renderujący (Gecko), interfejs i pluginy powstają w XUL, czyli mieszaninie XML (do opisu widgetów) i JS (do obsługi zdarzeń).

    Owszem, zawsze aplikacja w czystym C (ale nie w C++ który jest fatalnym językiem i dość wolnym jak na generujący kod natywny) zawsze będzie szybsza od napisanej w Javie czy Pythonie, ale w wielu przypadkach różnica nie będzie tak istotna by tracić czas na pisanie aplikacji w C.

    @JZ A w RB masz jakiś silnik FTS? Desktopowa aplikacja w Lisp? Ambitne samo w sobie… Do Qt masz jakiegoś pecha, mi działa tu i tu, fakt źe dotąd nie pisałem nic poważniejszego w tej platformie.

  9. Avatar Marek powiedział 1 day later:

    @Jiima: AWT udaje native (podobnie jak Qt) – kontrolki są rysowane na podobieństwo tych systemowych. SWT natomiast (Eclipse) zostało zastąpione przez Cocoa w Galileo (Eclipse 3.5) – coś jest na rzeczy ;-)

    A co, jak nie silnik, jest najważniejszą częścią przeglądarki? Chrome jest pisany w C++ (WTL dla GUI).

    Jeszcze taka dygresja – GUI w Windows to jeden wielki bałagan. Każda aplikacja wygląda inaczej (zakładając 3 interfejsy: classic, luna i aero). Czasem jest programik pod Viste z przyciskami rodem z Win 3.11 (vide świetny TrueCrypt, ale i aplikacje systemowe), jakieś wstęgi, pasek menu w dziwnym miejscu (IE 7, 8), różny wygląd samego menu (Office 2000, 2003, 2007, kolejne wersje Visual Studio). Bądź tu mądry ;-)

  10. Avatar Marek powiedział 4 days later:

    SWT nie został natomiast nigdzie “zastąpiony” i nic nie udaje – idea IBM w wypadku SWT polegała na użyciu natywnych widgetów z danego systemu, dlatego właśnie Eclipsa i jego pomioty masz w oddzielnej wersji na każdy OS – problemem nie jest sam Eclipse, tylko SWT, a dokładniej jedna natywna biblioteka napisana w C, która jest odpowiedzialna za renderowanie interfejsu przy pomocy natywnych widgetów. W 3.5 po prostu zastąpioną tą bibliotekę – w miejsce starego mostu korzystającego z API Carbon (zdecydowanie przestarzałego), wprowadzono most korzystający z Cocoa, reszta jest bez zmian. Wcześniej podobną migrację przeszło SWT dla X11, gdzie “czystą” implementację opartą na XLib zastąpiono GTK+, zaś obecnie podobny refaktoring przechodzi wersja dla Windows, gdzie Win32 zastąpiona zostaje przez WPF. (Oczywiście oznacza to że owe mosty nie są już pisane w C, tylko w ObjC (Cocoa) i chyba C# (WPF)) Czyli nadal nie wiem co miałoby być na rzeczy. Fakt, własne renderowanie widgetów nie jest do końca rozsądne gdy piszesz pod OSX lub Windows, bo dostajesz aplikację pasującą do systemu jak pięść do nosa. Takie podejście to spuścizna X-ów, w których nie istnieje pojęcie widgetu i dopiero takie biblioteki jak Athena, Motiff, GTK+ czy Qt dopiero je wprowadziły. A odnośnie AWT którego wspomniałeś wcześniej – AWT właśnie używał natywnych kontrolek (tzw. ciężkich kontrolek), renderowanie kontrolek “podobnych” do systemowych było opcjonalne. To z resztą było przyczyną ogólnej klapy tej biblioteki, była zasobożerna i stosowała podejście “najmniejszego wspólnego mianownika” dla różnych systemów (dla X był to Motiff) więc posiadała za mało kontrolek. Swing zamiast tego rysował kontrolki sam (tzw. lekkie kontrolki), nawet w “trybie AWT”, co poprawiło wygląd aplikacji, niestety nie poprawiając jej szybkości. Dopiero w wersji 5.0 dzięki optymalizacji Swinga i wejściu szybszych maszyn na rynek Swing zaczął nadawać się do użytku. Obecnie rzeczywiście symuluje on “natywny” wygląd (o ile nie zażyczysz sobie inaczej) w tym w Viście i GTK potrafi nawet “podkraść” aktualny temat.

    Co do spójności interfejsu dla mnie ideałami są OSX i KDE (niestety, sporo aplikacji pod X11 pisane jest w GTK+ co psuje ową sielankę w KDE), Apple nawet postarało się by Mac-owa wersja Swing’a korzystała z górnego paska menu zamiast renderować własny. Windows z założenia cierpi na nadmiar starożytnych API. Z “oficjalnych” LAF mamy nie tylko wymienione przez ciebie (z czego tylko “Luna” została posłana do kosza, pomimo iż w zasadzie Xp było najbardziej udanym systemem microsoftu), ale jeszcze Win16 (ocalałe “spady” po Windows 3.11, do dzisiaj działające, można je poznać np. po innym stylu okien dialogowych i nie rozpoznawaniu długich nazw), WPF (Niby podstawowo wygląda tak jak Aero, ale z niejasnych dla mnie powodów “oficjalne” aplikacje w tym napisane, jak np. Expression, wyglądają zupełnie inaczej), Office 2000 i 2003 (zauważ, że od wersji Office 2000 pakiet z założenia nie wygląda tak jak podstawowe aplikacje Windows) no i najnowszy – Ribbon (obecnie w Office 2007, ale również w Windows 7 – jako odrębne API, a ostatnio również Open Office eksperymentuje z tym wyglądem). Czyli jest w czym wybierać i można zapomnieć o spójności wyglądu…

    A co do kwestii szybkości, to sprawa o tyle jest zabawna, że GUI nie musi być szybkie (wystarczy że będzie “dość szybkie”), a co więcej, sposób renderowania kontrolek ma na ową szybkość mniejszy wpływ niż sądzisz. Zauważ, że te kontrolki muszą być narysowane tak czy siak. W starszych systemach ręczne rysowanie było wolniejsze głównie z powodu niemożności bezpośredniego renderowania, jednak obecnie wszystkie systemy graficzne to oferują, ba, łącznie z dopalaniem sprzętowym. Korzystanie z natywnych kontrolek ma swoje zalety i wady – np. w Windows kontrolki są obiektami systemu, więc musisz dbać o poprawne zwalnianie ich uchwytów, inaczej będziesz miał wyciek zasobów. Ponadto, kontrolki renderowane nie mogą być przechwycone przez różne podkradacze haseł (niestety nadal pozostaje keylogger), gdyż system ich nie widzi, a narzędzia te z reguły korzystają z api systemu. Tak więc temat “natywne vs. renderowane” jest o wiele bardziej złożony niż by się mogło wydawać.

    Na zakończenie przykład negatywny, ale sporo mówiący. StarOffice / OpenOffice. Pakiet ten Sun stworzył w Javie, w myśl zasady “eat your own dog food”. Jedną z jego powszechnie znanych wad była ślamazarność. Wyjaśnienie problemu wydawało się proste – chcieliście Javy no to macie ŻółwOffice™. Sun przemyślał sprawę, przepisał StarOffice w C++ przy okazji zmieniając nazwę i licencję. Powstał… równie powolny OpenOffice. Obecnie OO chodzi z zadowalającą prędkością, ale nie jest to zasługa C++ (bo w tym wypadku również wersja 1.0 chodziła by jak burza) ani natywnych widgetów, tylko tego że od wersji 1 programiści projektu pracują nad optymalizacją pakietu. Czyli w zasadzie toolkit jest mniej istotny, a bardziej to, jak napiszesz kod.

  11. Avatar Jiima powiedział 4 days later:

    @Marek Sorry, to powyżej to mój wpis, znowu wpisałem w złe pole. Sorry za podszywanie :)

  12. Avatar Piotr Jaskulski powiedział 5 days later:

    Bardzo lubię REALbasic, ale nie jest to idealne rozwiązanie. Nie lubię się powtarzać a tak się składa, że pisałem o tym ostatnio dłuższy tekst: REALbasic: plusy, minusy i mroczna przyszłość

  13. Avatar Piotr Jaskulski powiedział 5 days later:

    I jeszcze jedno. Do aplikacji współpracującej z PostgreSQL będzie potrzebna wersja Professional albo płatny plugin od MonkeyBread Software. Najtańsza wersja samodzielnie potrafi operować tylko na bazach REALSQLDatabase (czyli SQLite).

    I drugie. Sam język nie jest Basicem z dawnych lat, można zapomnieć o print i goto. REALbasic jest obiektowy a co potrafi? Np. ten programik jest w nim napisany: Xsilva

  14. Avatar waflo powiedział 9 days later:

    Ja bym Ci jednak polecił Qt. Ostatnio modna technologia i bardzo fajnie się w tym pisze. Po za tym robisz sobie statyczną wersję i masz aplikację w jednym pliku i nie potrzebujesz żadnych dodatkowych bibliotek. Ale to tylko w wersji komercyjnej bo w darmowej musisz dołączyć biblioteki osobno. Dla mnie jednak wsparcie jest ważne, a taki basic to ma niewielu uzytkowników. Po za tym do Qt masz dużo darmowych dodatkowych bibliotek i komponentów, które z założenia powinny być multiplatformowe (ale z tym to już różnie jest).

  15. Avatar Piotr Jaskulski powiedział 10 days later:

    Qwaflo: Dla mnie jednak wsparcie jest ważne, a taki basic to ma niewielu uzytkowników.

    Według producenta ma ponad 130 tys. użytkowników w 130 krajach. Forum RB ma ponad 5000 członków i 163 tys. postów. Działają 4 listy mailowe (ang, włoska, francuska i niemiecka). Najaktywniejsza – angielska – ma średnio ok. 1200 maili miesięcznie.

    Aplikacje napisane w RB i skompilowane dla Maca i Linuxa są jednoplikowe. Wersja dla Windows tworzona jest w postaci zestawu exe i bibliotek dll.

  16. Avatar Marek powiedział 10 days later:

    @Jiima: Dzięki za wyczerpującą odpowiedź. Pozdrawiam :-)

    P.S. Jeszcze ciekawostka. Okno zapisu obrazka w IE 8 (Windows XP SP3) wygląda jak z czasów Windows 95 (mimo motywu Luna): http://img148.yfrog.com/i/savepicture.png/

    Okno zapisu pliku i strony jest już natywne: http://yfrog.com/0jsavewebpagep

    Niestety, w Windows 7 sytuacja wcale nie wygląda lepiej, czego najlepszym przykładem jest choćby: http://www.windows7taskforce.com/view/1101

    Podsumowując – aplikacja zachowująca spójny wygląd pod Windowsem, to już niezły wyczyn, a co dopiero multiplaformowa ;-) Powodzenia dla JZ.

  17. Avatar Jiima powiedział 15 days later:

    @Marek O, tego zynksa z IE nie widziałem – wiesz, IE jest u mnie dość nisko na liście używanych aplikacji, w zasadzie odpalam go w robocie by wejść na firmowy portal i wypełnić timesheet, ew. sprawdzić czy aplikacja którą pisze działa.

    A ikonka reg… Ostatnio doszliśmy do wniosku, że rejestr to jeden z większych niewypałów Windows, a pliki REG zdaje się same są uważane za przestarzałe i niebezpieczne. Być może to jest powód, dla którego nie doczekały się swojej ikonki w W7

    A co do spójnego wyglądu, to jeszcze warto dodać Swinga (tylko pod OSX preferowany jest temat natywny), GTK+ (dopiero od niedawna jest Wimp i w odróżnieniu od Swing nie bierze on wyglądu z theme managera, tylko został ręcznie narysowany) no i oczywiście aplikacje M$, który zwykle jest pierwszą firmą NIE przestrzegającą swoich “Human Interface Guidelines”. Teraz jeszcze doszedł Apple, który uparł się, by jego aplikacje dla Windozy przypominały OSX do maksa (vide ITunes czy Safari 3. Safari 4 Beta wyglądała idealnie, jednak w wersji ostatecznej znowu z “macosiała”).

  18. Avatar calder powiedział 19 days later:

    Zgadzam się, że REALBasic jest dobrym narzędziem do szybkiego tworzenia prostych programów, ale osobiście bałbym się pchać w niego czy jakikolwiek komercyjny język z jednego powodu – jeżeli producent nie dostarczy jakiegoś komponentu / biblioteki to są raczej małe szanse na znalezienie czegoś w necie, nawet odpłatnie. W którymś momencie okazuje się, że musisz sobie taką klasę/bibliotekę/komponent napisać samemu i nagle cała produktywność i błyskawiczne tworzenie softu bierze w łeb.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz