Perbedaan antara program yang dikompilasi untuk OS yang berbeda

8

Pada sudut pandang kode yang dikompilasi, apa perbedaan antara program yang dikompilasi untuk satu os vs yang lain (Linux vs windows misalnya). Bukankah program berjalan langsung di cpu? Atau apakah itu karena program perlu referensi perpustakaan OS tertentu?

cpu operating-systems compile

— agz
sumber

6

Program yang dikompilasi biasa melakukan "berjalan langsung" pada CPU, tetapi sebuah program tidak berjalan dalam ruang hampa:

Banyak program bergantung pada pustaka ( DLLsatau .sopustaka) eksternal yang dimuat secara dinamis . Cara untuk menghubungkan mereka adalah dengan compiler / linker, dan setiap OS memiliki standar yang berbeda. Namun, ada juga program "yang terhubung secara statis" yang menyediakan semua kode mereka sendiri.
OS modern tidak memberikan kendali penuh komputer ke program yang sedang berjalan. Program bergantung pada "panggilan sistem" untuk i / o, akses ke perangkat keras, dan hal-hal seperti sinyal dan memasuki kondisi tidur. Layanan dan antarmuka yang tersedia ditentukan oleh OS. OS juga mengontrol bagian mana dari sistem (memori, register, interupsi) yang diizinkan untuk digunakan oleh program.
Program GUI juga harus bekerja melalui lingkungan pengguna grafis untuk menggambar dirinya sendiri di layar. Tapi Anda mungkin sudah memikirkan hal ini.

Untuk alasan ini, aplikasi independen OS harus bergantung pada "mesin virtual", seperti yang disediakan oleh runtime java. Yang terpenting, VM menyediakan antarmuka standar untuk sumber daya OS (i / o, sinyal, dll). Tentu saja, java atau python juga mengartikan "bytecode" alih-alih berurusan dengan kebiasaan set instruksi Intel; tapi itu cerita yang berbeda.

— Alexis
sumber

Selain itu, OS yang berbeda memiliki standar yang berbeda untuk tata letak tumpukan, praktik penyelarasan memori, dll, sehingga bahkan kode numerik / komputasi murni mungkin perlu berbeda dari satu OS ke yang berikutnya.

— Daniel R Hicks

Apakah perbedaan ini mencegah eksekusi kode yang dikompilasi secara statis? Tidak tahu itu ..

— alexis

Ini mungkin hanya masalah teoretis, karena beberapa ketidakcocokan akan membuat Anda lebih dulu. Tetapi OS sering memiliki harapan untuk bagaimana frame stack disejajarkan, di mana register disimpan, dll. Ini dapat bervariasi dari satu OS ke yang berikutnya untuk arsitektur perangkat keras yang sama. Secara teori Anda mungkin dapat MENJALANKAN kode "asing" yang murni komputasi, tetapi Anda tidak akan pernah bisa memulainya dan tidak pernah bisa mengakhirinya dengan bersih.

— Daniel R Hicks

5

OS yang berbeda memiliki fungsi yang berbeda pula. Windows memiliki port penyelesaian I / O, Linux tidak. FreeBSD memiliki kqueue, Linux tidak. Linux memiliki futex, Windows tidak. Mereka juga memiliki cara berbeda untuk melakukan hal yang sama - parameter apa yang Anda berikan untuk membuka file? Pesanan apa yang mereka masukkan? Seberapa spesifik Anda menjalankan fungsi "buka file" sistem operasi?

— David Schwartz
sumber

ok itu masuk akal, tetapi secara umum, apakah program memuat ke dalam memori dan berjalan pada cpu, atau apakah os "memiliki kendali" atas program

— agz

1

@agovizer: Keduanya. Mereka tidak saling eksklusif. Biasanya, OS akan mengatur lingkungan yang terkendali dan mengatur perangkat keras untuk mengganggu program dalam jumlah waktu tertentu dan kemudian menyerahkan inti ke program. Tetapi begitu program mencapai sejumlah kondisi (seperti kesalahan halaman, operasi I / O, atau sejenisnya), OS mengambil alih lagi.

— David Schwartz

5

Secara umum, program tidak kompatibel karena perbedaan dalam antarmuka biner aplikasi mereka (ABI) .

Bukankah program dijalankan langsung pada CPU?

TIDAK ! Itulah tugas sistem operasi, untuk mencegah aplikasi menjalankan "langsung" pada CPU. Biasanya, pada level terendah (yaitu OS API dibangun), sebuah aplikasi berinteraksi dengan kernel sistem operasi .

Apakah karena program yang dikompilasi sendiri perlu merujuk pustaka spesifik OS?

Ya . Banyak pustaka OS ditulis untuk memfasilitasi interfacing dengan sistem operasi itu sendiri, tetapi ada juga banyak yang ditulis sebagai cross-platform. Ini menyembunyikan antarmuka OS tingkat rendah dari pengembang, dan mengasumsikan versi yang dikompilasi untuk OS tersebut akan tersedia saat runtime (lihat di bawah).

Meskipun perpustakaan dapat ditulis secara lintas platform, ketika dikompilasi mereka tidak dapat dijalankan lintas platform. Mereka masih perlu dikompilasi ulang untuk sistem operasi target spesifik, sekali lagi untuk memanfaatkan komponen-komponen dasar yang mendasari sistem operasi (kernel).

Apa perbedaan antara program yang dikompilasi untuk satu OS vs yang lain?

Akhirnya, file yang dapat dieksekusi sendiri sering mengandung header pemuatan biner yang sangat spesifik dan sebagainya (mis. Format file PE Executable [.exe, .dll, dll ...] untuk Windows, atau ELF untuk Linux [tidak ada, .o, .so , dll ...]). Ini juga dapat mencakup kode untuk memuat binari yang dikompilasi OS spesifik untuk perpustakaan perangkat lunak tertentu.

Terakhir, dari perspektif programmer: konvensi pemanggilan . Kode yang dikompilasi meneruskan variabel ke fungsi dengan cara tertentu (yaitu melalui register, atau di stack) dalam urutan yang sangat khusus. Bahkan kemudian, juga harus disepakati siapa yang bertanggung jawab untuk "membersihkan" panggilan fungsi (penelepon atau callee?). Meskipun ada beberapa konvensi pemanggilan x86 standar dan banyak digunakan , beberapa mungkin tidak didukung oleh sistem operasi tertentu (ini adalah bagian dari ABI).

— Penerobosan
sumber