응용 프로그램이 운영체제마다 다른 이유
지금까지의 내용을 정리하며 확인할 수 있다.
각 운영체제는 고유한 system call 집합을 제공한다.
system call 은 응용 프로그램에서 사용할 수 있도록 OS 가 제공하는 서비스 집합이다.
심지어 system call 이 비슷하다 하더라도 내부적인 동작이 달라 응용 프로그램을 다른 OS 에서 사용하진 못했다. 그런데 종종 OS 를 초월하여 사용했던 프로그램은 어떻게 된 것일까? excel, 포토샵 같은건 따로 만들었겠지??
1.
응용 프로그램이 interperter 언어로 작성되었다.
•
코드를 line by line 으로 읽고 해당하는 기계어 명령을 실행하여 각 OS 에 필요한 system call 을 호출하는 inpterpreter를 사용했다. 대신 compile 된 기계 코드가 아니기 때문에 성능을 다소 포기해야 하고, 일부 system call 기능은 제한될 수 있다.
2.
가상 머신을 가진 언어로 작성되었다.
•
가성 머신은 RTE 중에 하나이다. (Java)
•
Java 는 로더, bytecode 검증기 및 java 으용 프로그램을 Java 가상 머신으로 적재하는 구성 요소를 RTE 로 가지고 있다.
•
이론적으로 이 RTE 가 제공되는 어떤 OS 에서도 사용할 수 있다.
•
인터프리터 시스템과 유사한 단점을 가지고 있다.
3.
개발자가 운영체제 별 고유의 이진 파일을 생성하는 표준 언어 또는 API를 사용했다.
•
운영체제 마다 알맞은 테스트와 검증이 필요하다.
•
i.e. UNIX 변종을 대응하기 위한 POSIX API 집합들
위의 방법은 어디까지나 이론적이다. 응용프로그램의 이동성이 부족한 데에는 여러가지 원인이 있다.
운영체제와 함께 GUI 인터페이스와 같은 기능을 제공하는 라이브러리가 포함되어 있다.(iOS API로 만들었다면 Android 에선 당연히 동작하지 않는다.)
다음의 경우를 포함해 시스템의 낮은 수준에서 다른 어려운 점이 존재한다.
•
OS는 header, command 및 변수등의 배치를 강제하는 형식이 있다. 즉 이러한 component는 반드시 특정 위치에 존재해야 하는데 이것이 OS 마다 다를 수 있다.
•
CPU는 다양한 명령어 집합을 가지며 해당 명령어가 포함된 응용 프로그램만 올바르게 실행시킬 수 있다.
•
OS 마다 같은 기능을 하는 system call 이라 하더라도 이름, 매개변수 의미 등등이 다를 수 있다.
◦
파일 생성, 네트워크 연결 등등 필수적인 기능은 모두 system call 에 의존한다.
이러한 구조적인 문제를 완전히 해결하진 못했지만 해결하는데 실마리가 되는 몇가지 방법이 있다.
1.
Linux(Unix) 시스템은 binary 실행 파일이 ELF 형식을 사용한다.
•
공통 표준이라 하더라도 특정 컴퓨터의 구조(architecture) 에 연관되어 있지 않아 실행 파일이 다른 H/W 플랫폼에서 구동된다는 보장은 없다.
2.
아키텍쳐 수준의 API 가 있는데 이것을 ABI(Application Binary Interface)라 한다.
•
ABI 기준으로 개발되었다면 ABI 를 지원 하는 곳에서 사용할 수 있어야 하지만 다음과 같은 문제가 있다.
◦
ABI 는 OS에 의존적이다. 따라서 플랫폼간 호환은 기대할 수 없다.
◦
CPU 의 유형(Intel 과 AMD 등)에 의존적이다.
요약
이러한 모든 차이는 특정 CPU의 특정 OS 에서 interpreter, RTE, binary 실행 파일을 작성하고 compile 하지 않으면 이식성이 없다.
