En el punto de vista del código compilado, ¿cuál es la diferencia entre un programa compilado para un sistema operativo frente a otro (Linux frente a Windows, por ejemplo)? ¿El programa no se ejecuta directamente en la CPU? ¿O es porque el programa necesita hacer referencia a bibliotecas específicas del sistema operativo?
Los programas compilados ordinarios "se ejecutan directamente" en la CPU, pero un programa no se ejecuta en el vacío:
Muchos programas se basan en bibliotecas ( DLLso .sobibliotecas) externas cargadas dinámicamente . La forma de vincularlos depende del compilador / vinculador, y cada sistema operativo tiene diferentes estándares. Sin embargo, también hay programas "vinculados estáticamente" que proporcionan todo su propio código.
Un sistema operativo moderno no le da el control completo de la computadora a un programa en ejecución. Los programas se basan en "llamadas del sistema" para E / S, acceso al hardware y cosas como señales y entrar en un estado de suspensión. Los servicios disponibles y la interfaz están definidos por el sistema operativo. El sistema operativo también controla qué partes del sistema (memoria, registros, interrupciones) puede usar el programa.
Un programa GUI también debe funcionar a través del entorno gráfico de usuario para dibujarse en la pantalla. Pero probablemente ya hayas pensado en esto.
Por estas razones, las aplicaciones independientes del sistema operativo deben confiar en una "máquina virtual" de algún tipo, como la que proporciona el tiempo de ejecución de Java. De manera crucial, una VM proporciona una interfaz estándar para los recursos del sistema operativo (E / S, señales, etc.). Por supuesto, java o python también interpretan "bytecode" en lugar de tratar con las peculiaridades del conjunto de instrucciones de Intel; Pero esa es una historia diferente.
Los diferentes sistemas operativos también tienen una funcionalidad diferente. Windows tiene puertos de finalización de E / S, Linux no. FreeBSD tiene kqueue, Linux no. Linux tiene futexes, Windows no. También tienen diferentes formas de hacer lo mismo: ¿qué parámetros pasas para abrir un archivo? ¿En qué orden entran? ¿Cómo invocas específicamente la función "abrir un archivo" del sistema operativo?
fuente
En general, los programas no son compatibles debido a las diferencias en su interfaz binaria de aplicación (ABI) .
NO ! Ese es el trabajo del sistema operativo, evitar que las aplicaciones se ejecuten "directamente" en la CPU. Normalmente, en el nivel más bajo (es decir, en el que se basa la API del sistema operativo), una aplicación interactúa con el núcleo del sistema operativo .
Sí . Muchas bibliotecas del sistema operativo están escritas para facilitar la interfaz con el sistema operativo en sí, pero hay tantas que están escritas para ser multiplataforma. Estos ocultan la interfaz del sistema operativo de bajo nivel del desarrollador, y asume que la versión compilada para ese sistema operativo estará disponible en tiempo de ejecución (ver más abajo).
Aunque las bibliotecas se pueden escribir de manera multiplataforma, cuando se compilan no se pueden ejecutar multiplataforma. Todavía deben volver a compilarse para el sistema operativo de destino específico, nuevamente para utilizar los componentes subyacentes particulares del sistema operativo (kernel).
Finalmente, los archivos ejecutables a menudo contienen encabezados de carga binarios muy específicos y demás (por ejemplo, el formato de archivo ejecutable PE [.exe, .dll, etc ...] para Windows o ELF para Linux [ninguno, .o, .so , etc ...]). Estos también pueden incluir código para cargar los binarios compilados específicos del sistema operativo para una biblioteca de software en particular.
Por último, desde la perspectiva de un programador: convocatoria de convenciones . El código compilado pasa variables a funciones de una manera dada (es decir, a través de registros o en la pila) en un orden muy particular. Incluso entonces, también debe acordarse quién es responsable de "limpiar" las llamadas de función (¿la persona que llama o la persona que llama?). Aunque hay varias convenciones de llamadas x86 estándar y ampliamente utilizadas , algunas pueden no ser compatibles con ciertos sistemas operativos (esto es parte de la ABI).
fuente