Co powoduje, że programy OSX nie działają w systemie Linux?

40

Wiem, że istnieje wiele różnic między OSX a Linuksem, ale co sprawia, że ​​są tak zupełnie różne, co sprawia, że ​​są zasadniczo niezgodne?

linux osx executable compatibility Falmarri
źródło
5
Dlaczego miałbyś oczekiwać, że programy OSX będą działały w systemie Linux? Co z tymi dwoma konkretnymi systemami operacyjnymi sprawia, że ​​wspominasz o nich w pytaniu, ale nie ma żadnego innego systemu operacyjnego, który również nie może uruchamiać programów OSX?
wrosecrans
6
To w zasadzie moje pytanie. OSX działa na jądrze Uniksa. Zastanawiałem się, co sprawia, że ​​jest wyjątkowy w porównaniu do innych unixów / linuksów
Falmarri,
6
W binariach są tajne małe jabłka, które widzą tylko komputery Mac 
bobobobo
Zasadniczo różne systemy operacyjne nie mogą uruchamiać plików binarnych; dlatego praktyka rozpowszechniania oprogramowania jako źródłowych plików archiwalnych wyrosła wokół Uniksa. Ani MacOS, ani Linux nie są pod tym względem wyjątkowi: byłoby czymś wyjątkowym, gdyby jedno z nich mogło uruchomić pliki binarne drugiej strony. Bardziej uprzywilejowany komentarz odpowiadający na komentarz wrosecrans zupełnie nie ma sensu. : /
Peter Cordes

Odpowiedzi:

56

Cały ABI jest inny, nie tylko format binarny (Mach-O kontra ELF), jak wspomniano w sepp2k.

Na przykład, podczas gdy zarówno Linux, jak i Darwin / XNU (jądro OS X) używają scPowerPC i int 0x80/ sysenter/ syscallna x86 do wprowadzania syscall, od tego momentu nie ma już więcej wspólnego.

Darwin kieruje ujemne liczby syscall na mikrojądro Macha, a dodatnie liczby syscall na monolityczne jądro BSD - patrz xnu / osfmk / mach / syscall_sw.h i xnu / bsd / kern / syscalls.master . Numery syscall Linuksa różnią się w zależności od architektury - patrz linux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h oraz linux / arch / x86 / include / asm / unistd_64.h - ale wszystkie są nieujemne. Więc oczywiście liczby syscall, argumenty syscall, a nawet te, które istnieją, są różne.

Standardowe biblioteki środowiska wykonawczego C również są inne; Darwin głównie dziedziczy libc FreeBSD, podczas gdy Linux zwykle używa glibc (ale istnieją alternatywy, takie jak eglibc i dietlibc oraz uclibc i Bionic).

Nie wspominając o tym, że cały stos graficzny jest inny; ignorując całe biblioteki Cocoa Objective-C, programy GUI w OS X rozmawiają z WindowServer przez porty Mach, podczas gdy w Linuksie programy GUI zwykle komunikują się z serwerem X przez gniazda domeny UNIX za pomocą protokołu X11. Oczywiście są wyjątki; możesz uruchomić X na Darwin i możesz ominąć X na Linuksie, ale aplikacje OS X zdecydowanie nie mówią X.

Podobnie jak Wine, jeśli ktoś wkłada pracę

  • implementacja binarnego modułu ładującego dla Mach-O
  • przechwytywanie wszystkich wywołań systemowych XNU i konwertowanie ich na odpowiednie wywołania systemowe Linux
  • pisanie zamienników dla bibliotek OS X, takich jak CoreFoundation, w razie potrzeby
  • pisanie zamienników dla usług OS X, takich jak WindowServer, w razie potrzeby

wtedy możliwe byłoby uruchomienie programu OS X „natywnie” w systemie Linux. Wiele lat temu Kyle Moffet popracował nad pierwszym elementem, tworząc prototyp binfmt_mach-o dla Linuksa, ale nigdy nie został ukończony i nie znam innych podobnych projektów.

(Teoretycznie jest to całkiem możliwe i podobne wysiłki były podejmowane wiele razy; oprócz Wine sam Linux wspiera obsługę plików binarnych z innych UNIXów, takich jak HP-UX i Tru64, a projekt Glendix ma na celu zapewnienie zgodności Planu 9 z Linux.)

Ktoś został umieszczony w celu wdrożenia Mach-O binarny ładowarka i tłumacza API dla Linuksa!

shinh / maloader - GitHub przyjmuje podejście podobne do wina, ładując plik binarny i przechwytując / tłumacząc wszystkie wywołania biblioteki w przestrzeni użytkownika. Całkowicie ignoruje wywołania systemowe i wszystkie biblioteki związane z grafiką, ale wystarczy, aby uruchomić wiele programów konsolowych.

