casaubon
2007/12/08, 11:17 PM
<h1><font color=red>PE U: The Mac OS X Leopard Windows API Myth</font></h1>December 5th, 2007 | Markets, Tech, the Media
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/200712050332.jpg"></center>
<b>Daniel Eran Dilger</b>
좀처럼 사라지지 않는 아이디어가 있다. 맥오에스텐 레퍼드 윈도 API 미신의 신봉자들은, 맥오에스텐 내부에 마이크로소프트 윈도를 돌려야 할 절대적인 필요성이 꼭 있다고 보고 있다. 이 때문에 그런 힌트라도 보인다고 하면 이들은 곧 이 일이 일어나리라 장담하곤 한다. 최근 레퍼드가 PE 파일을 읽어들이고 윈도 DLL 파일을 리퀘스트한다는 주제가 떠올랐다. 타이거에서는 이런 것이 없었기에 새로운 발견이라 짐짓 결정내려버린 전문가들이 있다. 이들은 바로 선정적인 태도로 넘어간다. 애플이 비밀리에 윈도 API를 구현시키고 있으며, 그로 인하여 맥이 윈도 프로그램도 네이티브로 돌리리라는 주장이다. 그들은 틀렸다. 왜인지 알아보자.
<b>This All Happened Before.</B>
지난 해, 필자는 레드박스 미신을 2006년 애플을 둘러싼 10대 미신 중 하나로 강조하였다. 새로운 이유도 없잖지만, 이 미신과 관련된 최신 루머도 똑같은 이유에서 미신일 수 밖에 없다.
"레드박스"라는 아이디어가 있다. 맥 데스크톱 상에서 윈도용 애플리케이션을 네이티브로 돌린다는 개념이다. 문제는 이 기술을 실제로 제공하는 것이 시간여행의 문제처럼 전혀 다른 문제라는 데에 있다. 즉, 시간여행처럼 추측만 가능할 뿐이다. 물론 시간여행처럼 그 어려운 악조건에도 불구하고 상상력만은 없앨 수가 없다. 그래서 레드박스 개념은 꾸준히 나오고 있다.
로버트 크린즐리라는 필명으로 글을 쓰는 마크 스티븐스(Mark Stephens)가 지난 해, 레드박스 미신을 거론하면서, 1997년 마이크로소프트와의 상호특허 인정 계약이 있으니 별다른 수고를 들이지 않고도 할 수 있으리라 추측하였다. 두 회사가 상호 특허 포트폴로이를 두고 서로 고소하지 않기로 동의하였으며, 애플이 윈도 소스코드에 대한 접근권도 어느 정도 있잖을까라는 주장이었다. 즉, 애플이 원하는 식으로 윈도 소스코드를 라이센스해서 바로 활용할 수 있다는 의미였다. 완전히 터무니 없는 주장이다.
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/rd-q4.06-5d46aa85-a561-44c3-af5e-a61a54fae472-files-red-box.jpg"></center>
<A href="http://www.appleforum.com/378985-post8.html" target="_new">Myth 8: 레드박스 미신</a>
<b>Really, Really Hard Problems.</B>
현실적으로 마이크로소프트 코드와 개발툴, 미래 전략계획에 완전히, 무제한적으로 접근이 가능하다 하더라도, 맥 상에서 "윈도 API"를 제공하기란 쉽지 않다. 일반인들은 복잡한 소프트웨어를 제공한다는 사실이 얼마나 어려운지 잘 인식을 못한다. 생각해 보시라.
<ol><li> 마이크로소프트가 비스타를 내놓는 데에 걸린 시간만 7년이 넘어간다. 그것도 매번 완전히 재시작해야 했다. "똑같은 윈도 API"에 몇 가지 변화와 추가만 했음에도 불구하고 비스타는 여전히 하드웨어 호환문제와 퍼포먼스 문제, 수 많은 보안과 안정성 문제를 안고 있으며, 이 문제를 해결하는 데에도 수 년이 걸릴 것이다.
<li> 애플 또한 클래식 맥 API를 카본이라는 형태로, 맥오에스텐 환경에 이식하는 데에만 수 년이 걸렸다. 완전히 제공하는 데에는 5년이 걸렸으며, 2002년 맥오에스텐 10.2 재규어가 나온 이후 지난 5년간 매번 개선을 거듭해왔다. 카본을 NeXTSTEP, 즉, 맥오에스텐으로 통합시키는 일은 두 체제 모두에게 상당한 변화를 요구하였다.
애플은 두 환경 모두를 온전히 갖고 있으며, 친숙한 엔지니어들도 많이 고용하고 있다. 그럼에도 불구하고 양측을 하나의 패키지로 심어 놓는 데에 여전히 문제점이 남아 있었다. 윈도 환경 이식은 훨씬 더 복잡한 문제다. 애플이 자신에 맞게 윈도를 변경시킬 수 없기 때문이다. 마찬가지 이유로, 윈도에 대한 마이크로소프트의 정의도 독립적인 방향으로 움직이게 되어 있다.
<li> 오픈소스 커뮤니티가 몇 가지 독립 프로젝트로 윈도 API에 대한 대안을 작업해왔다. 윈도 NT의 클론인 ReactOS 프로젝트와, 유닉스-류 운영체제에서 네이티브 API로 윈도 API를 매핑하는 프로젝트, 와인(Wine)이 있다. 와인은 14년동안 개선을 거듭해왔지만, 여전히 실험적인 단계다.
위 프로젝트 모두, 매우 뛰어난 엔지니어들이 상당히 많이 투입된 프로젝트이다. 제품을 더 낫게, 더 빠르게 만들 능력이 있었더라면 벌써 그렇게 나왔을 것이다. 위 프로젝트 모두 각 그룹이 제공할 수 있는 최선의 상태이다. </ol>
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/wp-content-uploads-2007-10-rd-rdm.tech.q3.07-9dd78403-fe1b-4da1-a757-84e24cb642a3-files-iphone-2.jpg"></center>
<A href="http://www.appleforum.com/401586-post1.html" target="_new">iPhone의 OS X과 Leopard, 그리고 Vista</a>
<A href="http://www.appleforum.com/383645-post1.html" target="_new">1995년은 2007년에 되풀이될 수 없다</A>
<b>Solvable Problems.</B>
맥 상에서 윈도 애플리케이션을 돌린다는 아이디어가 해결할 수 없는 문제까지는 아니다. PowerPC 맥도 에뮬레이션으로 윈도 애플리케이션을 돌릴 수 있었다. 가상 PC 환경을 만들어주는 소프트웨어 레이어 상에 윈도를 설치하여 돌리는 식이다. 인텔 맥에서는 부트캠프를 통해 바로 네이티브 윈도를 돌릴 수 있으며, Parallels Desktop이나 Fusion과 같은 환경을 사용하여 돌릴 수 있다.
하지만 이러한 해결책 모두 윈도 정본을 필요로 한다. 즉, 마이크로소프트는 PC 업체들에게 OEM으로 윈도를 파는 것보다 10 배 이상의 값으로 맥 사용자들에게 윈도를 행복하게 판매할 수 있다. Wine이나 레드박스 개념은 윈도 자체를 교체하자는 식이다. 따라서 윈도용 애플리케이션도 윈도 설치를 하지 않고서도 돌릴 수 있는 개념이다.
그런 문제가 해결 불가능까지는 아니다. TransGaming Technologies에서 판매하는 와인이 있는데, 이 와인은 특정 윈도 프로그램을 윈도 없이 실행 가능하게 해 준다. 이 제품은 리눅스 상에서 윈도용 게임(혹은 애플 아이튠스나 마이크로소프트 오피스)을 돌리도록 해 주며, EA Games도 올해 인텔맥용 게임을 선보일 때 이 제품을 활용했었다. Parallels도 와인 일부를 사용하여 DirectX 지원을 다룬다.
<b>Unsolvable Problems.</B>
그러나 범용 목적의 시스템으로서, 윈도 없는 윈도 애플리케이션은 훨씬 더 어렵다. 맥 데스크톱과의 통합은 훨씬 더 복잡한 문제다. 어느 시점에서라도 마이크로소프트는, 손쉽게 호환성을 깨는 윈도 API를 수정할 수 있으며, 유사 윈도 환경을 거부하는 코드를 사용해 오피스를 내놓을 수도 있다.
이미 90년대 초 IBM이 이 점을 발견한 바 있다. 당시 마이크로소프트는 OS/2의 경쟁압력을 모두 없애려 하였다. OS/2는 마이크로소프트와의 협력에 따라 윈도용 애플리케이션을 돌릴 예정이었다. 윈도 API 사용허가를 받은 IBM의 OS/2한테 마이크로소프트가 저지른 일을 기억하신다면, 경쟁자에게는 마이크로소프트가 어떻게 대처할지 상상해 보시라! 보다 최근 사례를 들어 보자. 마이크로소프트는 코렐의 와인 프로젝트 지원을 중단시키기 위해, 코렐에 투자를 거행하였다. 또한 윈도 업데이트를 돌릴 때, 와인을 특별히 확인하도록 하였다.
애플의 자원은 제한적이다. 설사 15년에 걸친 와인도 할 수 없는 기술을 애플이 갖고 있다 하더라도, 마이크로소프트가 Win32를 죽이고 새로이 .Net과 관계있는 윈도 API를 새로이 내놓는다는 점을 애플이 깡그리 무시한다 하더라도, 그런 대안적인 솔루션을 애플이 직접 하는 편보다, 더 이윤이 많이 날 일이 많이 있다.
<b>Imagine the Outcry.</B>
이미 Paralles나 Fusion, 그 외 상용 제품들이 맥오에스텐에서 윈도 호환 환경을 열심히 제공해 놓았다. 이런 상황에서 갑자기 애플이 나서면 어떤 꼴이 되어버릴까?
애플이 Sherlock 3.0, 그리고 Dashboard를 선보였을 때, 전문가들은 애플이 써드파티 개발자들을 저버렸다면서 주먹을 휘두르고 병을 깨뜨리며 옷을 찢는 등, 난리도 아니었다. 이들이 흐르는 악어의 눈물은 거의 노아의 대홍수급이다. 그러나 Karelia Watson과 Konfabulator의 사례를 보면, 애플은 고유의 소프트웨어로 방향을 분명히 하여 확장을 했을 뿐이었다. 오로지 Paralles와 Fusion 시장을 파괴시키기 위, 이미 해결책이 있는 시장에서 애플이 개발에 나서야 할 필요가 있을까? 애플이 레드박스를 만들 수 있다는 것 이상으로 더 웃기는 일이 아닐 수 없다.
<A href="http://www.appleinsider.com/articles/07/10/19/road_to_mac_os_x_leopard_dashboard_spotlight_and_t he_desktop.html&page=2" target="_new">AppleInsider | Road to Mac OS X Leopard: Dashboard, Spotlight and the Desktop: Watson</a>
<A href="http://www.appleinsider.com/articles/07/10/19/road_to_mac_os_x_leopard_dashboard_spotlight_and_t he_desktop.html&page=3" target="_new">AppleInsider | Road to Mac OS X Leopard: Dashboard, Spotlight and the Desktop: Konfabulator</a>
<b>Be Careful What You Wish For.</B>
문제를 너무 잘 해결하는 데에 따르는 문제도 있다. 카본과 맥오에스텐을 통합시킴으로써 애플이 나서서 클래식 맥오에스 API가 근근히 이어지리라 확인해 준 꼴이었다. 마찬가지로 유사 윈도 환경을 접붙이기하면, 또 다른 구식 API를 애플이 나서서 지원해 주어야 한다. 보존해야 할 이유가 없는 API를 말이다. 심지어 마이크로소프트도 Win32를 묻어버리고 .Net으로 개발자들을 옮기려하고 있다. (마이크로소프트 고유의 모던 API를 사용하는 마이크로소프트 애플리케이션을 재작성할 시간이 일단 있어야겠다.)
윈도 API를 지원해야 하는 경우, 치즈처럼 뚫린 보안 구멍 패치를 다 신경써야 하고, 그 많은 버그 에뮬레이션도 이해해야 한다. 안좋은 써드파티 소프트웨어를 지원하기 위한 해킹도 알아내야 한다. 인터넷 익스플로러처럼 움직이기 위해, 오페라가 온갖 노력을 다 하는 것이 실례(實例)다. 윈도 전체라면 어떨지 상상해 보시라.
올해 애플은 아이폰 출하때문에 레퍼드의 출시를 4월에서 10월로 연기시켰다. 아이폰은 애플에게 수 백만 달러의 하드웨어 수입을, 서비스 수입으로도 수 백만 달러를 안겨다주고 있다. 내년 초봄이면, 개발세계를 뒤흔들 예정이다. 역사상 그 어느 때보다도 코코아와 오브젝티브-C에 대한 관심을 불러일으키게 되기 때문이다.
윈도 API에 더 많은 수고를 투입하면 도대체 애플이 무엇을 얻을까? 하드웨어나 소프트웨어의 직접적인 수입은 없으며, 개발툴에 대한 관심도 새로이 불러일으키지 못할 것이다. 오히려 써드파티 개발자를 내몰아서 스스로를 축소시켜버릴지도 모른다.
<A href="http://www.appleforum.com/419228-post1.html" target="_new">iPhone SDK 개방과 그 의미</a>
<b>But What About PE?</B>
윈도 API를 애플이 스스로 구현하리라는 어리석은 망상은 또다시 잊혀지고말았다. 최근 윈도의 PE 파일이 맥오에스텐 레퍼드에 있다면서 또다시 이 이야기가 나오고 있어서이다. 흥분감이 땅 속에 묻혀 있던 레드박스 미신까지 다시금 살려낼 지경이었다. 마치 세상을 밝은 미래로 이끌리라는 전망까지 이끌어내면서 말이다. 바보짓에는 한계가 없다.
PE는 Portable Executable을 의미하며, 윈도 애플리케이션과 윈도 3.1, 95/98/Me, NT/2000/XP/Vista, 심지어 WinCE에 이르기까지 DLL과 바이너리 실행파일용 파일포맷과 관련이 있다. PE는 예전 유닉스 COFF 사양에 기반하지만, 현재 유닉스와 리눅스 대부분은 ELF를 사용한다. 단, 맥오에스텐은 Mach 커널때문에 Mach-O 포맷을 사용한다.
PE가 DOS (윈도 애플리케이션은 시작할 때 모두 DOS 애플리케이션을 실행시킨다)의 한 단계이기 때문에, 표준형 PE 파일은 보통 이런 메시지를 포함한다. “This program cannot be run in DOS mode.”
<b>To PE or Not to PE.</B>
“Windows PE” (이 PE는 다르다. “preinstallation environment”)는 윈도를 수리하고 배치하는 별도의 마이크로소프트 제품 이름이기도 하다. 윈도에 무엇이 들어가는지, 무엇을 어떻게 설정하는지 여전히 통제를 하고 싶은 마이크로소프트이다. 따라서 WinPE는 OEM 업체들에게만 제공되고 라이센스가 주어진다. 그 외 마이크로소프트와 계약을 맺은 기관만 받을 수 있다. 완전한 컨트롤 하에, 사용자는 수 백 달러의 별도 비용지불 없이, 비스타 Basic을 비스타 Ultimate으로 바꿀 수 있으며, 갖고 있는 컴퓨터 전부에 설치할 수도 있다. 그렇다면 마이크로소프트의 이익이 줄어들게 된다.
윈도는 새로운 윈도 시스템 설치 이미지를 관리하기 위해, 기본적인 운영체제를 작동시켜야 한다. 표준형 BIOS PC가 갖는 펌웨어의 한계때문에, 하드웨어도 윈도 설치본을 수리하기 위해서는 뭔가 다른 것을 돌려야 한다. 윈도 XP가 나오기 전, 소비자용 윈도 시스템 WinPE의 역할은 DOS가 맡았었다.
WinPE를 사용하면, 윈도 업체나 관리자는 개별 윈도 버전을 만들어서 여러 머신에 설치할 수 있다. WinPE는 또한 시스템 복구에 쓸 수도 있다. WinPE는 사실 최소한만 갖춘 윈도이며, 똑같은 NT loader와 커널을 사용하고, 똑같은 유틸리티 일부를 제공한다.
맥오에스텐은 그런식의 대량 설치와 사용자화가 훨씬 간편하다. 애플은 무료로 디스크 유틸리티 안에 디스크 이미징툴을 제공한다. 그 외에도 맥오에스텐 설치 DVD는 기본 버전의 맥오에스텐에 몇 가지 유틸리티의 형태로 부팅을 시킨다. WinPE에 비해 보다 세련되고 그래픽이 풍부하며, 비싸지도 않고, 통제도 받지 않는다.
<b>Why Apple Supports PE in Leopard.</B>
나름의 WinPE를 갖고 있긴 하지만, 애플이 PE 포맷을 지원해야 하는 다른 이유가 있다. 인텔맥이 나오기 전, 애플은 Sun이 개발한 세련된 펌웨어, OpenBoot를 사용하였다. 이 이름이 IEEE를 통과하면서 OpenFirmware로 바뀐다. 기본 Forth 환경에 기반하는 이 시스템덕에, 파워맥은 PC에 없는 여러 가지 기능용 환경으로 부팅할 수 있었다.
<ul><li> 옵션을 누르고 부팅하면, 부팅 가능한 기기를 찾아서 선택할 수 있도록 해준다.
<li> 타겟 모드로 부팅할 경우, 시스템이 파이어와이어 디스크로 뜬다. 즉, 다른 시스템이 타겟 모드로 부팅한 맥을 드라이브로 인식한다.
<li> Net Booting을 할 경우, 네트워크 공유 디스크 이미지로 부팅이 가능해진다.
<li> 다른 키조합으로 운영체제를 지나칠 수 있다. </ul>
인텔맥으로 이주하면서, 애플은 OpenFirmware를 포팅하지 않고, 인텔이 만들어 놓은 새로운 펌웨어 환경으로 이주하였다. 주된 이유는 일반 PC도 언젠가는 새 표준으로 이주할 터이기 때문에, 향후 개발과 호환성을 갖추기 위해서였다. 이것이 바로 EFI, 즉, Extensible Firmware Interface이다.
<b>EFI and Itanium.</B>
인텔은 원래 예전 x86 아키텍쳐를 교체할 예정으로 나온 64-비트 프로세서, 아이태니엄(Itanium)용으로 EFI를 만들었었다. 인텔은 절대반지 하나를 가지고 모든 경쟁사와 프로세서 아키텍쳐를 인텔의 손아귀에 거머쥘 심산이었다. 아이태니엄은 기존 PC나 다른 시스템에 비해, 완전히 새롭고 깔끔한 해결책을 의도하였다. 하지만 너무 늦게 나왔고, 계획보다 훨씬 더 복잡하지고 비쌌다.
아이태니엄은 대실패로 끝나서 서버시장 바깥으로는 나가지 못하였다. 물론 수정주의 역사가들은 아이태니엄이 원래 서버용으로 개발된 것이라는 주장도 한다. 그러나 현실적으로 아이태니엄은 1994년 당시, PowerPC의 경쟁자로 거론됐었다. 1997년 당시 IDC는 아이태니엄이 2001년까지 380억 달러 규모의 시장으로 성장하리라 추측하였다. 그러나 아이태니엄은 2001년까지도 못 나왔고, 겨우 수 천 유닛만을 판매하였다.
아이태니엄은 인텔 x86 라인에서 허덕이다가 실망스러운 펜티엄 4로 교체되는 수모를 겪었다. 하지만 비교적 최근인 2003년 3월까지도 존 드보락(John Dvorak)은 PC Magazine에서 이런 주장을 펼쳤다. "애플은 곧 아이태니엄 칩을 사용할 것이다. 아이태니엄의 다중 프로세서 디자인을 사용하여, 아이태니엄의 첫 번째 데스크톱을 만들 것이다."
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/200712050204.jpg"></center>
드보락은 애플이 2004년 말 전에 아이태니엄으로 이주하리라 예언했었다. 하지만 2003년, 애플은 G5 기반의 새 파워맥을 발표하여 모두를 놀라게 하였다. 몇 년 후, 애플은 드보락이 예언했던 듀얼-프로세서 아키텍쳐 대신 인텔을 선택한다. 게다가 사용자들이 제일 민감해하면서, 프로세서 이주로부터 제일 이득을 얻지도 못하는 포터블로 과감히 시작하였다. 데스크톱부터가 아니었다. 물론 애플은 아이태니엄 칩을 전혀 사용하지 않았다.
<A href="http://www.roughlydrafted.com/RD/RDM.Tech.Q2.07/23659F71-13AE-4865-908A-2712484708E1.html" target="_new">John Dvorak: How Wrong Can One Guy Be?</A>
<b>Microsoft’s EFI Involvement.</b>
인텔은 아이태니엄과 EFI를 마이크로소프트와 공동 개발했었다. 그래서 마이크로소프트는 아이태니엄용 "IA-64" 버전의 윈도까지 출시했었다. 그러나 마이크로소프트는 애플처럼 유니버설 바이너리와 같은 해결책을 제공하지 않았다. 이 때문에 IA-64 윈도용 소프트웨어는 아이태닝머 시스템에서만 돌아갔고, x86용 주류 윈도 애플리케이션은 아이태니엄 시스템에서 안 돌아갔다.
마이크로소프트의 기여가 또 한 가지 있다. 공개된 소프트웨어보다는 EFI on PE 기반으로 인텔을 데려온 것이다. EFI의 목표 중 하나는, 하드웨어 업체가 컴퓨터 사용 통제를 할 수 있는 마이크로소프트 팔라디움(Palladium) 방식의 시스템이었다. 애플은 단순히 EFI를 OpenFirmware(EFI가 따라하였다) 수준으로 사용하였다. 이 때문에 오늘날 EFI 기반의 인텔맥들도 예전 맥과 유사하게 돌아간다.
맥 이외에, EFI를 사용하는 다른 PC는 없으며, 윈도 XP와 PC용 비스타 또한 EFI를 지원하지 않는다. 이 때문에 10년이 넘게 맥 사용자들이 누려오던 펌웨어-관련 기능을 윈도 PC는 못 누리고 있다.
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/rd-home-7cc25766-ef64-4d85-ad37-bcc39fbd2a4f-files-leapfrog.jpg"></center>
<A href="http://www.appleforum.com/365060-post8.html" target="_new">BIOS PC를 뛰어넘은 애플 펌웨어</a>
<b>EFI on Intel Macs.</b>
맥오에스텐 10.4 타이거의 EFI 지원은 Forth보다도 PE에 기반하는 새로운 펌웨어 레이어를 지원하는 시스템 해킹이 필요했따. 이런 변화는 2006년, 인텔-맥이 초창기 PowerPC 맥과 똑같은 소프트웨어를 돌리는 것으로 보여야 했기 때문이다. 현시적으로 인텔용 타이거는 PowerPC용 타이거와 완전히 별다른 운영체제이다.
이러한 변화때문에 첫 인텔맥이 나온 이후, 최신 인텔맥의 커널소스를 애플이 일단 붙잡고 있어야 했다. 이 또한 수 많은 여론을 만들어냈다. 얘거(Tom Yager)는 애플이 오픈소스 정책을 중단했다는 교활한 글을 썼다.
<A href="http://www.appleforum.com/356829-post1.html" target="_new">커널 소스코드 폐쇄의 미신을 파헤친다</a>
2007년, 애플은 첫 번째 유니버설 운영체제로서 맥오에스텐 10.5, 레퍼드를 선보인다. PowerPC와 인텔용 설치 디스크를 별도로 만들지 않고, 레퍼드 운영체제 자체를 유니버설 바이너리화시켜서, 각 플랫폼 모두 설치와 운영이 가능해졌다.
레퍼드의 PE 지원에 대한 최근의 논란은 레퍼드의 EFI 네이티브 지원과 관련이 있다. 원래 타이거는 EFI를 지원할 필요가 없었다. 인텔맥 이후가 EFI를 지원하고 있었고, PowerPC용 타이거는 이미 나온지 1년이 넘었었다. 인텔맥 타이거의 EFI 지원은 레퍼드와 동일하게 돌아가지 않는다. 물론 타이거식으로 PowerPC용 버전이 따로 필요하지도 않다.
PE를 사용하여 EFI를 만들었기 때문에, 레퍼드는 PE 파일과 윈도용 DLL 아키텍쳐 로딩을 지원해야 했다. 공개적으로 지원하는 인터페이스도 아니기에, 애플은 이를 광고하지도 않았다. PE 자체의 특성을 볼 때, "This program cannot be run in DOS mode" 문장을 포함시킨 파일이 맥오에스텐 상에 있긴 할 것이다. 그러나 이를 두고서 애플이 드디어 방대한 윈도 API를 구현하기 시작했다거나, 파트너를 죽이기 위해 와인을 맥오에스텐에 통합시키기 시작했다고 말한다면, 이는 충분히 생각해보지도 않았음이 분명하다.
<b>Thinking Outside the Red Box.</B>
애플은 맥오에스텐 용으로 새로운 색상 박스를 개발하지 않았다. 다중 플랫폼에서 돌아가는 단일 운영체제와 현대적인 API를 만들어냈으며, 아이포드 터치에서 아이폰, 애플티비, 노트북, 데스크톱, 서버용으로 모두 동일한 운영체제를 돌려내고 있다. 새로운 아이포드 모델과 아이폰은 물론, 맥북, 내년에 어쩌면 나올지도 모를 울트라 노트북으로 대표될 애플의 성장도 기대할 만하다.
즉, 이제 죽어가는 90년대의 운영체제를 90년대의 PC를 갖고 어떻게 성공을 시키겠다는 말인가? PC 시장은 성숙한 시장이다. 이미 업체들로 가득 차있다. 더 영리하게 움직이는 것 외에, 점점 더 많은 휴대기기들이 운영체제를 필요로 할 것이다. 옛날 소프트웨어 그 이상으로 말이다.
과거로부터 배울 점은 매우 많지만, 그대로 답습하는 것은 기대만큼의 효과를 낼 때가 없다. 그 자체로 반복하는 역사라고 해서, 마이크로소프트가 가진 행운의 권력이 단순히 되풀이되진 않을 것이다. 현대적인 IBM이 아닌, 약간 개선시킨 API만으로 마이크로소프트는 기술 산업을 장악했었다. 당시만 해도 컴퓨터 업계 최대의 독점 거인은 IBM이었지만 순간 무너지고 말았다. 이번에는 마이크로소프트 차례이다.
<I>What do you think? I really like to hear from readers. Comment in the <A href="http://www.roughlydrafted.com/RD/Forum.html" target="_new">Forum</a> or <A href="http://www.roughlydrafted.com/RD/Journal/7DBAEF76-AE98-4D20-BB8E-4D82D8713D2E.html" target="_new">email me</A> with your ideas.
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and <A href="http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=214923915" target="_new">subscribe</A> to my podcast! Submit to Reddit or Slashdot, or consider making a <A href="http://www.roughlydrafted.com/RD/About.html" target="_new">small donation</a> supporting this site. Thanks!</I>
PE U: The Mac OS X Leopard Windows API Myth (http://www.roughlydrafted.com/2007/12/05/pe-u-the-mac-os-x-leopard-windows-api-myth/)
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/200712050332.jpg"></center>
<b>Daniel Eran Dilger</b>
좀처럼 사라지지 않는 아이디어가 있다. 맥오에스텐 레퍼드 윈도 API 미신의 신봉자들은, 맥오에스텐 내부에 마이크로소프트 윈도를 돌려야 할 절대적인 필요성이 꼭 있다고 보고 있다. 이 때문에 그런 힌트라도 보인다고 하면 이들은 곧 이 일이 일어나리라 장담하곤 한다. 최근 레퍼드가 PE 파일을 읽어들이고 윈도 DLL 파일을 리퀘스트한다는 주제가 떠올랐다. 타이거에서는 이런 것이 없었기에 새로운 발견이라 짐짓 결정내려버린 전문가들이 있다. 이들은 바로 선정적인 태도로 넘어간다. 애플이 비밀리에 윈도 API를 구현시키고 있으며, 그로 인하여 맥이 윈도 프로그램도 네이티브로 돌리리라는 주장이다. 그들은 틀렸다. 왜인지 알아보자.
<b>This All Happened Before.</B>
지난 해, 필자는 레드박스 미신을 2006년 애플을 둘러싼 10대 미신 중 하나로 강조하였다. 새로운 이유도 없잖지만, 이 미신과 관련된 최신 루머도 똑같은 이유에서 미신일 수 밖에 없다.
"레드박스"라는 아이디어가 있다. 맥 데스크톱 상에서 윈도용 애플리케이션을 네이티브로 돌린다는 개념이다. 문제는 이 기술을 실제로 제공하는 것이 시간여행의 문제처럼 전혀 다른 문제라는 데에 있다. 즉, 시간여행처럼 추측만 가능할 뿐이다. 물론 시간여행처럼 그 어려운 악조건에도 불구하고 상상력만은 없앨 수가 없다. 그래서 레드박스 개념은 꾸준히 나오고 있다.
로버트 크린즐리라는 필명으로 글을 쓰는 마크 스티븐스(Mark Stephens)가 지난 해, 레드박스 미신을 거론하면서, 1997년 마이크로소프트와의 상호특허 인정 계약이 있으니 별다른 수고를 들이지 않고도 할 수 있으리라 추측하였다. 두 회사가 상호 특허 포트폴로이를 두고 서로 고소하지 않기로 동의하였으며, 애플이 윈도 소스코드에 대한 접근권도 어느 정도 있잖을까라는 주장이었다. 즉, 애플이 원하는 식으로 윈도 소스코드를 라이센스해서 바로 활용할 수 있다는 의미였다. 완전히 터무니 없는 주장이다.
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/rd-q4.06-5d46aa85-a561-44c3-af5e-a61a54fae472-files-red-box.jpg"></center>
<A href="http://www.appleforum.com/378985-post8.html" target="_new">Myth 8: 레드박스 미신</a>
<b>Really, Really Hard Problems.</B>
현실적으로 마이크로소프트 코드와 개발툴, 미래 전략계획에 완전히, 무제한적으로 접근이 가능하다 하더라도, 맥 상에서 "윈도 API"를 제공하기란 쉽지 않다. 일반인들은 복잡한 소프트웨어를 제공한다는 사실이 얼마나 어려운지 잘 인식을 못한다. 생각해 보시라.
<ol><li> 마이크로소프트가 비스타를 내놓는 데에 걸린 시간만 7년이 넘어간다. 그것도 매번 완전히 재시작해야 했다. "똑같은 윈도 API"에 몇 가지 변화와 추가만 했음에도 불구하고 비스타는 여전히 하드웨어 호환문제와 퍼포먼스 문제, 수 많은 보안과 안정성 문제를 안고 있으며, 이 문제를 해결하는 데에도 수 년이 걸릴 것이다.
<li> 애플 또한 클래식 맥 API를 카본이라는 형태로, 맥오에스텐 환경에 이식하는 데에만 수 년이 걸렸다. 완전히 제공하는 데에는 5년이 걸렸으며, 2002년 맥오에스텐 10.2 재규어가 나온 이후 지난 5년간 매번 개선을 거듭해왔다. 카본을 NeXTSTEP, 즉, 맥오에스텐으로 통합시키는 일은 두 체제 모두에게 상당한 변화를 요구하였다.
애플은 두 환경 모두를 온전히 갖고 있으며, 친숙한 엔지니어들도 많이 고용하고 있다. 그럼에도 불구하고 양측을 하나의 패키지로 심어 놓는 데에 여전히 문제점이 남아 있었다. 윈도 환경 이식은 훨씬 더 복잡한 문제다. 애플이 자신에 맞게 윈도를 변경시킬 수 없기 때문이다. 마찬가지 이유로, 윈도에 대한 마이크로소프트의 정의도 독립적인 방향으로 움직이게 되어 있다.
<li> 오픈소스 커뮤니티가 몇 가지 독립 프로젝트로 윈도 API에 대한 대안을 작업해왔다. 윈도 NT의 클론인 ReactOS 프로젝트와, 유닉스-류 운영체제에서 네이티브 API로 윈도 API를 매핑하는 프로젝트, 와인(Wine)이 있다. 와인은 14년동안 개선을 거듭해왔지만, 여전히 실험적인 단계다.
위 프로젝트 모두, 매우 뛰어난 엔지니어들이 상당히 많이 투입된 프로젝트이다. 제품을 더 낫게, 더 빠르게 만들 능력이 있었더라면 벌써 그렇게 나왔을 것이다. 위 프로젝트 모두 각 그룹이 제공할 수 있는 최선의 상태이다. </ol>
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/wp-content-uploads-2007-10-rd-rdm.tech.q3.07-9dd78403-fe1b-4da1-a757-84e24cb642a3-files-iphone-2.jpg"></center>
<A href="http://www.appleforum.com/401586-post1.html" target="_new">iPhone의 OS X과 Leopard, 그리고 Vista</a>
<A href="http://www.appleforum.com/383645-post1.html" target="_new">1995년은 2007년에 되풀이될 수 없다</A>
<b>Solvable Problems.</B>
맥 상에서 윈도 애플리케이션을 돌린다는 아이디어가 해결할 수 없는 문제까지는 아니다. PowerPC 맥도 에뮬레이션으로 윈도 애플리케이션을 돌릴 수 있었다. 가상 PC 환경을 만들어주는 소프트웨어 레이어 상에 윈도를 설치하여 돌리는 식이다. 인텔 맥에서는 부트캠프를 통해 바로 네이티브 윈도를 돌릴 수 있으며, Parallels Desktop이나 Fusion과 같은 환경을 사용하여 돌릴 수 있다.
하지만 이러한 해결책 모두 윈도 정본을 필요로 한다. 즉, 마이크로소프트는 PC 업체들에게 OEM으로 윈도를 파는 것보다 10 배 이상의 값으로 맥 사용자들에게 윈도를 행복하게 판매할 수 있다. Wine이나 레드박스 개념은 윈도 자체를 교체하자는 식이다. 따라서 윈도용 애플리케이션도 윈도 설치를 하지 않고서도 돌릴 수 있는 개념이다.
그런 문제가 해결 불가능까지는 아니다. TransGaming Technologies에서 판매하는 와인이 있는데, 이 와인은 특정 윈도 프로그램을 윈도 없이 실행 가능하게 해 준다. 이 제품은 리눅스 상에서 윈도용 게임(혹은 애플 아이튠스나 마이크로소프트 오피스)을 돌리도록 해 주며, EA Games도 올해 인텔맥용 게임을 선보일 때 이 제품을 활용했었다. Parallels도 와인 일부를 사용하여 DirectX 지원을 다룬다.
<b>Unsolvable Problems.</B>
그러나 범용 목적의 시스템으로서, 윈도 없는 윈도 애플리케이션은 훨씬 더 어렵다. 맥 데스크톱과의 통합은 훨씬 더 복잡한 문제다. 어느 시점에서라도 마이크로소프트는, 손쉽게 호환성을 깨는 윈도 API를 수정할 수 있으며, 유사 윈도 환경을 거부하는 코드를 사용해 오피스를 내놓을 수도 있다.
이미 90년대 초 IBM이 이 점을 발견한 바 있다. 당시 마이크로소프트는 OS/2의 경쟁압력을 모두 없애려 하였다. OS/2는 마이크로소프트와의 협력에 따라 윈도용 애플리케이션을 돌릴 예정이었다. 윈도 API 사용허가를 받은 IBM의 OS/2한테 마이크로소프트가 저지른 일을 기억하신다면, 경쟁자에게는 마이크로소프트가 어떻게 대처할지 상상해 보시라! 보다 최근 사례를 들어 보자. 마이크로소프트는 코렐의 와인 프로젝트 지원을 중단시키기 위해, 코렐에 투자를 거행하였다. 또한 윈도 업데이트를 돌릴 때, 와인을 특별히 확인하도록 하였다.
애플의 자원은 제한적이다. 설사 15년에 걸친 와인도 할 수 없는 기술을 애플이 갖고 있다 하더라도, 마이크로소프트가 Win32를 죽이고 새로이 .Net과 관계있는 윈도 API를 새로이 내놓는다는 점을 애플이 깡그리 무시한다 하더라도, 그런 대안적인 솔루션을 애플이 직접 하는 편보다, 더 이윤이 많이 날 일이 많이 있다.
<b>Imagine the Outcry.</B>
이미 Paralles나 Fusion, 그 외 상용 제품들이 맥오에스텐에서 윈도 호환 환경을 열심히 제공해 놓았다. 이런 상황에서 갑자기 애플이 나서면 어떤 꼴이 되어버릴까?
애플이 Sherlock 3.0, 그리고 Dashboard를 선보였을 때, 전문가들은 애플이 써드파티 개발자들을 저버렸다면서 주먹을 휘두르고 병을 깨뜨리며 옷을 찢는 등, 난리도 아니었다. 이들이 흐르는 악어의 눈물은 거의 노아의 대홍수급이다. 그러나 Karelia Watson과 Konfabulator의 사례를 보면, 애플은 고유의 소프트웨어로 방향을 분명히 하여 확장을 했을 뿐이었다. 오로지 Paralles와 Fusion 시장을 파괴시키기 위, 이미 해결책이 있는 시장에서 애플이 개발에 나서야 할 필요가 있을까? 애플이 레드박스를 만들 수 있다는 것 이상으로 더 웃기는 일이 아닐 수 없다.
<A href="http://www.appleinsider.com/articles/07/10/19/road_to_mac_os_x_leopard_dashboard_spotlight_and_t he_desktop.html&page=2" target="_new">AppleInsider | Road to Mac OS X Leopard: Dashboard, Spotlight and the Desktop: Watson</a>
<A href="http://www.appleinsider.com/articles/07/10/19/road_to_mac_os_x_leopard_dashboard_spotlight_and_t he_desktop.html&page=3" target="_new">AppleInsider | Road to Mac OS X Leopard: Dashboard, Spotlight and the Desktop: Konfabulator</a>
<b>Be Careful What You Wish For.</B>
문제를 너무 잘 해결하는 데에 따르는 문제도 있다. 카본과 맥오에스텐을 통합시킴으로써 애플이 나서서 클래식 맥오에스 API가 근근히 이어지리라 확인해 준 꼴이었다. 마찬가지로 유사 윈도 환경을 접붙이기하면, 또 다른 구식 API를 애플이 나서서 지원해 주어야 한다. 보존해야 할 이유가 없는 API를 말이다. 심지어 마이크로소프트도 Win32를 묻어버리고 .Net으로 개발자들을 옮기려하고 있다. (마이크로소프트 고유의 모던 API를 사용하는 마이크로소프트 애플리케이션을 재작성할 시간이 일단 있어야겠다.)
윈도 API를 지원해야 하는 경우, 치즈처럼 뚫린 보안 구멍 패치를 다 신경써야 하고, 그 많은 버그 에뮬레이션도 이해해야 한다. 안좋은 써드파티 소프트웨어를 지원하기 위한 해킹도 알아내야 한다. 인터넷 익스플로러처럼 움직이기 위해, 오페라가 온갖 노력을 다 하는 것이 실례(實例)다. 윈도 전체라면 어떨지 상상해 보시라.
올해 애플은 아이폰 출하때문에 레퍼드의 출시를 4월에서 10월로 연기시켰다. 아이폰은 애플에게 수 백만 달러의 하드웨어 수입을, 서비스 수입으로도 수 백만 달러를 안겨다주고 있다. 내년 초봄이면, 개발세계를 뒤흔들 예정이다. 역사상 그 어느 때보다도 코코아와 오브젝티브-C에 대한 관심을 불러일으키게 되기 때문이다.
윈도 API에 더 많은 수고를 투입하면 도대체 애플이 무엇을 얻을까? 하드웨어나 소프트웨어의 직접적인 수입은 없으며, 개발툴에 대한 관심도 새로이 불러일으키지 못할 것이다. 오히려 써드파티 개발자를 내몰아서 스스로를 축소시켜버릴지도 모른다.
<A href="http://www.appleforum.com/419228-post1.html" target="_new">iPhone SDK 개방과 그 의미</a>
<b>But What About PE?</B>
윈도 API를 애플이 스스로 구현하리라는 어리석은 망상은 또다시 잊혀지고말았다. 최근 윈도의 PE 파일이 맥오에스텐 레퍼드에 있다면서 또다시 이 이야기가 나오고 있어서이다. 흥분감이 땅 속에 묻혀 있던 레드박스 미신까지 다시금 살려낼 지경이었다. 마치 세상을 밝은 미래로 이끌리라는 전망까지 이끌어내면서 말이다. 바보짓에는 한계가 없다.
PE는 Portable Executable을 의미하며, 윈도 애플리케이션과 윈도 3.1, 95/98/Me, NT/2000/XP/Vista, 심지어 WinCE에 이르기까지 DLL과 바이너리 실행파일용 파일포맷과 관련이 있다. PE는 예전 유닉스 COFF 사양에 기반하지만, 현재 유닉스와 리눅스 대부분은 ELF를 사용한다. 단, 맥오에스텐은 Mach 커널때문에 Mach-O 포맷을 사용한다.
PE가 DOS (윈도 애플리케이션은 시작할 때 모두 DOS 애플리케이션을 실행시킨다)의 한 단계이기 때문에, 표준형 PE 파일은 보통 이런 메시지를 포함한다. “This program cannot be run in DOS mode.”
<b>To PE or Not to PE.</B>
“Windows PE” (이 PE는 다르다. “preinstallation environment”)는 윈도를 수리하고 배치하는 별도의 마이크로소프트 제품 이름이기도 하다. 윈도에 무엇이 들어가는지, 무엇을 어떻게 설정하는지 여전히 통제를 하고 싶은 마이크로소프트이다. 따라서 WinPE는 OEM 업체들에게만 제공되고 라이센스가 주어진다. 그 외 마이크로소프트와 계약을 맺은 기관만 받을 수 있다. 완전한 컨트롤 하에, 사용자는 수 백 달러의 별도 비용지불 없이, 비스타 Basic을 비스타 Ultimate으로 바꿀 수 있으며, 갖고 있는 컴퓨터 전부에 설치할 수도 있다. 그렇다면 마이크로소프트의 이익이 줄어들게 된다.
윈도는 새로운 윈도 시스템 설치 이미지를 관리하기 위해, 기본적인 운영체제를 작동시켜야 한다. 표준형 BIOS PC가 갖는 펌웨어의 한계때문에, 하드웨어도 윈도 설치본을 수리하기 위해서는 뭔가 다른 것을 돌려야 한다. 윈도 XP가 나오기 전, 소비자용 윈도 시스템 WinPE의 역할은 DOS가 맡았었다.
WinPE를 사용하면, 윈도 업체나 관리자는 개별 윈도 버전을 만들어서 여러 머신에 설치할 수 있다. WinPE는 또한 시스템 복구에 쓸 수도 있다. WinPE는 사실 최소한만 갖춘 윈도이며, 똑같은 NT loader와 커널을 사용하고, 똑같은 유틸리티 일부를 제공한다.
맥오에스텐은 그런식의 대량 설치와 사용자화가 훨씬 간편하다. 애플은 무료로 디스크 유틸리티 안에 디스크 이미징툴을 제공한다. 그 외에도 맥오에스텐 설치 DVD는 기본 버전의 맥오에스텐에 몇 가지 유틸리티의 형태로 부팅을 시킨다. WinPE에 비해 보다 세련되고 그래픽이 풍부하며, 비싸지도 않고, 통제도 받지 않는다.
<b>Why Apple Supports PE in Leopard.</B>
나름의 WinPE를 갖고 있긴 하지만, 애플이 PE 포맷을 지원해야 하는 다른 이유가 있다. 인텔맥이 나오기 전, 애플은 Sun이 개발한 세련된 펌웨어, OpenBoot를 사용하였다. 이 이름이 IEEE를 통과하면서 OpenFirmware로 바뀐다. 기본 Forth 환경에 기반하는 이 시스템덕에, 파워맥은 PC에 없는 여러 가지 기능용 환경으로 부팅할 수 있었다.
<ul><li> 옵션을 누르고 부팅하면, 부팅 가능한 기기를 찾아서 선택할 수 있도록 해준다.
<li> 타겟 모드로 부팅할 경우, 시스템이 파이어와이어 디스크로 뜬다. 즉, 다른 시스템이 타겟 모드로 부팅한 맥을 드라이브로 인식한다.
<li> Net Booting을 할 경우, 네트워크 공유 디스크 이미지로 부팅이 가능해진다.
<li> 다른 키조합으로 운영체제를 지나칠 수 있다. </ul>
인텔맥으로 이주하면서, 애플은 OpenFirmware를 포팅하지 않고, 인텔이 만들어 놓은 새로운 펌웨어 환경으로 이주하였다. 주된 이유는 일반 PC도 언젠가는 새 표준으로 이주할 터이기 때문에, 향후 개발과 호환성을 갖추기 위해서였다. 이것이 바로 EFI, 즉, Extensible Firmware Interface이다.
<b>EFI and Itanium.</B>
인텔은 원래 예전 x86 아키텍쳐를 교체할 예정으로 나온 64-비트 프로세서, 아이태니엄(Itanium)용으로 EFI를 만들었었다. 인텔은 절대반지 하나를 가지고 모든 경쟁사와 프로세서 아키텍쳐를 인텔의 손아귀에 거머쥘 심산이었다. 아이태니엄은 기존 PC나 다른 시스템에 비해, 완전히 새롭고 깔끔한 해결책을 의도하였다. 하지만 너무 늦게 나왔고, 계획보다 훨씬 더 복잡하지고 비쌌다.
아이태니엄은 대실패로 끝나서 서버시장 바깥으로는 나가지 못하였다. 물론 수정주의 역사가들은 아이태니엄이 원래 서버용으로 개발된 것이라는 주장도 한다. 그러나 현실적으로 아이태니엄은 1994년 당시, PowerPC의 경쟁자로 거론됐었다. 1997년 당시 IDC는 아이태니엄이 2001년까지 380억 달러 규모의 시장으로 성장하리라 추측하였다. 그러나 아이태니엄은 2001년까지도 못 나왔고, 겨우 수 천 유닛만을 판매하였다.
아이태니엄은 인텔 x86 라인에서 허덕이다가 실망스러운 펜티엄 4로 교체되는 수모를 겪었다. 하지만 비교적 최근인 2003년 3월까지도 존 드보락(John Dvorak)은 PC Magazine에서 이런 주장을 펼쳤다. "애플은 곧 아이태니엄 칩을 사용할 것이다. 아이태니엄의 다중 프로세서 디자인을 사용하여, 아이태니엄의 첫 번째 데스크톱을 만들 것이다."
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/200712050204.jpg"></center>
드보락은 애플이 2004년 말 전에 아이태니엄으로 이주하리라 예언했었다. 하지만 2003년, 애플은 G5 기반의 새 파워맥을 발표하여 모두를 놀라게 하였다. 몇 년 후, 애플은 드보락이 예언했던 듀얼-프로세서 아키텍쳐 대신 인텔을 선택한다. 게다가 사용자들이 제일 민감해하면서, 프로세서 이주로부터 제일 이득을 얻지도 못하는 포터블로 과감히 시작하였다. 데스크톱부터가 아니었다. 물론 애플은 아이태니엄 칩을 전혀 사용하지 않았다.
<A href="http://www.roughlydrafted.com/RD/RDM.Tech.Q2.07/23659F71-13AE-4865-908A-2712484708E1.html" target="_new">John Dvorak: How Wrong Can One Guy Be?</A>
<b>Microsoft’s EFI Involvement.</b>
인텔은 아이태니엄과 EFI를 마이크로소프트와 공동 개발했었다. 그래서 마이크로소프트는 아이태니엄용 "IA-64" 버전의 윈도까지 출시했었다. 그러나 마이크로소프트는 애플처럼 유니버설 바이너리와 같은 해결책을 제공하지 않았다. 이 때문에 IA-64 윈도용 소프트웨어는 아이태닝머 시스템에서만 돌아갔고, x86용 주류 윈도 애플리케이션은 아이태니엄 시스템에서 안 돌아갔다.
마이크로소프트의 기여가 또 한 가지 있다. 공개된 소프트웨어보다는 EFI on PE 기반으로 인텔을 데려온 것이다. EFI의 목표 중 하나는, 하드웨어 업체가 컴퓨터 사용 통제를 할 수 있는 마이크로소프트 팔라디움(Palladium) 방식의 시스템이었다. 애플은 단순히 EFI를 OpenFirmware(EFI가 따라하였다) 수준으로 사용하였다. 이 때문에 오늘날 EFI 기반의 인텔맥들도 예전 맥과 유사하게 돌아간다.
맥 이외에, EFI를 사용하는 다른 PC는 없으며, 윈도 XP와 PC용 비스타 또한 EFI를 지원하지 않는다. 이 때문에 10년이 넘게 맥 사용자들이 누려오던 펌웨어-관련 기능을 윈도 PC는 못 누리고 있다.
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/rd-home-7cc25766-ef64-4d85-ad37-bcc39fbd2a4f-files-leapfrog.jpg"></center>
<A href="http://www.appleforum.com/365060-post8.html" target="_new">BIOS PC를 뛰어넘은 애플 펌웨어</a>
<b>EFI on Intel Macs.</b>
맥오에스텐 10.4 타이거의 EFI 지원은 Forth보다도 PE에 기반하는 새로운 펌웨어 레이어를 지원하는 시스템 해킹이 필요했따. 이런 변화는 2006년, 인텔-맥이 초창기 PowerPC 맥과 똑같은 소프트웨어를 돌리는 것으로 보여야 했기 때문이다. 현시적으로 인텔용 타이거는 PowerPC용 타이거와 완전히 별다른 운영체제이다.
이러한 변화때문에 첫 인텔맥이 나온 이후, 최신 인텔맥의 커널소스를 애플이 일단 붙잡고 있어야 했다. 이 또한 수 많은 여론을 만들어냈다. 얘거(Tom Yager)는 애플이 오픈소스 정책을 중단했다는 교활한 글을 썼다.
<A href="http://www.appleforum.com/356829-post1.html" target="_new">커널 소스코드 폐쇄의 미신을 파헤친다</a>
2007년, 애플은 첫 번째 유니버설 운영체제로서 맥오에스텐 10.5, 레퍼드를 선보인다. PowerPC와 인텔용 설치 디스크를 별도로 만들지 않고, 레퍼드 운영체제 자체를 유니버설 바이너리화시켜서, 각 플랫폼 모두 설치와 운영이 가능해졌다.
레퍼드의 PE 지원에 대한 최근의 논란은 레퍼드의 EFI 네이티브 지원과 관련이 있다. 원래 타이거는 EFI를 지원할 필요가 없었다. 인텔맥 이후가 EFI를 지원하고 있었고, PowerPC용 타이거는 이미 나온지 1년이 넘었었다. 인텔맥 타이거의 EFI 지원은 레퍼드와 동일하게 돌아가지 않는다. 물론 타이거식으로 PowerPC용 버전이 따로 필요하지도 않다.
PE를 사용하여 EFI를 만들었기 때문에, 레퍼드는 PE 파일과 윈도용 DLL 아키텍쳐 로딩을 지원해야 했다. 공개적으로 지원하는 인터페이스도 아니기에, 애플은 이를 광고하지도 않았다. PE 자체의 특성을 볼 때, "This program cannot be run in DOS mode" 문장을 포함시킨 파일이 맥오에스텐 상에 있긴 할 것이다. 그러나 이를 두고서 애플이 드디어 방대한 윈도 API를 구현하기 시작했다거나, 파트너를 죽이기 위해 와인을 맥오에스텐에 통합시키기 시작했다고 말한다면, 이는 충분히 생각해보지도 않았음이 분명하다.
<b>Thinking Outside the Red Box.</B>
애플은 맥오에스텐 용으로 새로운 색상 박스를 개발하지 않았다. 다중 플랫폼에서 돌아가는 단일 운영체제와 현대적인 API를 만들어냈으며, 아이포드 터치에서 아이폰, 애플티비, 노트북, 데스크톱, 서버용으로 모두 동일한 운영체제를 돌려내고 있다. 새로운 아이포드 모델과 아이폰은 물론, 맥북, 내년에 어쩌면 나올지도 모를 울트라 노트북으로 대표될 애플의 성장도 기대할 만하다.
즉, 이제 죽어가는 90년대의 운영체제를 90년대의 PC를 갖고 어떻게 성공을 시키겠다는 말인가? PC 시장은 성숙한 시장이다. 이미 업체들로 가득 차있다. 더 영리하게 움직이는 것 외에, 점점 더 많은 휴대기기들이 운영체제를 필요로 할 것이다. 옛날 소프트웨어 그 이상으로 말이다.
과거로부터 배울 점은 매우 많지만, 그대로 답습하는 것은 기대만큼의 효과를 낼 때가 없다. 그 자체로 반복하는 역사라고 해서, 마이크로소프트가 가진 행운의 권력이 단순히 되풀이되진 않을 것이다. 현대적인 IBM이 아닌, 약간 개선시킨 API만으로 마이크로소프트는 기술 산업을 장악했었다. 당시만 해도 컴퓨터 업계 최대의 독점 거인은 IBM이었지만 순간 무너지고 말았다. 이번에는 마이크로소프트 차례이다.
<I>What do you think? I really like to hear from readers. Comment in the <A href="http://www.roughlydrafted.com/RD/Forum.html" target="_new">Forum</a> or <A href="http://www.roughlydrafted.com/RD/Journal/7DBAEF76-AE98-4D20-BB8E-4D82D8713D2E.html" target="_new">email me</A> with your ideas.
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and <A href="http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=214923915" target="_new">subscribe</A> to my podcast! Submit to Reddit or Slashdot, or consider making a <A href="http://www.roughlydrafted.com/RD/About.html" target="_new">small donation</a> supporting this site. Thanks!</I>
PE U: The Mac OS X Leopard Windows API Myth (http://www.roughlydrafted.com/2007/12/05/pe-u-the-mac-os-x-leopard-windows-api-myth/)