Kompatybilność binarna między Mac OS X i Linux

Przygotujcie się, to pytanie prawdopodobnie będzie naiwne i / lub głupie, ponieważ jestem stosunkowo nowy w wewnętrznych działaniach systemów uniksowych i programowaniu w ogóle.

Gotowy? Dobrze! Przejdę przez około 3 poziomy ludicrosity, wzrastając wraz z upływem czasu.

Jeden jest uruchomiony (wstaw tutaj swoją dystrybucję Linuksa: Ubuntu będzie odtąd używany), a drugi działa powiedzmy Mac OS X.

Kompiluje się równoważny program, powiedzmy coś takiego:

int main()
{
    int cat = 33;
    int dog = 5*cat;
    return dog;
}

Kod jest niezwykle prosty, ponieważ nie chcę jeszcze rozważać konsekwencji bibliotek współdzielonych.

Po skompilowaniu w odpowiednich systemach. Czy główna różnica między wydajnością nie jest kwestią ELF a Mach-O? Gdyby rozebrać każdy plik binarny formatowania, pozostawiając płaski plik binarny, czy zdemontowane instrukcje maszyny nie byłyby takie same? (może z kilkoma różnicami w zależności od nawyków / tendencji kompilatorów).

1.) Gdyby opracować program do przepakowywania płaskiego pliku binarnego wyprodukowanego z naszego systemu Ubuntu, w formacie Mach-O, czy działałby on w systemie Mac OS X? Zatem, jeśli ktoś miałby tylko skompilowany plik binarny rzekomego programu powyżej i miałby to mistyczne narzędzie do przepakowywania płaskich plików binarnych, czy proste programy byłyby w stanie uruchomić na systemie Mac OS X?

Mamy teraz program ze źródłem takim jak:

#include <stdio.h>
int main()
{
    printf("I like tortoises, but not porpoises");
    return 0;
}

2.) Zakładając, że ten program jest skompilowany i statycznie powiązany, czy nasz magiczny program nadal byłby w stanie ponownie spakować surowy plik binarny w formacie Mach-O i czy działa na Mac OS X? Ponieważ nie trzeba polegać na żadnych innych plikach binarnych (dla których system mac nie miałby w tym przypadku)

3.) Co, jeśli użyjemy tego rzekomego programu do konwersji wszystkich niezbędnych bibliotek współdzielonych do formatu Mach-O, a następnie skompilujemy powyższy program z dynamicznym łączeniem. Czy program nadal będzie działał?

Tak powinno być na razie, oczywiście każdy etap absurdu opiera się na poprzedniej bazie, aby nawet mieć sens. więc jeśli pierwszy filar zostanie zniszczony, wątpię, czy pozostałe poziomy będą miały wiele zalet.

Zdecydowanie nie posunęłbym się nawet tak daleko, by myśleć o tym z programami z myślą o GUI. Systemy okien prawdopodobnie byłyby zupełnie innym problemem. Na tym etapie rozważam tylko programy wiersza poleceń.

Teraz zapraszam świat, aby mnie poprawił i powiedział mi wszystko, co jest nie tak z moim absurdalnym tokiem myślenia.

Zapominasz jednej kluczowej rzeczy, a mianowicie, że Twój program będzie musiał wchodzić w interakcje z systemem operacyjnym, aby zrobić coś interesującego.

Konwencje różnią się między Linuksem a OS X, więc ten sam plik binarny nie może działać w takiej postaci, w jakiej jest, bez zasadniczo części kodu zależnego od systemu operacyjnego, aby móc z nim współdziałać. Wiele z tych rzeczy jest ukrytych w bibliotekach, które następnie trzeba połączyć, a to oznacza, że ​​twój program musi być możliwy do połączenia, a łączenie jest również różne w obu systemach.

I tak to trwa. To, co na pierwszy rzut oka wydaje się robić to samo, różni się w rzeczywistych szczegółach.

Jest to wykonalne, jeśli ktoś chce poświęcić wystarczająco dużo czasu, aby tak się stało. TheProjekt Kochanie próbuje ten, choć jak to pisze, że był on w stanie dość prymitywne.

Udało się to wcześniej na innych platformach:

• Solaris i UnixWare zawierają program pomocniczy o nazwie, lxrunktóry działa mniej więcej tak sudo: przekazujesz swoją nazwę pliku wykonywalnego i parametry do pomocnika i naprawia to dynamicznie, aby plik wykonywalny mógł komunikować się z systemem operacyjnym. Oficjalna strona (w dół, archiwum Link ) mówi, że bitrotted .

