Differenza tra i programmi compilati per diversi sistemi operativi

8

Dal punto di vista del codice compilato qual è la differenza tra un programma compilato per un sistema operativo rispetto a un altro (Linux vs Windows per esempio). Il programma non viene eseguito direttamente sulla CPU? O è perché il programma deve fare riferimento a librerie specifiche del sistema operativo?

cpu operating-systems compile

— AGZ
fonte

6

I programmi compilati ordinari "eseguono direttamente" sulla CPU, ma un programma non funziona nel vuoto:

Molti programmi si basano su librerie ( DLLso .solibrerie) esterne, caricate dinamicamente . Il modo di collegarli dipende dal compilatore / linker e ogni sistema operativo ha standard diversi. Tuttavia, esistono anche programmi "collegati staticamente" che forniscono tutto il proprio codice.
Un sistema operativo moderno non fornisce il controllo completo del computer a un programma in esecuzione. I programmi si basano su "chiamate di sistema" per I / O, accesso all'hardware e cose come segnali ed entrare in uno stato di sospensione. I servizi e l'interfaccia disponibili sono definiti dal sistema operativo. Il sistema operativo controlla anche quali parti del sistema (memoria, registri, interruzioni) possono essere utilizzate dal programma.
Un programma GUI deve anche funzionare attraverso l'ambiente utente grafico per poter disegnare da solo sullo schermo. Ma probabilmente ci hai già pensato.

Per questi motivi, le applicazioni indipendenti dal sistema operativo devono fare affidamento su una "macchina virtuale" di qualche tipo, come quella fornita dal runtime java. Fondamentalmente, una VM fornisce un'interfaccia standard alle risorse del sistema operativo (I / O, segnali, ecc.). Naturalmente, java o python interpretano anche "bytecode" invece di occuparsi delle stranezze del set di istruzioni di Intel; ma questa è una storia diversa.

— alexis
fonte

Inoltre, diversi sistemi operativi hanno standard diversi per il layout dello stack, le pratiche di allineamento della memoria, ecc. Pertanto, anche il codice puramente numerico / computazionale potrebbe dover differire da un sistema operativo all'altro.

— Daniel R Hicks,

Queste differenze impedirebbero l'esecuzione del codice compilato staticamente? Non lo sapevo ..

— alexis,

Probabilmente è solo un problema teorico, dal momento che qualche altra incompatibilità ti porterebbe prima. Ma i sistemi operativi hanno spesso aspettative su come allineare i frame dello stack, dove sono memorizzati i registri, ecc. Questi possono variare da un sistema operativo all'altro in base alla stessa architettura hardware. In teoria potresti essere in grado di ESEGUIRE codice "estraneo" che è puramente computazionale, ma non saresti mai in grado di avviarlo e non riusciresti mai a terminarlo in modo pulito.

— Daniel R Hicks,

5

Diversi sistemi operativi hanno anche funzionalità diverse. Windows ha porte di completamento I / O, Linux no. FreeBSD ha kqueue, Linux no. Linux ha futex, Windows no. Hanno anche diversi modi di fare la stessa cosa: quali parametri passi per aprire un file? In che ordine vanno? Come invocate in modo specifico la funzione "apri un file" del sistema operativo?

— David Schwartz
fonte

ok ha senso, ma in generale, il programma carica in memoria ed esegue sulla cpu, oppure il sistema operativo "ha il controllo" sul programma

— agz

1

@agovizer: entrambi. Non si escludono a vicenda. In genere, il sistema operativo imposta un ambiente controllato e fa in modo che l'hardware interrompa il programma in un determinato periodo di tempo, quindi passa il core al programma. Ma non appena il programma rileva un numero qualsiasi di condizioni (come un errore di pagina, un'operazione di I / O o simili), il sistema operativo riprende il controllo.

— David Schwartz,

5

In generale, i programmi non sono compatibili a causa delle differenze nell'interfaccia binaria dell'applicazione (ABI) .

Il programma non viene eseguito direttamente sulla CPU?

NO ! Questo è il compito del sistema operativo, impedire alle applicazioni di essere eseguite "direttamente" sulla CPU. In genere, al livello più basso (ovvero quello su cui è basata l'API del sistema operativo), un'applicazione si interfaccia con il kernel del sistema operativo .

È perché lo stesso programma compilato deve fare riferimento a librerie specifiche del sistema operativo?

Sì . Molte librerie del sistema operativo sono state scritte per facilitare l'interfacciamento con il sistema operativo stesso, ma ce ne sono altrettante scritte per essere multipiattaforma. Questi nascondono l'interfaccia dello sviluppatore di basso livello dallo sviluppatore e presumono che la versione compilata per quel sistema operativo sarà disponibile in fase di esecuzione (vedi sotto).

Sebbene le librerie possano essere scritte in modo multipiattaforma, una volta compilate non possono essere eseguite multipiattaforma. Devono ancora essere ricompilati per il sistema operativo di destinazione specifico, di nuovo per utilizzare i componenti sottostanti specifici del sistema operativo (kernel).

Qual è la differenza tra un programma compilato per un sistema operativo rispetto a un altro?

Infine, i file eseguibili stessi contengono spesso intestazioni di caricamento binario molto specifiche e così via (ad esempio il formato di file eseguibile PE [.exe, .dll, ecc ...] per Windows o ELF per Linux [none, .o, .so , eccetera...]). Questi possono anche includere codice per caricare i binari compilati specifici del sistema operativo per una particolare libreria software.

Infine, dal punto di vista di un programmatore: chiamare la convenzione . Il codice compilato trasmette le variabili alle funzioni in un determinato modo (cioè attraverso registri o nello stack) in un ordine molto particolare. Anche in questo caso, deve essere concordato anche chi è il responsabile della "pulizia" delle chiamate di funzione (il chiamante o il chiamante?). Sebbene esistano diverse convenzioni di chiamata x86 standard e ampiamente utilizzate , alcune potrebbero non essere supportate da alcuni sistemi operativi (fa parte dell'ABI).

— Sfondamento
fonte