อะไรทำให้โปรแกรม OSX ไม่สามารถรันได้บน Linux

ฉันรู้ว่ามีความแตกต่างมากมายระหว่าง OSX และ Linux แต่สิ่งที่ทำให้แตกต่างกันอย่างสิ้นเชิงนั่นทำให้พวกเขาไม่ลงรอยกันอย่างลึกซึ้ง?

ABIทั้งหมดนั้นแตกต่างกันไม่ใช่แค่รูปแบบไบนารี (Mach-O กับ ELF) ตามที่ sepp2k พูดถึง

ตัวอย่างเช่นในขณะที่ทั้ง Linux และ Darwin / XNU (เคอร์เนลของ OS X) ใช้scบน PowerPC และint 0x80/ sysenter/ syscallบน x86 สำหรับรายการ syscall แต่ก็มีไม่มากเหมือนกัน

ดาร์วินนำหมายเลข syscall เชิงลบที่ microkernel Mach และหมายเลข syscall บวกที่ BSD เคอร์เนลเสาหิน - ดูxnu / osfmk / จักร / syscall_sw.hและxnu / BSD / kern / syscalls.master หมายเลข syscall ของ Linux แตกต่างกันไปตามสถาปัตยกรรม - ดูlinux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h , และlinux / arch / x86 / include / asm / unistd_64.h - แต่ไม่ติดลบทั้งหมด หมายเลขดังนั้น syscall เห็นได้ชัดว่าข้อโต้แย้ง syscall และแม้กระทั่งซึ่ง syscalls อยู่ที่แตกต่างกัน

ไลบรารีรันไทม์ C มาตรฐานนั้นแตกต่างกันเช่นกัน ดาร์วินส่วนใหญ่สืบทอด libc ของ FreeBSD ในขณะที่ Linux มักใช้ glibc (แต่มีทางเลือกเช่น eglibc และ dietlibc และ uclibc และ Bionic)

ไม่ต้องพูดถึงว่ากราฟิกสแต็กทั้งหมดนั้นแตกต่างกัน ไม่สนใจทั้ง Cocoa Objective-C ไลบรารีโปรแกรม GUI บน OS X คุยกับ WindowServer ผ่านพอร์ต Mach ในขณะที่บน Linux โปรแกรม GUI มักจะพูดคุยกับเซิร์ฟเวอร์ X ผ่านซ็อกเก็ตโดเมน UNIX โดยใช้โปรโตคอล X11 แน่นอนว่ามีข้อยกเว้น; คุณสามารถรัน X บนดาร์วินและคุณสามารถข้าม X บน Linux ได้ แต่แอปพลิเคชัน OS X จะไม่พูดถึง X

เช่นเดียวกับไวน์ถ้าใครบางคนใส่ลงไป

• การใช้งานตัวโหลดไบนารีสำหรับ Mach-O
• ดักทุก XNU syscall และแปลงเป็น Linux syscalls ที่เหมาะสม
• การเขียนทดแทนสำหรับไลบรารี OS X เช่น CoreFoundation ตามต้องการ
• การเขียนการแทนที่บริการ OS X เช่น WindowServer ตามต้องการ

จากนั้นเรียกใช้โปรแกรม OS X "โดยกำเนิด" บน Linux อาจเป็นไปได้ ปีที่แล้ว Kyle Moffet ทำงานบางอย่างในรายการแรกสร้างต้นแบบbinfmt_mach-oสำหรับ Linux แต่ก็ไม่เคยเสร็จและฉันรู้ว่าไม่มีโครงการที่คล้ายกันอื่น ๆ

(ในทางทฤษฎีสิ่งนี้เป็นไปได้และมีความพยายามคล้ายกันหลายครั้งนอกจาก Wine แล้ว Linux ยังรองรับการใช้งานไบนารีจาก UNIX อื่น ๆ เช่น HP-UX และ Tru64 และโครงการGlendixมีเป้าหมายที่จะนำ Plan 9 compatiblity ลินุกซ์.)

มีบางคนพยายามปรับใช้ตัวโหลดไบนารี Mach-O และตัวแปล API สำหรับ Linux!

shinh / maloader - GitHubใช้วิธีคล้ายไวน์ในการโหลดไบนารี่และการดักจับ / แปลการเรียกไลบรารีทั้งหมดใน userspace มันไม่สนใจ syscalls และไลบรารีที่เกี่ยวข้องกับกราฟิกทั้งหมด แต่ก็เพียงพอที่จะทำให้โปรแกรมคอนโซลจำนวนมากทำงานได้