Darling opiera się na złośliwym programie, dodając biblioteki i inne wspierające bity środowiska uruchomieniowego.

efemeryczny
źródło
Nowe wysiłki byłyby znacznie bardziej prawdopodobne, aby użyć binfmt_misc niż mieć własny kod jądra, prawda?
SamB,
@SamB: Czy próbowałeś kiedyś skonfigurować moduł obsługi binfmt_misc w chroot? Myślę, że rozsądne jest obsługiwanie formatów binarnych dla innych systemów typu UNIX w jądrze.
ephemient
1
Moje pytanie brzmi; jeśli masz pliki binarne systemu OS X do działania w systemie Linux, dlaczego miałbyś przepisywać biblioteki i usługi systemu OS X? Czy nie działaliby wtedy w Linuksie bez zmian? Czy chodzi tylko o kwestie prawne?
Hubro,
20

Dlaczego aplikacje OSX nie działają natywnie na systemie Linux:

Po pierwsze OSX używa innego formatu binarnego niż Linux, więc Linux nie może wykonywać plików binarnych skompilowanych dla OSX (w ten sam sposób, w jaki nie może wykonywać plików binarnych skompilowanych dla Windows lub BSD).

Po drugie, jeśli mówisz o aplikacjach GUI, zestaw narzędzi Apple GUI Cocoa a) jest dostępny tylko dla OSX, a b) nie działa na X11.

Dlaczego nie ma odpowiednika wina dla aplikacji OSX:

Trzeba było dużo pracy, zanim wino zdążyło być w połowie użyteczne. Ponieważ zapotrzebowanie na ekwiwalent OSX nie jest tak duże, nikt jeszcze nie zainwestował tyle wysiłku w taki projekt.

sepp2k
źródło
Wiesz, nawet nie zdawałem sobie sprawy, że OSX / unix nie używa tego samego formatu binarnego. Czy masz link do więcej informacji na ten temat?
Falmarri,
Falmarri: OSX używa formatu Mach-O , Linux używa ELF .
sepp2k,
1
@Falmarri Nie wszystkie systemy UNIX używają tego samego formatu binarnego i chociaż prawie wszystkie współczesne używają formatu ELF, nadal ogólnie nie można uruchamiać systemu binarnego z jednego systemu UNIX na drugim. Heck, nie sądzę, że FreeBSD nawet gwarantuje, że możesz uruchomić program dla wersji 7.x na wersji 8.x lub odwrotnie, podczas gdy program dla Linuksa dla wersji 1.0 powinien nadal działać na wersji 2.6.x.
ephemient
5

Najważniejszym powodem, dla którego aplikacje OS X nie będą działały w systemie Linux, jest to, że systemy te używały różnych wywołań systemowych.

W niektórych wcześniejszych odpowiedziach wspomniano o bibliotekach, ale generalnie tak nie jest - Core Foundation jest w dużej mierze pozyskiwana przez Apple pod nazwą CFLite i łatwo przenośna na dowolną platformę (wersja iTunes dla Windows jest właściwie umieszczona na porcie Windows Core Foundation niektóre poprawki kompilatora, możesz bezpośrednio zrobić CFLite za pomocą clang w dystrybucji Linuksa) i podejmowane są również otwarte próby przeniesienia środowiska Objective-C, głównie Foundation i AppKit na Linux, w szczególności GNUstep, implementacja GNU OpenStep, z datą wcześniej niż Apple Cocoa (zaczęło się, gdy istniała jeszcze firma NeXT Computer).

Jeśli ktoś jest zdeterminowany, może zaprojektować moduł ładujący, który będzie przechwytywał każde wywołanie systemowe Mach-O i przetłumaczył je na odpowiednie wywołanie systemowe Linuksa, a także dynamicznie powiązał te „odpowiedniki” biblioteki open source z plikiem binarnym z odpowiednim tłumaczeniem ABI.

I tylko dla twojej informacji, jeśli możesz uzyskać kod źródłowy aplikacji Mach-O, możesz rozważyć przeniesienie go i może okazać się bardzo proste. Na przykład aplikację TextEdit dołączoną do systemu OS X 10.6 można bezpośrednio ponownie skompilować, łącząc z GNUstep po usunięciu kilku wierszy (niekrytycznego) kodu CF, a zatem natychmiast dostępna pod Linuksem (nie wspominając, że TextEdit dostarczany z GNUstep był w rzeczywistości bezpośrednia rekompilacja aplikacji TextEdit od NeXTSTEP, prekursora OS X, nawet zachowując etykietę „© 1995 NeXT”). TextEdit jest na licencji BSD.

Maxthon Chan
źródło