क्या Linux पर OSX प्रोग्राम रन करने योग्य नहीं है?

Question

मुझे पता है कि OSX और Linux के बीच कई अंतर हैं, लेकिन क्या उन्हें इतना अलग बनाता है, जो उन्हें मौलिक रूप से असंगत बना देता है?

Comments

ठीक है, आप लिनक्स पर OSX कार्यक्रमों के चलने की उम्मीद क्यों करेंगे? इन दो विशिष्ट ओएस के बारे में क्या आप सवाल में उनका उल्लेख करते हैं, लेकिन किसी अन्य ओएस पर नहीं जो ओएसएक्स प्रोग्राम भी नहीं चला सकता है?

— wrosecrans

यह मूल रूप से मेरा सवाल है। OSX एक यूनिक्स कर्नेल पर चलता है। मैं सोच रहा था कि इसके बारे में अन्य यूनिक्स / linuxes की तुलना में क्या खास है

— फलामरी

बायनेरिज़ के अंदर गुप्त छोटे सेब होते हैं जिन्हें केवल मैक मशीनें app

— बॉबोबोबो

सामान्य रूप से भिन्न OS एक दूसरे के बायनेरिज़ को नहीं चला सकते हैं; यही कारण है कि स्रोत टारबॉल के रूप में सॉफ्टवेयर को वितरित करने का अभ्यास यूनिक्स के आसपास हुआ। न तो MacOS है और न ही लिनक्स इस संबंध में विशेष कर रहे हैं: यह होगा यदि या तो कुछ खास हो सकता है के अन्य बाइनरी चलाते हैं। Wrosecrans की टिप्पणी का उत्तर देने वाला अधिक उत्कीर्ण टिप्पणी इसके बारे में पूरी तरह से याद आ रही है। : /

— पीटर कॉर्ड्स

Answer 1

पूरे ABI अलग है, न कि केवल द्विआधारी प्रारूप (Mach-O बनाम ELF) जैसा कि sepp2k उल्लेख किया गया है।

उदाहरण के लिए, जबकि लिनक्स और डार्विन / एक्सएनयू (ओएस एक्स के कर्नेल) दोनों ही scपावरपीसी और int 0x80/ sysenter/ syscallपर x86 पर syscall प्रविष्टि के लिए उपयोग करते हैं , वहां से बहुत अधिक नहीं है।

डार्विन ने मैक माइक्रोकाइनल में नकारात्मक syscall संख्या और BSD अखंड कर्नेल पर सकारात्मक syscall संख्याओं को निर्देशित किया - xnu / osfmk / mach / syscall_sw.h और xnu / bsd / kern / syscalls.master देखें । Linux के syscall नंबर आर्किटेक्चर से भिन्न होते हैं - linux / arch / powerpc / see / asm / unistd.h , linux / arch / x86 / / / asm / unistd_32.h , और linux / arch-x86 / / / asm / unistd_64.hh शामिल करें। - लेकिन सभी nonnegative हैं। तो स्पष्ट रूप से syscall नंबर, syscall तर्क और यहां तक ​​कि जो syscall मौजूद हैं वे अलग हैं।

मानक सी रनटाइम लाइब्रेरी भी अलग हैं; डार्विन ज्यादातर फ्रीबीएसडी के परिवाद को विरासत में लेते हैं, जबकि लिनक्स आमतौर पर ग्लिबक का उपयोग करता है (लेकिन एग्लिबेक और डाइटलिब और यूक्लिब और बायोनिक जैसे विकल्प हैं)।

यह उल्लेख करने के लिए नहीं कि पूरे ग्राफिक्स स्टैक अलग हैं; पूरे कोको ऑब्जेक्टिव-सी लाइब्रेरी को अनदेखा करते हुए, OS X पर GUI प्रोग्राम मैक पोर्ट्स पर WindowServer से बात करते हैं, जबकि Linux पर, GUI प्रोग्राम आमतौर पर X11 प्रोटोकॉल का उपयोग करके UNIX डोमेन सॉकेट्स पर X सर्वर से बात करते हैं। बेशक, वहां अपवाद हैं; आप डार्विन पर एक्स चला सकते हैं, और आप लिनक्स पर एक्स को बायपास कर सकते हैं, लेकिन ओएस एक्स एप्लिकेशन निश्चित रूप से एक्स से बात नहीं करते हैं।