• Jądro Linuksa miało kiedyś funkcję o nazwie iBCS, która działała w drugą stronę, tyle że nie potrzebowała pomocnika, ponieważ jądro bezpośrednio rozpoznawało „obce” pliki binarne. To popadł w ruinę podczas cyklu rozwojowego jądra 2.3 , najprawdopodobniej dlatego, że mała bitwa serwerów Unix było w zasadzie na raz 2,4 wyszło.

• Jądro FreeBSD można skonfigurować do rozpoznawania plików binarnych systemu Linux i uruchamiania ich tak, jakby były rodzime. Ta funkcja wydaje się być w lepszej formie niż powyższe dwa.

  OpenBSD i NetBSD mają podobne funkcje.

OS X zawiera wiele FreeBSD , więc przeniesienie obsługi Linuksa może być proste.

W zasadzie zgadzam się ze wszystkimi, ale chcę dodać, że choć zajęłoby to znaczną ilość czasu i wysiłku, nie byłoby tak dużo, jak zajęło to opracowanie Wine.

Wiele trudności w rozwoju Wine polega na tym, że przenoszą one format binarny z systemu operacyjnego o zamkniętym źródle, a WIELE wywołań systemowych jest nieudokumentowanych. Musieli zasadniczo dokonać inżynierii wstecznej systemu operacyjnego.

Gdyby ktoś zrobił to z jednego otwartego systemu operacyjnego na inny otwarty system operacyjny, prawdopodobnie mógłby to zrobić w 1/10 czasu, ponieważ warstwa kompatybilności mogłaby być całkiem kopiowana / wklejona z innego systemu operacyjnego, jeśli równoważne rodzime wywołanie systemowe nie istnieje Oczywiście w większości przypadków na całym świecie POSIX dostępne będzie połączenie natywne.

Innym ważnym projektem jest ReactOS, w którym zasadniczo tworzą pełną kompatybilną z binarną wersją systemu Windows ... bez potrzeby Wine.

Jest to technicznie wykonalne w systemie macOS, ale nie bez znacznego wysiłku, chociaż część wysiłku jest już dla nas wykonana.

• Zarówno macOS, jak i rebrandowany system Red Hat Enterprise Linux mają certyfikat UNIX 03. Oznacza to, że w zasadzie wywołania POSIX powinny mieć ten sam interfejs API.
• Zarówno macOS, jak i Linux używają System V ABI dla platformy amd64. Oznacza to, że dla amd64 macOS i Linux powinny mieć kompatybilne ABI i API.
• macOS używa Mach-O jako natywnego formatu wykonywalnego, podczas gdy Linux używa ELF. Ułatwia to, ponieważ format pliku wykonywalnego może służyć do rozróżnienia, czy należy wywoływać warstwę zgodności. Wymagałoby to binfmt_miscjednak czegoś takiego .
• Istnieje rozszerzenie jądra macOS innej firmy, które zapewnia dokładnie to. Teraz mamy sposób na załadowanie przekonania macOS do załadowania ELF, potrzebujemy naszego programu specjalnego, ld-linux.soktóry sam jest plikiem wykonywalnym Mach-O, który załaduje nasz ELF i uruchomi go.

Teraz potrzebujemy co najmniej specjalnego, ld-linux.soktóry może wykonać następujące czynności:

• Być plikiem wykonywalnym Mach-O lub dyldsamym sobą,
• Może załadować pliki ELF systemu Linux do pamięci pod odpowiednim adresem,
• Mam nadzieję, że ma możliwość mapowania soname Linuksa na macOS (przykład /lib/libc.so.6na /lib/libSystem.B.dylib) i załadowanie odpowiedniego Mach-O, gdy nie zostanie znaleziony pasujący ELF, więc możemy ponownie użyć bibliotek macOS

Tylko ten moduł ładujący powyżej ELF, który nie wykonuje bezpośrednich wywołań systemowych, ma duże szanse na działanie, ale ELF z wywołaniami systemowymi może nie działać. Drugim przydatnym komponentem byłoby rozszerzenie jądra, które przechwytuje te systemowe wywołania Linuksa i odwzorowuje je na macOS. W przypadku komputerów stacjonarnych potrzebna jest specjalna implementacja mesa do mapowania wywołań graficznych Linuksa do OpenGL.frameworki Metal.framework.

Istnieje wiele wyspecjalizowanych aplikacji dla systemu Linux, dla których byłoby to bardzo pomocne. Po stronie FPGA Quartus i Vivado są dobrymi przykładami programów działających pod Linuksem i jest mało prawdopodobne, aby dostępny był dla nich kod źródłowy lub podobne programy, które są ukierunkowane na najnowsze układy FPGA.

Myślę, że prosta odpowiedź na twoje pytanie brzmi: przekompiluj na MacOS, gdzie masz źródło i utwórz grupę, aby zapewnić możliwości, jeśli masz czas - i będzie to czasochłonne zadanie.