เทียบเท่า MacOS 'dll

ดังนั้น DLL จะคล้ายกับโฟลเดอร์ แต่อนุญาตให้หลายโปรแกรม / executables เข้าถึงได้ในครั้งเดียวดังนั้นการอนุรักษ์หน่วยความจำ (ฉันคิดว่า)

อะไรคือสิ่งที่เทียบเท่ากับ Mac ของ DLL? ฉันมองผ่านโฟลเดอร์ Google Chrome ข้างใน~/Library/Application Supportและแทนที่จะเป็น Windows Default.dll ปกติมีเพียงโฟลเดอร์ "Default" เป็นไฟล์ปกติที่มีเนื้อหาฉันถือว่าเป็นประจำจะอยู่ใน DLL

Mac ที่เทียบเท่ามีฟังก์ชั่นเหมือนกันหรือไม่?

macos

— kalaracey
แหล่งที่มา

โฟลเดอร์นั้นเป็นเพียงโปรไฟล์ Chrome ของคุณ (การตั้งค่าส่วนตัวบุ๊กมาร์ก ฯลฯ ) สิ่งที่คุณต้องการอยู่ในชุดแอปพลิเคชัน

— Daniel Beck

เมื่อคุณมองเข้าไปในโฟลเดอร์ / Library / Application Support / Google / Chrome / Default / Extensions / (สตริงยาวแปลก ๆ ) คุณจะพบไฟล์ png และ css จำนวนมากสำหรับธีม มันเป็นโฟลเดอร์ชุดรูปแบบซึ่งพบภายใน DLL บน windows

— kalaracey

ในกรณีนี้ดูเหมือนว่านักพัฒนา Chrome จะใช้กลอุบายเช่นเพื่อประหยัดหน่วยความจำบน Windows พวกเขาไม่ใช้ DLL ที่เทียบเท่ากับ OS X หากคุณดูเช่นที่ Firefox พวกเขาจะเก็บโปรไฟล์ผู้ใช้เป็นไฟล์แต่ละไฟล์ในทุกระบบปฏิบัติการ

— Daniel Beck

ตอนนี้มันน่าสนใจว่าสิ่งที่คุณถามจริง: เกี่ยวกับ "DLLs บน OS X" โดยทั่วไปหรือเทียบเท่ากับdefault.dllใน Mac OS X คำตอบดูเหมือนจะแตกต่างกันมาก

— Daniel Beck

A dllไม่มีโฟลเดอร์หรือที่ใด ๆ ใกล้ ๆ มันมีวิธีการและฟังก์ชั่นที่สามารถเรียกใช้โดยโปรแกรมอื่น ๆ เพื่อให้พวกเขาไม่จำเป็นต้องใช้มันเอง บางครั้ง a dllยังถือทรัพยากรเช่นไอคอน

— Bobby

คำตอบ:

สิ่งที่เทียบเท่ากับ Windows DLL บน OS X คือ Frameworks (Cocoa) หรือ dylibs (BSD) ระบบที่จัดให้มีอยู่ใน/usr/libและ/System/Library/Frameworksตามลำดับ

โฟลเดอร์ที่คุณพูดถึงLibrary/Application Supportคล้ายกับโฟลเดอร์Application Data(หรือAppRoamingตอนนี้?) ใน Windows ที่มีการตั้งค่าส่วนบุคคลของแอปพลิเคชันของคุณ

แม้ว่าฉันจะไม่ทราบว่าเทียบเท่ากับ Chrome default.dllใน OS X แต่ชุดแอปพลิเคชันมีสิ่งต่อไปนี้:

ข้อความแสดงแทน

คาดเดาจากขนาดดูเหมือนว่าGoogle Chrome Frameworkอาจมีความสำคัญ (โฟลเดอร์Frameworksด้านบนมีความสนใจไม่มาก)

— Daniel Beck
แหล่งที่มา

ไม่มี DLLs จริงใน OS X, Linux หรือ POSIX ใด ๆ สำหรับเรื่องนั้น พวกเขาไม่ได้สร้างความแตกต่าง

ทำไม?

สิ่งหนึ่งที่ Mac เป็นจำนวนมากมีอยู่ในตัวเอง (.app เป็นเพียงโฟลเดอร์หลังจากทั้งหมด)
ไบนารีใน Mac OS X (และ Linux และ * Nixes) ใช้ELF (ซึ่งหมายถึง Executable และ Library Format) สำหรับทั้งไลบรารีและไฟล์เรียกทำงาน

ไฟล์เริ่มต้นที่คุณพบอาจเป็นไบนารี ELF

ปรับปรุง : dmckee ชี้ให้เห็นว่า. dylibs อยู่ในรูปแบบMach-O ซึ่งเป็นเอกสิทธิ์ของ Macs อย่างไรก็ตามมันยากที่จะแยกแยะความแตกต่างทั้งสองอย่างด้วยสายตาเพราะพวกเขาไม่ต้องการส่วนขยายใด ๆ

— digitxp
แหล่งที่มา

DLLs บน Windows ใช้รูปแบบเดียวกันกับไฟล์เรียกทำงาน (หรืออย่างน้อยก็ทำทีละครั้ง) ใช่ไหม?

— Daniel Beck

พวกเขายังคงทำ

— digitxp

เป็นการดีที่จะทราบ - เมื่อฉันอ่านโพสต์ของคุณฉันคิดว่าคุณแยก Unixes ออก แต่คุณพูดถึงเอลฟ์เป็นพิเศษ

— Daniel Beck

เอ่อ ... นี่มันผิดนะ อ็อบเจ็กต์ไฟล์ที่แบ่งใช้ (.so) และไลบรารีแบบไดนามิก (.dylib) ทำหน้าที่ตรงตามวัตถุประสงค์เดียวกันบน Linux และ Mac OS เช่นเดียวกับห้องสมุดที่โหลดได้แบบไดนามิก (.dll) บน Windowns ความจริงที่ว่าพวกเขาแบ่งปันมาตรฐานบรรจุภัณฑ์กับไฟล์ปฏิบัติการไม่ได้เปลี่ยนความจริงนี้

— dmckee --- ผู้ดูแลอดีตแมว

@digitxp: คุณพลาดจุดไปแล้ว บรรจุภัณฑ์ไม่สำคัญในเรื่องนี้ Windows .dll's, Mac OS .dylib และ. so ไฟล์ออบเจ็กต์ที่แชร์ (ซึ่ง Mac OS ยังสามารถใช้งานได้แม้ว่าจะไม่ได้สง่างามเท่าที่ใช้. dylib's) ล้วนให้บริการแบบเดียวกัน: ไลบรารีแบบแบ่งใช้ที่รันไทม์และโหลดได้แบบไดนามิก

— dmckee --- ผู้ดูแลอดีตลูกแมว

linux และ Mac ที่ใกล้เคียงที่สุดที่เรียกว่า "ไฟล์วัตถุที่ใช้ร่วมกัน" (มักจะใช้ส่วนขยาย. so) และไลบรารีแบบไดนามิก

มีการใช้วัตถุที่ใช้ร่วมกันอย่างแพร่หลายในระบบ Linux ทั่วไปไลบรารีแบบไดนามิกนั้นไม่แพร่หลายเนื่องจากรูปแบบ. app ช่วยให้มีกลไกการกระจายที่ปลอดภัยมากสำหรับการสนับสนุนสถาปัตยกรรมหลาย ๆ แบบในราคาต้นทุนของไฟล์ "exectuatble ขนาดใหญ่"

— dmckee --- ลูกแมวผู้ดูแลอดีต
แหล่งที่มา