Każdy kto miał styczność z Linuksem wie czym jest Wine. W skrócie jest to emulator (w dużym przybliżeniu), pozwalający uruchamiać na Linuksie aplikacje stworzone pod Windowsa. Dla wielu osób przesiadających się na Linuksa, Wine pozwolił w miarę bezproblemowy sposób kontynuować pracę w ulubionych aplikacjach, do czasu zapoznania się z alternatywnymi rozwiązaniami.
Autor projektu Wine ogłosił, że pracuje nad wersją swojej aplikacji działającej na Androdzie. Co więcej, udało mu się już uruchomić działającą wersję w emulatorze Androida. Niestety prędkość działania tak uruchomionych aplikacji pozostawia wiele do życzenia, co nie zmienia faktu, że po wypuszczeniu stabilnej wersji, tablety z Androidem będą mogły stanąć w szranki z Surface Pro.
>Wine
>emulator
<facepalm>
Poza tym zapewne chodzi o aplikacje na Windowsa ARM, a nie zwykłego Windowsa.
Wine is not an emulator!
Zapowada się rewolucja – każda aplikacja będzie mogła być uruchomiona pod każdą platformą, znikną podziały desktop-mobile. Już teraz jest dostępny WindowsAndroid uruchamiający natywne aplikacje Androidowe pod Windows czy iEmu dla emulacji iOS pod różnymi platformami.
Nie znikną. Aplikacja mobilna od desktopowej nie różni się tylko procesorem na którym jest uruchamiana ale przede wszystkim całym interfejsem, całym UX. Zupełnie inaczej obsługuje się tablet, inaczej komputer z touchscreenem a jeszcze inaczej komputer z klawiaturą i myszką/touchpadem. Aplikacja napisana dla jednego z nich może się nawet dać uruchomić na innym, fizyka tego nie zabrania, ale jej używanie będzie torturą.
Ale to tylko (i aż) kwestia interfejsu. Pod maską wszystko działa tak samo. Można by pokusić się o implementację kilka interfejsów (np. podstawowy na PC + nakładkę na touchscreen).
Jak to "pod maską to samo"
Poprawicie mnie, jeśli się mylę, ale moim zdaniem assembly programu napisanego na x86 jest zgoła inne niż tego na ARM. Może i rozkazy są podobne, ale sama logika programu była by bardziej zróżnicowana (choćby ze względu na dużą różnicę ilości rejestrów do wykorzystania) i prawie niemożliwym wydaje mi się "przekompilowanie" (bo "emulowanie" w czasie rzeczywistym wydaje mi się jeszcze mniej prawdopodobne) programu z assembly x86 na assembly ARM przy jednoczesnym zachowaniu wydajności, że o czasochłonności samego procesu nie wspomnę.
Interpretowanie pliku wykonywalnego innego systemu jest bardzo różne od interpretowania binarki innego procesora.
Myślisz zbyt niskopoziomowo 😉 Obecnie rzadko pisze się w asemblerze. Można napisać program w C++, a samo tylko GUI w Javie dla Androida. Można też wszystko napisać w Javie. Poza tym przepisanie z języka na język jak się ma gotową aplikację jest prostsze niż robienie jej od nowa. Najlepsze aplikacje i tak składane są z mniejszych bibliotek łączonych za pomocą GUI. Chociaż sam interfejs ma spory wpływ na sposób działania aplikacji.
Wniosek z tego, że aplikacja i tak musi być przemyślana i przeprojektowana dla danego rodzaju urządzenia, ale dzięki różnym rozwiązaniem może to być nieco prostsze. Chociaż w przypadku Wine nie odczuwam zachwytu. Dla mnie zawsze będzie to proteza, czasem przydatna, ale zawsze lepiej mieć natywną aplikację dla danego systemu.
Myślę niskopoziomowo, bo temat tego wymaga 🙂
Nigdzie nie napisałem cokolwiek o interfejsie, nie interesuje mnie to. No i nikt tu nie wspomina o pisaniu programów w Assembly 🙂 Kolega wyżej pisze, że "pod maską działa tak samo". Otóż nie tak samo, bo wszystko i tak się koniec końców sprowadza do kodu maszynowego danego procesora; czy to chodzi o C, gdzie kompilacja odbywa się raz, czy o Jave, gdzie JVM interpretuje kod pośredni i gada z procesorem za pomocą jego języka, nie swojego.
Jasne, że można napisać w Javie, ale po co mi wtedy Wine?
O ile jestem naocznym świadkiem jak Wine wyciąga z co potrzebne z binarki PE i uruchamia to na Linuksie, to nie jestem w stanie sobie wyobrazić, jak uruchamia kod przeznaczony dla x86 na ARMie.
Na x86(-64) to działa, bo pliki binarne ELF i PE mają jedną część wspólną – właśnie kod dla tego procesora.
Ging is not Ging
" (…) po wypuszczeniu stabilnej wersji, tablety z Androidem będą mogły stanąć w szranki z Surface Pro (…)".
"Gdybyśmy mieli cienką blachę, to byśmy robili konserwy. Ale nie mamy mięsa."
Na razie to Surface tzw. "Pro" nie może stawać w szranki z Androidem.
Więc Wine na Androidzie raczej dobije już konający na tym rynku microsoft.
"… co nie zmienia faktu, że po wypuszczeniu stabilnej wersji, tablety z Androidem będą mogły stanąć w szranki z Surface Pro."
Yea right!
Szanuję ludzi co robią WINE, mają łeb i determinację, ale uważam że ilości czasu które pochłonął ten projekt w zestawieniu z jego użytecznością nie są tego warte.
Ale niehc sobie robią co im sprawia radość.
Jak na razie jestem sceptycznie nastawiony do szans x86 w starciu z ARM na rynku mobilnym.
Chciałem tylko zaznaczyć, że ten Wine na Androidzie jest wstanie uruchomić jedynie aplikacje skompilowane za pomocą Winelib czyli programiści musieliby przekompilować swoją aplikację – i w tym momencie cały entuzjam pryska 🙂 Podobno pracują też, nad emulowaniem fragmentów x86 poprzez Qemu ale nie widziałem, żadnych większych postępów w tym temacie.
Na forum odroida ktoś odpalił na QEMU windows XP lub coś podobnego.
Z drugiej strony może z tego wyniknąć coś ciekawego jeśli jakiś wielki gracz zdecyduje się zainwestować kasę w projekt, po to by ich tablet mógł połączyć popularność androida z opcją uruchamiania aplikacji napisanych dla windows. Najpewniej skończyłoby się to pozwem od MS ale przynajmniej byłoby zabawnie – przez chwilę.
"po to by ich tablet mógł połączyć popularność androida z opcją uruchamiania aplikacji napisanych dla windows. "
Tylko po co? Na Androida jest masa aplikacji i to dostosowanych do możliwości czy to tabletu czy telefonu. Pomysł Microsoftu z połączeniem tabletu i laptopa jest debilny. Mały tablet nie zastąpi dużego ekranu laptopa, duży tablet przestaje mieć sens bo nie da się go nosić. Uruchamianie aplikacji Windows na Androidzie może mieć sens tylko wtedy gdy Android będzie chciał trafić do desktopów.
Ale spójrz jak to wygląda z perspektywy np. intela. Czy x86 przebije się z windowsem na tablety? Z androidem? Też jakoś nie bardzo. Ale android z możliwością odpalania programów z windowsa mógłby być o dziwo konkurencyjny.
To takie moje fantazje. Nie wierzę by coś podobnego mogło mieć miejsce. Ale to wspaniały scenariusz końca windowsa i konkretnego kopa w tłusty zad ballmera który najwyraźniej uważa, że ludzie używają windowsa bo go lubią. Tak nie jest. To nie windows jest popularny tylko programy na windowsa, a rozpowszechnienie widnowsa jest pochodną bazy oprogramowania dostępnej na ten system…
Czyli – żeby była jasność – najpierw będzie emulacja kodu x86, potem to coś zostanie przepchnięte przez kulawą warstwę abstrakcji żeby potem trafić na VM, która …
I jakim cudem całość ma mieć choćby zbliżone osiągi do analogicznej aplikacji napisanej na daną platforę nawet w marnej, ale natywnej implementacji jakiegoś języka z kodem zarządzanym, albo – o zgrozo – natywnej ?
Na mój gust, każda sensowna platforma powinna oferować jeden język wysokiego poziomu kompilowany natywnie, z bezpośrednim dostępem do OSu i sprzetu do aplikacji profesjonalnych oraz jeden język wysokiego poziomu z kodem zarządzanym do pisania popularnych aplikacji. Do obu w miarę spojne SDK i dostęp do API systemu. Jak ktoś chce emulacjo-wirtualizacjo-konwersjo…coś tam, to niech się bawi.
Ale ta paranoja prowadzi do tego, do czego doszło na desktopach – że każdy postep ze sprzętem jest natychmiast konsumowany już nie przez gorsze oprogramowanie (bo tu się nawet poprawia) ale przez kolejne warstwy "kompatybilności".
"Na mój gust, każda sensowna platforma powinna oferować jeden język wysokiego poziomu kompilowany natywnie, z bezpośrednim dostępem do OSu i sprzetu do aplikacji profesjonalnych oraz jeden język wysokiego poziomu z kodem zarządzanym do pisania popularnych aplikacji. Do obu w miarę spojne SDK i dostęp do API systemu."
Chyba masz na myśli co najmniej jeden. Czy większa ilość obsługiwanych języków jest wadą? Twórcom platformy sprzętowej łatwiej jest wspierać głównie jeden język i zazwyczaj to robią, ale przy okazji lepiej nie utrudniać używanie innych rozwiązań.
Na coś podobnego takiego jak piszesz zdecydowało się ostatnio Gnome. Stawiają na C jako język pisania bibliotek i wydajnych aplikacji i JavaScript do tworzenia interfejsu GUI i usług dla użytkownika końcowego. Będą starać się stworzyć wygodne narzędzia i dokumentację to tych rozwiązań. Ale równocześnie nie zapomną o innych językach tyle, że nie będą one priorytetem.
Czyżby twórcy GNOME zapomnieli o Vala?
chcesz korzystac z ulubionych aplikacji windowsowych ?
przejdź na linuksa !
wine – wine is not an emulator
Ludzie ogarnijcie się.