शराब की तरह, अगर किसी ने काम में डाल दिया

• माच-ओ के लिए एक बाइनरी लोडर लागू करना
• हर XNU syscall को फँसाना और उसे उपयुक्त Linux syscalls में परिवर्तित करना
• OS X पुस्तकालयों जैसे CoreFoundation के लिए आवश्यकतानुसार लेखन प्रतिस्थापन
• आवश्यकतानुसार OSS सेवाओं के लिए OS X सेवाओं के लिए लेखन प्रतिस्थापन

तब लिनक्स पर "मूल रूप से" एक ओएस एक्स प्रोग्राम चलाना संभव हो सकता है। कई साल पहले, काइल मोफ़ेट ने लिनक्स के लिए एक प्रोटोटाइप binfmt_mach-o का निर्माण करते हुए पहले आइटम पर कुछ काम किया था , लेकिन यह कभी पूरा नहीं हुआ था, और मुझे कोई अन्य समान परियोजनाओं का पता नहीं है।

(सिद्धांत रूप में यह बहुत संभव है, और इसी तरह के प्रयास कई बार किए गए हैं; वाइन के अलावा, लिनक्स के पास अन्य यूनिक्स जैसे एचपी-यूएक्स और ट्रू 64 से चलने वाले बायनेरिज़ के लिए समर्थन है, और ग्लेंडिक्स परियोजना का लक्ष्य 9 9 संगतता लाने का लक्ष्य है लिनक्स।)

---

किसी ने लिनक्स के लिए माच-ओ बाइनरी लोडर और एपीआई अनुवादक को लागू करने के प्रयास में लगा दिया है!

shinh / maloader - GitHub , बाइनरी को लोड करने और यूजर्स कॉल में लाइब्रेरी की सभी कॉल को ट्रैप / ट्रांसलेट करने के लिए वाइन जैसा दृष्टिकोण लेता है। यह पूरी तरह से syscalls और सभी ग्राफिकल से संबंधित पुस्तकालयों की अनदेखी करता है, लेकिन कई कंसोल कार्यक्रमों को काम करने के लिए पर्याप्त है।

डार्लिंग मैलोडर पर बनाता है, पुस्तकालयों और अन्य सहायक रनटाइम बिट्स को जोड़ता है।

Comments

नए प्रयासों के लिए अपने स्वयं के कर्नेल कोड की तुलना में binfmt_misc का उपयोग करने की अधिक संभावना होगी, क्या वे नहीं करेंगे?

— SamB

@SBB: कभी एक chroot में एक binfmt_misc हैंडलर स्थापित करने की कोशिश की? मुझे लगता है कि कर्नेल में अन्य UNIX जैसी प्रणालियों के लिए द्विआधारी स्वरूपों को संभालना उचित है।

— युगान्तर

मेरा सवाल यह है कि; यदि आपने लिनक्स पर चलने के लिए OS X बायनेरिज़ प्राप्त की है, तो आपको OS X लाइब्रेरी और सेवाओं को फिर से लिखने की आवश्यकता क्यों होगी? क्या वे उस समय लिनक्स पर अपरिवर्तित नहीं चलेंगे? क्या यह सिर्फ कानूनी मुद्दों के बारे में है?

— हब्रो

Answer 2

OSX एप्लिकेशन लिनक्स पर मूल रूप से क्यों नहीं चलेंगे:

सबसे पहले ओएसएक्स लिनक्स की तुलना में एक अलग बाइनरी प्रारूप का उपयोग करता है, इसलिए लिनक्स ओएसएक्स के लिए संकलित बायनेरिज़ को निष्पादित नहीं कर सकता है (उसी तरह यह विंडोज या बीएसडी के लिए संकलित बायनेरिज़ को निष्पादित नहीं कर सकता है)।

यदि आप GUI अनुप्रयोगों के बारे में बात कर रहे हैं, तो दूसरा, Apple का GUI टूलकिट a) केवल OSX के लिए उपलब्ध है और b) X11 के शीर्ष पर नहीं चलता है।

OSX अनुप्रयोगों के लिए वाइन के बराबर क्यों नहीं है:

