답변:
일반적으로 컴파일 된 프로그램은 CPU에서 "직접 실행"되지만 프로그램은 진공 상태에서 실행되지 않습니다.
많은 프로그램이 동적으로로드 된 외부 라이브러리 ( DLLs또는 .so라이브러리) 에 의존합니다 . 그것들을 연결하는 방법은 컴파일러 / 링커에 달려 있으며 각 OS에는 다른 표준이 있습니다. 그러나 자체 코드를 모두 제공하는 "정적으로 링크 된"프로그램도 있습니다.
최신 OS는 실행중인 프로그램으로 컴퓨터를 완전히 제어하지 못합니다. 프로그램은 I / O에 대한 "시스템 호출", 하드웨어에 대한 액세스 및 신호 및 휴면 상태에 들어가는 것에 의존합니다. 사용 가능한 서비스 및 인터페이스는 OS에 의해 정의됩니다. 또한 OS는 프로그램에서 사용할 수있는 시스템의 일부 (메모리, 레지스터, 인터럽트)를 제어합니다.
GUI 프로그램은 또한 그래픽 사용자 환경을 통해 작동하여 화면에 표시되어야합니다. 그러나 당신은 아마 이것에 대해 이미 생각했을 것입니다.
이러한 이유로 OS 독립적 응용 프로그램은 Java 런타임에서 제공하는 것과 같은 일종의 "가상 컴퓨터"에 의존해야합니다. 결정적으로 VM은 OS 리소스 (i / o, 신호 등)에 대한 표준 인터페이스를 제공합니다. 물론, 자바 나 파이썬은 인텔 명령어 세트의 단점을 다루는 대신 "바이트 코드"를 해석한다. 그러나 그것은 다른 이야기입니다.
OS마다 기능이 다릅니다. Windows에는 I / O 완료 포트가 있고 Linux에는 없습니다. FreeBSD에는 kqueue가 있고 Linux에는 없습니다. 리눅스에는 futex가 있지만 Windows에는 없습니다. 그들은 또한 같은 일을하는 다른 방법을 가지고 있습니다-파일을 열기 위해 어떤 매개 변수를 전달합니까? 그들은 어떤 순서로 들어 갑니까? 운영 체제의 "파일 열기"기능을 구체적으로 호출합니까?
일반적으로 프로그램은 ABI (Application Binary Interface) 의 차이로 인해 호환되지 않습니다 .
프로그램이 CPU에서 직접 실행되지 않습니까?
NO ! CPU에서 응용 프로그램이 "직접"실행 되지 않도록 하는 것이 운영 체제의 작업입니다 . 일반적으로 가장 낮은 수준 (예 : OS API가 구축 된 수준)에서 응용 프로그램은 운영 체제의 커널 과 인터페이스 합니다 .
컴파일 된 프로그램 자체가 OS 특정 라이브러리를 참조해야하기 때문입니까?
예 . 많은 OS 라이브러리는 운영 체제 자체와의 인터페이스를 용이하게하기 위해 작성되었지만 크로스 플랫폼으로 작성된 라이브러리도 많습니다. 이것들은 개발자로부터 저수준 OS 인터페이스를 숨기고 런타임에 해당 OS에 대해 컴파일 된 버전을 사용할 수 있다고 가정합니다 (아래 참조).
라이브러리는 크로스 플랫폼 방식으로 작성 될 수 있지만 컴파일되면 크로스 플랫폼으로 실행할 수 없습니다 . 운영 체제 (커널)의 특정 기본 구성 요소를 다시 사용하려면 특정 대상 운영 체제에 맞게 다시 컴파일해야합니다.
OS별로 컴파일 된 프로그램과 다른 OS의 차이점은 무엇입니까?
마지막으로 실행 파일 자체에는 매우 특정한 이진로드 헤더와 그 밖의 내용 (예 : Windows의 경우 PE 실행 파일 형식 [.exe, .dll 등 ...] 또는 Linux의 경우 ELF [none, .o, .so)가 포함됩니다. 등 ...]). 여기에는 특정 소프트웨어 라이브러리에 대해 컴파일 된 OS 특정 바이너리를로드하는 코드도 포함될 수 있습니다.
마지막으로, 프로그래머의 관점에서 : 호출 규칙 . 컴파일 된 코드는 주어진 방식으로 (즉, 레지스터 또는 스택을 통해) 매우 특정한 순서로 변수를 함수에 전달합니다. 그럼에도 불구하고 기능 호출 (발신자 또는 수신자)을 "정리"할 책임이있는 사람에 대해서도 동의해야합니다. 여러 표준으로 널리 사용되는 x86 호출 규칙이 있지만 일부 운영 체제에서는 지원되지 않을 수 있습니다 (ABI의 일부 임).