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

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?

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.

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.

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.

8 grudnia 2012 r. Ruszył nowy projekt - Darling.

http://www.darlinghq.org/