शराब बनाने से पहले भी बहुत काम करना पड़ता था, यहाँ तक कि आधे रास्ते का इस्तेमाल करना भी मुश्किल था। चूँकि OSX समतुल्य की उतनी माँग नहीं है, फिर भी किसी ने इस परियोजना में उतने ही प्रयास का निवेश नहीं किया है।

Comments

तुम्हें पता है, मुझे एहसास भी नहीं था कि OSX / यूनिक्स ने एक ही बाइनरी प्रारूप का उपयोग नहीं किया। क्या आपके पास उस पर अधिक जानकारी के लिए लिंक है?

— फाल्मरी

फल्मरी: OSX माच-ओ प्रारूप का उपयोग करता है, लिनक्स ईएलएफ का उपयोग करता है ।

— sepp2k

@Falmarri सभी यूनीक्स एक ही बाइनरी प्रारूप का उपयोग नहीं करते हैं, और भले ही लगभग सभी आधुनिक ईएलएफ का उपयोग करते हैं, फिर भी आप आमतौर पर एक यूनिक्स से दूसरे पर एक बाइनरी नहीं चला सकते हैं। हेक, मुझे नहीं लगता कि FreeBSD यहां तक ​​कि गारंटी देता है कि आप 8.x या इसके विपरीत पर 7.x के लिए एक प्रोग्राम चला सकते हैं, जबकि 1.0 के लिए लिनक्स प्रोग्राम अभी भी 2.6.x पर चलना चाहिए।

— ephemient

Answer 3

सबसे महत्वपूर्ण कारण है कि OS X ऐप लिनक्स पर नहीं चलेगा क्योंकि उन OSes ने अलग-अलग syscalls का उपयोग किया था।

कुछ पिछले जवाबों ने पुस्तकालयों का उल्लेख किया है, लेकिन यह आमतौर पर ऐसा नहीं है - कोर फाउंडेशन मुख्य रूप से Apple द्वारा किसी भी प्लेटफ़ॉर्म के लिए CFLite और आसानी से पोर्टेबल नाम से खुला है (iTunes का विंडोज संस्करण वास्तव में कोर फाउंडेशन के एक विंडोज पोर्ट के ऊपर बैठता है, और साथ कुछ संकलक ट्विक्स, आप सीधे लिनक्स वितरण पर क्लैंग का उपयोग करके सीफ़लाइट बना सकते हैं) और उद्देश्य-सी पर्यावरण को पोर्ट करने के लिए खुले-खट्टे प्रयास भी हैं, मुख्य रूप से लिनक्स के लिए फाउंडेशन और ऐपिट, सबसे विशेष रूप से जीएनयूस्टेप, ओपनस्टेप का एक जीएनयू कार्यान्वयन। Apple के कोको से पहले (तब शुरू हुआ जब अभी भी कंपनी नेक्सटी कंप्यूटर था।)

यदि कोई निर्धारित किया जाता है, तो वे एक लोडर को डिज़ाइन कर सकते हैं जो प्रत्येक मच-ओ syscall को कैप्चर करेगा और इसे संबंधित लिनक्स syscall में अनुवाद करेगा, साथ ही उन खुले स्रोत लाइब्रेरी "समकक्षों" को बाइनरी के साथ उपयुक्त ABB अनुवाद के साथ जोड़ देगा।

और आपकी जानकारी के लिए, यदि आप Mach-O एप्लिकेशन का स्रोत कोड प्राप्त कर सकते हैं, तो आप इसे पोर्ट मान सकते हैं और यह बहुत सरल हो सकता है। एक उदाहरण के रूप में, OS X 10.6 के साथ बंडल किए गए TextEdit ऐप को सीधे (गैर-महत्वपूर्ण) CF कोड की कुछ पंक्तियों को हटाने के बाद GNUstep से लिंक करके पुन: कनेक्ट किया जा सकता है और इस प्रकार तुरंत लिनक्स के अंतर्गत उपलब्ध होता है (GNUstep के साथ भेजे गए TextDdit का उल्लेख नहीं करना वास्तव में एक था NeXTSTEP से TextEdit ऐप का डायरेक्ट रिजेक्टाइल, OS X के अग्रदूत के रूप में भी, इसके "© 1995 NeXT" लेबल को बरकरार रखना। TextEdit BSD लाइसेंस के तहत है।

Answer 4

8 दिसंबर 2012 को नई परियोजना शुरू की गई है - डार्लिंग।

http://www.darlinghq.org/