จุดยืนของโค้ดที่คอมไพล์แล้วความแตกต่างระหว่างโปรแกรมที่คอมไพล์แล้วสำหรับระบบปฏิบัติการหนึ่งเทียบกับอีกระบบหนึ่ง (เช่น Linux เทียบกับ windows) โปรแกรมไม่ทำงานโดยตรงบน cpu หรือไม่ หรือเป็นเพราะโปรแกรมต้องการอ้างอิงไลบรารีเฉพาะ OS?
จุดยืนของโค้ดที่คอมไพล์แล้วความแตกต่างระหว่างโปรแกรมที่คอมไพล์แล้วสำหรับระบบปฏิบัติการหนึ่งเทียบกับอีกระบบหนึ่ง (เช่น Linux เทียบกับ windows) โปรแกรมไม่ทำงานโดยตรงบน cpu หรือไม่ หรือเป็นเพราะโปรแกรมต้องการอ้างอิงไลบรารีเฉพาะ OS?
คำตอบ:
โปรแกรมที่คอมไพล์ปกติจะ "รันโดยตรง" บน CPU แต่โปรแกรมไม่ทำงานในสุญญากาศ:
โปรแกรมจำนวนมากพึ่งพาไลบรารีภายนอก ( DLLsหรือ.soไลบรารี) ที่โหลดแบบไดนามิก วิธีการเชื่อมโยงนั้นขึ้นอยู่กับคอมไพเลอร์ / ลิงเกอร์และแต่ละระบบปฏิบัติการมีมาตรฐานที่แตกต่างกัน อย่างไรก็ตามยังมีโปรแกรม "ลิงก์แบบคงที่" ที่ให้รหัสของตัวเองทั้งหมด
ระบบปฏิบัติการที่ทันสมัยไม่สามารถควบคุมคอมพิวเตอร์ได้อย่างสมบูรณ์กับโปรแกรมที่กำลังทำงานอยู่ โปรแกรมพึ่งพา "การเรียกของระบบ" สำหรับ i / o การเข้าถึงฮาร์ดแวร์และสิ่งต่าง ๆ เช่นสัญญาณและการเข้าสู่โหมดสลีป บริการและอินเทอร์เฟซที่มีอยู่ถูกกำหนดโดย OS ระบบปฏิบัติการยังควบคุมส่วนต่าง ๆ ของระบบ (หน่วยความจำการลงทะเบียนการขัดจังหวะ) โปรแกรมที่ได้รับอนุญาตให้ใช้
โปรแกรม GUI จะต้องทำงานผ่านสภาพแวดล้อมของผู้ใช้แบบกราฟิกเพื่อวาดตัวเองบนหน้าจอ แต่คุณอาจคิดถึงเรื่องนี้อยู่แล้ว
ด้วยเหตุผลเหล่านี้แอปพลิเคชันที่ไม่ขึ้นกับระบบปฏิบัติการจะต้องพึ่งพา "เครื่องเสมือน" ของบางประเภทเช่นที่จัดทำโดยรันไทม์ของจาวา สิ่งสำคัญที่สุดคือ VM จัดเตรียมอินเตอร์เฟสมาตรฐานให้กับทรัพยากรระบบปฏิบัติการ (i / o, สัญญาณ, ฯลฯ ) แน่นอนว่าจาวาหรือไพ ธ อนตีความ "bytecode" แทนการจัดการกับชุดคำสั่งของ Intel; แต่นั่นเป็นเรื่องที่แตกต่าง
ระบบปฏิบัติการที่แตกต่างกันมีฟังก์ชั่นที่แตกต่างเช่นกัน Windows มีพอร์ต I / O ที่สมบูรณ์ Linux ไม่ได้ FreeBSD มี kqueue, Linux ไม่มี ลินุกซ์มี futexes, Windows ไม่ได้ พวกเขายังมีวิธีที่แตกต่างกันในการทำสิ่งเดียวกัน - คุณส่งผ่านพารามิเตอร์อะไรเพื่อเปิดไฟล์ พวกเขาจะสั่งอะไร คุณเรียกใช้ฟังก์ชัน "เปิดไฟล์" ของระบบปฏิบัติการโดยเฉพาะอย่างไร
โดยทั่วไปโปรแกรมที่เข้ากันไม่ได้เนื่องจากความแตกต่างของพวกเขาอินเตอร์เฟซโปรแกรมไบนารี (ABI)
โปรแกรมไม่ทำงานบน CPU โดยตรงหรือไม่
ไม่ ! นั่นเป็นหน้าที่ของระบบปฏิบัติการเพื่อป้องกันไม่ให้แอปพลิเคชันเรียกใช้ "โดยตรง" บน CPU โดยปกติแล้วที่ระดับต่ำสุด (คือหนึ่งในระบบปฏิบัติการ API จะถูกสร้างขึ้นบน) ซึ่งเป็นอินเตอร์เฟซการประยุกต์ใช้กับระบบปฏิบัติการของเคอร์เนล
เป็นเพราะโปรแกรมที่คอมไพล์เองต้องการอ้างอิงไลบรารีเฉพาะระบบปฏิบัติการหรือไม่
ใช่แล้ว ห้องสมุด OS หลายแห่งถูกเขียนขึ้นเพื่ออำนวยความสะดวกในการเชื่อมต่อกับระบบปฏิบัติการเอง แต่ก็มีมากมายที่เขียนไว้เพื่อเป็นแพลตฟอร์มข้าม สิ่งเหล่านี้ซ่อนการเชื่อมต่อระบบปฏิบัติการระดับต่ำจากนักพัฒนาและสมมติว่าเวอร์ชั่นที่คอมไพล์แล้วสำหรับระบบปฏิบัติการนั้นจะสามารถใช้งานได้ในรันไทม์ (ดูด้านล่าง)
แม้ว่าไลบรารีสามารถเขียนได้ในลักษณะข้ามแพลตฟอร์มเมื่อรวบรวมแล้วจะไม่สามารถเรียกใช้ข้ามแพลตฟอร์มได้ พวกเขายังคงต้องคอมไพล์ใหม่สำหรับระบบปฏิบัติการเป้าหมายที่เฉพาะเจาะจงอีกครั้งเพื่อใช้ส่วนประกอบพื้นฐานของระบบปฏิบัติการ (เคอร์เนล) อีกครั้ง
ความแตกต่างระหว่างโปรแกรมที่คอมไพล์แล้วสำหรับระบบปฏิบัติการหนึ่งกับอีกระบบหนึ่งคืออะไร?
ในที่สุดไฟล์เรียกทำงานตัวเองมักจะมีส่วนหัวโหลดไบนารีที่เฉพาะเจาะจงและอื่น ๆ (เช่นรูปแบบไฟล์PE ปฏิบัติการ [.exe, .dll, ฯลฯ ... ] สำหรับ Windows หรือELFสำหรับ Linux [none, .o, .so ฯลฯ ... ]) สิ่งเหล่านี้ยังสามารถรวมรหัสเพื่อโหลดไบนารีเฉพาะระบบปฏิบัติการที่รวบรวมไว้สำหรับไลบรารีซอฟต์แวร์เฉพาะ
สุดท้ายจากมุมมองของโปรแกรมเมอร์: การเรียกประชุม รหัสที่คอมไพล์ส่งผ่านตัวแปรไปยังฟังก์ชันในลักษณะที่กำหนด (เช่นผ่านการลงทะเบียนหรือบนสแต็ก) ตามลำดับที่เฉพาะเจาะจงมาก ถึงแม้ว่าจะต้องมีการตกลงกันว่าใครเป็นผู้รับผิดชอบในการ "ล้าง" ฟังก์ชั่นการโทร (ผู้โทรหรือผู้โทร?) แม้ว่าจะมีหลายมาตรฐานและใช้กันอย่างแพร่หลายในการประชุมเรียก x86บางคนอาจไม่ได้รับการสนับสนุนโดยระบบปฏิบัติการบางอย่าง (นี่เป็นส่วนหนึ่งของ ABI)