casaubon
2007/12/18, 12:23 AM
<font color=red><h1><B>Advancing Software Reuse of Linux, Windows Code on the Mac</B></font></h1>December 17th, 2007 | Markets, Software, Tech, the Media
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/200712161906.jpg"></centeR>
<B>Daniel Eran Dilger</B>
애플은 유닉스/리눅스용 소프트웨어의 코드를 재사용하여 성공적인 전략을 펼치고 있다. 하지만 그뿐만이 아니다. 윈도와 묶여있는 기존의 코드가지고도 새로운 노력을 하고 있다. 무엇이 포함되어있는지 알아보자.
<b>The Open and Shut Case of Mac OS X.</B>
지난 10년간 애플은 클래식 맥오에스를 새 플랫폼으로 재탄생시켰다. 이 새 플랫폼은 다른 유닉스-류 운영체제와 공통점을 갖고 있되, 맥 소프트웨어용의 특화된 소프트웨어 인터페이스를 제공하였다. 그 결과 맥오에스텐은 다음의 세 가지 클래스를 지원하게 되었다.
<ul><li> POSIX 코드나 100% 자바와 같은 완전히 개방되거나 상호운용 가능한 소프트웨어.
<li> 애플 독점적인 Cocoa와 Carbon 라이브러리를 이용해 개발한, 완전히 고유의 소프트웨어
<li> 둘의 잡종. 공개 코드에 세련된 맥 인터페이스를 입힌 소프트웨어</ul>
이제 점차 사소한 문제가 되어가고 있는데, 유용한 코드 전부가 오픈소스인 것만은 아니다. 윈도용으로는 여전히 거대한 양의 폐쇄형 코드가 있다. 여기에는 특정 하드웨어 기기용 드라이버나 유틸리티, 혹은 업체의 공개적인 지원을 받지 않는 툴이 속한다.
현재 맥 호환이 아니거나, 오픈소스화 되어있지 않은 소프트웨어는 보통 윈도로의 부팅을 요구하거나, Parallels Desktop과 같은 환경을 열어야 돌릴 수 있다. 상당한 단점이 아닐 수 없겠다.
<b>Red Box Rumblings.</B>
맥오에스텐 10.5 레퍼드가 윈도 PE 실행 포맷을 새로이, 그리고 수수께끼처럼 지원한다고 해서 일어난 논란이 있다. 필자는 이 지원이 인텔 EFI 펌웨어 지원용이지, 레드박스 지원용 증거가 아니라 말한 바 있다. 레드박스는 윈도 애플리케이션을 맥오에스텐 상에서 직접 돌리는 개념이다.
맥오에스텐을 새로운 윈도의 별종으로 만들어버리자는 개념은 윈도 열광론자들 사이에서 유명하다. 이들은 전세계의 모든 문제가 "충분히 마이크로소프트이지 않아서" 일어난다 여기고 있다. 이런 생각은 너무나 넓게 퍼진 나머지, 맥-중심의 언론마저 이따금씩 드보락-스타일의 재생산을 하고 있다. 음모론의 낚시줄을 드리우면서, "내가 틀리면 고쳐주시라. 내가 누구신진 알지."라 말한다.
동시에 다른 소프트웨어를 돌리는 문제는 리눅스에서도 존재한다. 세계 최고의 코드를 많이 접근할 수 있는 리눅스 사용자들은 맥 사용자들처럼, 가끔씩 윈도용으로 만들어진 기기나 소프트웨어를 사용할 때가 있다. 맥 하드웨어 플랫폼의 성장덕분에 맥 사용자들에 있어서 그런 문제는 점차 줄어들고 있다. 하지만 그런 문제는 여전히 존재한다.
한 가지 솔루션으느 WINE이다. WINE은 간단하지도 않고, 모든 프로그램의 해결책도 아니다. 하지만 숙련성 있고 별 기대감이 없는(tempered expectation) 사용자의 경우, 특정 애플리케이션의 사용에는 유용할 수 있다. 맥 사용자들은 보다 소비자-지향적이라서, WINE의 현재 상태에 대해 별로 만족스러워하지 않는다. 별 기대감이 없는 맥 사용자란, 없다고 말할 수 있어서이다.
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/wp-content-uploads-2007-12-200712050332.jpg"></center>
<A href="http://www.appleforum.com/421346-post13.html" target="_new">PE, 레퍼드가 윈도 API를 운영한다는 환상</a>
<b>Windows DLL Sharing?</b>
"PE, 레퍼드가 윈도 API를 운영한다는 환상" 기사에 대한 반응 중, 애플이 어쩌면 폐쇄형 윈도 코드를 적절히 사용하여, 맥오에스텐에서 유닉스/POSIX 라이브러리를 사용한 식으로 윈도 코드를 사용할 수 있으리라고 주장한 개발자들이 있었다.
윈도에서 코드는 보통 DLL이라 불리는 라이브러리로 제공된다. DLL이 기능을 제공하여, 윈도 유틸리티와 드라이버의 네이티브 맥 버전을 만드는 데에 활용할 수 있다. 이러면 소프트웨어의 맥 포팅을 제공할 필요가 있는 써드파티의 노력을 단순화시킬 수 있다. 직접적인 지원이 없이도 써드파티가 몇 가지 툴을 포팅시켜줄 수도 있다.
만약 그런 경우가 있다면, 맥 소프트웨어 라이브러리를 늘리는 동시에, 윈도에서만 작업하는 하드웨어를 사용해야 할 때 추가적인 선택을 줄 수 있다. 즉, 레드박스를 둘러싼 거의 불가능한 장벽을 우회할 수 있다는 얘기다.
<b>Solving the Red Box Issues.</B>
DLL 안에서 윈도 코드를 실행시킬 때, 완전한 에뮬레이션을 필요로하진 않는다. 다루기 어려운 "윈도 API"가 모두 있어야 하진 않다. 윈도 API는 언제나 변화하면서, 마이크로소프트의 방향에 따라 바뀔 수 있다.
그렇다고 레드박스만큼의 자원 소모적인 개발을 해야하는 것도 아니다. 무엇이든 돌려야 한다는 비합리적인 요구사항을 맞춰주어야 할 필요가 없기 때문이다. 레드박스는 얼마나 완벽하건 간에, 아무도 만족시켜줄 수 없을 개념이다.
개발자들이 윈도 코드 재사용을 한다고 해서 기존의 윈도 환경 소프트웨어 사업이 위협에 처해지는 것도 아니다. Fusion이나 Parallels Desktop과 같은 제품 개발사들에게 레드박스가 갑자기 드리우게 될 쇠퇴에 분노하게 될 일도 없다. "OS/2 효과"를 막을 수도 있는 일이다. 가상적인 레드박스가 있다면, 윈도 개발자들이 그냥 맥용으로 윈도용 애플리케이션을 제공하지, 일부러 맥 기능의 장점을 누리게 위해 포팅을 시키지는 않을 것이다.
핵심 윈도 코드의 휴대성을 살리면, 개발자들은 유사하고 친숙한 맥 인터페이스를 만들어서 맥 기능을 누리면서 포팅을 할 수 있다. 최종 사용자에게는 별 다를 일이 없다. 맥 애플리케이션은 맥 애플리케이션이기 때문이다. 핵심 코드가 오픈소스 라이브러리이건, 맥 루틴이건, 윈도 DLL이건 상관 없다.
<b>In Cider the Apple.</B>
마이크로소프트와 어도비와 같은 써드파티 개발사 입장에서는, 이런 유사한 코드 공유가 일반적이었다. 이들은 오피스와 Creative Suite의 제작에 있어, 양 플랫폼용 네이티브 인터페이스로 싸인 엔진을 사용해, 각 플랫폼용 프로그램을 만든다.
사실 더 대규모의 새로운 개발은 비디오 게임 분야에서 이미 일어나고 있다. TransGaming의 Cider 라이브러리는 윈도 게임을 맥용으로 포팅시켜줄 때, 최소한의 코드변환만 하도록 돕는다. 원래는 네이티브로 개발하겠다 했던 게임도 지름길을 통해 간다고는 하지만, 결코 맥용으로 나타나지 않는다는 비판도 있다. 필자는 좀 다른 관점을 갖고 있으며 여기에 대해서는 다음 기사에서 밝히겠다.
하지만 우선, 윈도 코드를 맥 애플리케이션으로 통합시키는 것에는 어떤 측면이 있을까? 윈도 실행 포맷을 새로이 지원한다는 레퍼드의 새로운 지원에서 어떤 의미가 있을까? 오픈소스 개발과 협력적이지만 경쟁적이기도 한 애플의 위치를 보라. 애플은 대부분의 사람들 생각 이상으로 오픈소스에 더 많은 기여를 하게 될 것이다. 다음 기사에서 밝힌다.
<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>
Advancing Software Reuse of Linux, Windows Code on the Mac (http://www.roughlydrafted.com/2007/12/17/advancing-software-reuse-of-linux-windows-code-on-the-mac/)
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/200712161906.jpg"></centeR>
<B>Daniel Eran Dilger</B>
애플은 유닉스/리눅스용 소프트웨어의 코드를 재사용하여 성공적인 전략을 펼치고 있다. 하지만 그뿐만이 아니다. 윈도와 묶여있는 기존의 코드가지고도 새로운 노력을 하고 있다. 무엇이 포함되어있는지 알아보자.
<b>The Open and Shut Case of Mac OS X.</B>
지난 10년간 애플은 클래식 맥오에스를 새 플랫폼으로 재탄생시켰다. 이 새 플랫폼은 다른 유닉스-류 운영체제와 공통점을 갖고 있되, 맥 소프트웨어용의 특화된 소프트웨어 인터페이스를 제공하였다. 그 결과 맥오에스텐은 다음의 세 가지 클래스를 지원하게 되었다.
<ul><li> POSIX 코드나 100% 자바와 같은 완전히 개방되거나 상호운용 가능한 소프트웨어.
<li> 애플 독점적인 Cocoa와 Carbon 라이브러리를 이용해 개발한, 완전히 고유의 소프트웨어
<li> 둘의 잡종. 공개 코드에 세련된 맥 인터페이스를 입힌 소프트웨어</ul>
이제 점차 사소한 문제가 되어가고 있는데, 유용한 코드 전부가 오픈소스인 것만은 아니다. 윈도용으로는 여전히 거대한 양의 폐쇄형 코드가 있다. 여기에는 특정 하드웨어 기기용 드라이버나 유틸리티, 혹은 업체의 공개적인 지원을 받지 않는 툴이 속한다.
현재 맥 호환이 아니거나, 오픈소스화 되어있지 않은 소프트웨어는 보통 윈도로의 부팅을 요구하거나, Parallels Desktop과 같은 환경을 열어야 돌릴 수 있다. 상당한 단점이 아닐 수 없겠다.
<b>Red Box Rumblings.</B>
맥오에스텐 10.5 레퍼드가 윈도 PE 실행 포맷을 새로이, 그리고 수수께끼처럼 지원한다고 해서 일어난 논란이 있다. 필자는 이 지원이 인텔 EFI 펌웨어 지원용이지, 레드박스 지원용 증거가 아니라 말한 바 있다. 레드박스는 윈도 애플리케이션을 맥오에스텐 상에서 직접 돌리는 개념이다.
맥오에스텐을 새로운 윈도의 별종으로 만들어버리자는 개념은 윈도 열광론자들 사이에서 유명하다. 이들은 전세계의 모든 문제가 "충분히 마이크로소프트이지 않아서" 일어난다 여기고 있다. 이런 생각은 너무나 넓게 퍼진 나머지, 맥-중심의 언론마저 이따금씩 드보락-스타일의 재생산을 하고 있다. 음모론의 낚시줄을 드리우면서, "내가 틀리면 고쳐주시라. 내가 누구신진 알지."라 말한다.
동시에 다른 소프트웨어를 돌리는 문제는 리눅스에서도 존재한다. 세계 최고의 코드를 많이 접근할 수 있는 리눅스 사용자들은 맥 사용자들처럼, 가끔씩 윈도용으로 만들어진 기기나 소프트웨어를 사용할 때가 있다. 맥 하드웨어 플랫폼의 성장덕분에 맥 사용자들에 있어서 그런 문제는 점차 줄어들고 있다. 하지만 그런 문제는 여전히 존재한다.
한 가지 솔루션으느 WINE이다. WINE은 간단하지도 않고, 모든 프로그램의 해결책도 아니다. 하지만 숙련성 있고 별 기대감이 없는(tempered expectation) 사용자의 경우, 특정 애플리케이션의 사용에는 유용할 수 있다. 맥 사용자들은 보다 소비자-지향적이라서, WINE의 현재 상태에 대해 별로 만족스러워하지 않는다. 별 기대감이 없는 맥 사용자란, 없다고 말할 수 있어서이다.
<center><img src="http://www.roughlydrafted.com/wp-content/uploads/2007/12/wp-content-uploads-2007-12-200712050332.jpg"></center>
<A href="http://www.appleforum.com/421346-post13.html" target="_new">PE, 레퍼드가 윈도 API를 운영한다는 환상</a>
<b>Windows DLL Sharing?</b>
"PE, 레퍼드가 윈도 API를 운영한다는 환상" 기사에 대한 반응 중, 애플이 어쩌면 폐쇄형 윈도 코드를 적절히 사용하여, 맥오에스텐에서 유닉스/POSIX 라이브러리를 사용한 식으로 윈도 코드를 사용할 수 있으리라고 주장한 개발자들이 있었다.
윈도에서 코드는 보통 DLL이라 불리는 라이브러리로 제공된다. DLL이 기능을 제공하여, 윈도 유틸리티와 드라이버의 네이티브 맥 버전을 만드는 데에 활용할 수 있다. 이러면 소프트웨어의 맥 포팅을 제공할 필요가 있는 써드파티의 노력을 단순화시킬 수 있다. 직접적인 지원이 없이도 써드파티가 몇 가지 툴을 포팅시켜줄 수도 있다.
만약 그런 경우가 있다면, 맥 소프트웨어 라이브러리를 늘리는 동시에, 윈도에서만 작업하는 하드웨어를 사용해야 할 때 추가적인 선택을 줄 수 있다. 즉, 레드박스를 둘러싼 거의 불가능한 장벽을 우회할 수 있다는 얘기다.
<b>Solving the Red Box Issues.</B>
DLL 안에서 윈도 코드를 실행시킬 때, 완전한 에뮬레이션을 필요로하진 않는다. 다루기 어려운 "윈도 API"가 모두 있어야 하진 않다. 윈도 API는 언제나 변화하면서, 마이크로소프트의 방향에 따라 바뀔 수 있다.
그렇다고 레드박스만큼의 자원 소모적인 개발을 해야하는 것도 아니다. 무엇이든 돌려야 한다는 비합리적인 요구사항을 맞춰주어야 할 필요가 없기 때문이다. 레드박스는 얼마나 완벽하건 간에, 아무도 만족시켜줄 수 없을 개념이다.
개발자들이 윈도 코드 재사용을 한다고 해서 기존의 윈도 환경 소프트웨어 사업이 위협에 처해지는 것도 아니다. Fusion이나 Parallels Desktop과 같은 제품 개발사들에게 레드박스가 갑자기 드리우게 될 쇠퇴에 분노하게 될 일도 없다. "OS/2 효과"를 막을 수도 있는 일이다. 가상적인 레드박스가 있다면, 윈도 개발자들이 그냥 맥용으로 윈도용 애플리케이션을 제공하지, 일부러 맥 기능의 장점을 누리게 위해 포팅을 시키지는 않을 것이다.
핵심 윈도 코드의 휴대성을 살리면, 개발자들은 유사하고 친숙한 맥 인터페이스를 만들어서 맥 기능을 누리면서 포팅을 할 수 있다. 최종 사용자에게는 별 다를 일이 없다. 맥 애플리케이션은 맥 애플리케이션이기 때문이다. 핵심 코드가 오픈소스 라이브러리이건, 맥 루틴이건, 윈도 DLL이건 상관 없다.
<b>In Cider the Apple.</B>
마이크로소프트와 어도비와 같은 써드파티 개발사 입장에서는, 이런 유사한 코드 공유가 일반적이었다. 이들은 오피스와 Creative Suite의 제작에 있어, 양 플랫폼용 네이티브 인터페이스로 싸인 엔진을 사용해, 각 플랫폼용 프로그램을 만든다.
사실 더 대규모의 새로운 개발은 비디오 게임 분야에서 이미 일어나고 있다. TransGaming의 Cider 라이브러리는 윈도 게임을 맥용으로 포팅시켜줄 때, 최소한의 코드변환만 하도록 돕는다. 원래는 네이티브로 개발하겠다 했던 게임도 지름길을 통해 간다고는 하지만, 결코 맥용으로 나타나지 않는다는 비판도 있다. 필자는 좀 다른 관점을 갖고 있으며 여기에 대해서는 다음 기사에서 밝히겠다.
하지만 우선, 윈도 코드를 맥 애플리케이션으로 통합시키는 것에는 어떤 측면이 있을까? 윈도 실행 포맷을 새로이 지원한다는 레퍼드의 새로운 지원에서 어떤 의미가 있을까? 오픈소스 개발과 협력적이지만 경쟁적이기도 한 애플의 위치를 보라. 애플은 대부분의 사람들 생각 이상으로 오픈소스에 더 많은 기여를 하게 될 것이다. 다음 기사에서 밝힌다.
<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>
Advancing Software Reuse of Linux, Windows Code on the Mac (http://www.roughlydrafted.com/2007/12/17/advancing-software-reuse-of-linux-windows-code-on-the-mac/)