ดาร์ลิ่งสร้างขึ้นบน maloader โดยเพิ่มไลบรารีและบิตสนับสนุนอื่น ๆ

เหตุใดแอปพลิเคชัน OSX จะไม่ทำงานโดยกำเนิดบน linux:

ประการแรก OSX ทั้งหมดใช้รูปแบบไบนารีที่แตกต่างจาก Linux ดังนั้น Linux จึงไม่สามารถเรียกใช้ไบนารีที่รวบรวมสำหรับ OSX (เช่นเดียวกับที่ไม่สามารถเรียกใช้ไบนารีที่รวบรวมสำหรับ Windows หรือ BSD)

ประการที่สองหากคุณกำลังพูดถึงแอปพลิเคชั่น GUI ชุดเครื่องมือ GUI ของ Apple Cocoa a) จะใช้ได้เฉพาะกับ OSX และ b) ไม่สามารถทำงานบน X11 ได้

ทำไมไม่มีไวน์เทียบเท่าสำหรับแอปพลิเคชัน OSX:

งานจำนวนมากต้องทำก่อนที่ไวน์จะสามารถใช้งานได้ครึ่งทาง เนื่องจากมีความต้องการไม่มากเท่ากับ OSX จึงยังไม่มีใครลงทุนในโครงการดังกล่าว

เหตุผลที่สำคัญที่สุดที่แอป OS X จะไม่ทำงานบน Linux นั้นเป็นเพราะระบบปฏิบัติการเหล่านั้นใช้ syscalls ที่ต่างกัน

บางคำตอบก่อนหน้านี้กล่าวถึงห้องสมุด แต่โดยทั่วไปไม่ใช่ - Core Foundation ส่วนใหญ่เปิดมาจาก Apple ภายใต้ชื่อ CFLite และพกพาไปยังแพลตฟอร์มใด ๆ ได้อย่างง่ายดาย (เวอร์ชั่น Windows ของ iTunes ตั้งอยู่บนพอร์ต Windows ของ Core Foundation และด้วย คอมไพเลอร์ปรับแต่งคุณสามารถสร้าง CFLite โดยใช้เสียงดังกราวบนการกระจาย Linux) และยังมีความพยายามในการเปิดแหล่งที่มากับสภาพแวดล้อมของ Objective-C ซึ่งส่วนใหญ่เป็น Foundation และ AppKit to Linux โดยเฉพาะ GNUstep, GNU ของ OpenStep เร็วกว่าแอปเปิ้ลโกโก้ (เริ่มต้นเมื่อยังมี บริษัท NeXT Computer อยู่)

หากมีใครพิจารณาแล้วพวกเขาสามารถออกแบบตัวโหลดที่จะดักจับ syscall ทุก Mach-O และแปลไปยัง Linux syscall ที่สอดคล้องกันรวมทั้งเชื่อมโยงไลบรารีโอเพนซอร์สเหล่านั้น "คู่" กับไบนารีด้วยการแปล ABI ที่เหมาะสม

และสำหรับข้อมูลของคุณหากคุณสามารถรับซอร์สโค้ดของแอปพลิเคชัน Mach-O คุณอาจพิจารณาพอร์ตและมันอาจกลายเป็นเรื่องง่ายมาก ตัวอย่างแอพ TextEdit ที่มาพร้อมกับ OS X 10.6 สามารถทำการคอมไพล์ใหม่เชื่อมโยงกับ GNUstep ได้โดยตรงหลังจากดึงรหัส CF (ไม่สำคัญ) ไปสองบรรทัดและทันทีที่ใช้ภายใต้ Linux (ไม่ต้องพูดถึง TextEdit ที่ส่งมากับ GNUstep recompile โดยตรงของแอพ TextEdit จาก NeXTSTEP ซึ่งเป็นสารตั้งต้นไปยัง OS X เช่นกันแม้จะยังคงฉลาก "© 1995 NeXT" ไว้) TextEdit อยู่ภายใต้ใบอนุญาต BSD

เมื่อวันที่ 8 ธันวาคม 2012 เปิดตัวโครงการใหม่ - ดาร์ลิ่ง

http://www.darlinghq.org/