“Window’s 8 dirty little secret”. 이란 글은 이미 오래전에 봤는데요. 그 글 보고서 든 생각은 한마디로 "황당하다" 였습니다.



위의 그림에서와 같이... WinRT는 메트로 스타일 애플리케이션을 위한 새로운 API 레이어 입니다.
테블릿 또는 모바일 기종들의 제품을 위한 새로운 플렛폼이기도한 셈인 데요

메트로 애플리케이션에서는 Win32 API를 쓸 필요도 없고, 써서도 안되는 겁니다.

ARM 프로세서가 장착되는 기종에서는 'Window 8 RT' OS 가 들어가게 되고 여기선 Win32 API 레이어 자체가 아예 없습니다.

더욱이 메트로 스타일 애플리케이션은...

누군가가 만들어서 윈도우즈 App 스토어에 게시하면, 일반 사용자들이 돈을 지불하고 소프트웨어를 구매해서 사용하는 구조이기
때문에, 기존의 허술한 Win32 API를 그대로 허용하면 보안상 문제가 많고, 그 피해는 고스란히 제품 구매자들 에게 돌아가기 때문에
Win32 API는 극히 일부분만 사용이 가능하고, 그것도 디지틀 서명과 함께 패키징 되어 베포되어야만 합니다.

그러나 위에서 언급한 대로 'Windows 8 RT'에는 Win32 API 레이어 자체가 없기 때문에 Win32 API를 사용해선 안되는 겁니다.

그럼에도 불구하고 “Window’s 8 dirty little secret”. 이라는 글을 통해서 RTL에서 'VirtualAlloc()' 같은 Win32 API를 쓸수 없기
때문에 MS사 탓하면서 WinRT를 지원하지 못한다고 하는 것은 한마디로 엠바카데로의 황당하고 구차한 변명이라는 거죠.


생각컨데 엠바카데로에서 이런 구차한 변명을 늘어 놓는 이유는...

네이티브 WinRT를 지원하기 위해선...

컴파일러가 메타데이타 정보를 생성하거나, 다른 메타데이타 정보를 인지할 수 있어야 하고...
네이티브 코드인 WinRT와 .net 어셈블리 모듈간에 ABI 바운드리를 연계해주는 코드도 생성 가능해야 하고...
COM 객체 인터페이스도 WinRT Symantics 에 맞게 처리 되도록 해주어야 합니다.

그리고...

WinRT는 C++ COM 기반의 네이티브 코드이지만, .net 어셈블리 모듈처럼 사용되기 때문에..
COM에서의 HRESULT 리턴값을 .net 어셈블리 모듈에서 인식할 수 있는 Exception 형태로 변환되로록...
컴파일러가 코드를 생성해 줘야 합니다. (컴파일러가 바이너리를 생성할 때... 이런 코드들을 투명하게 생성하기 때문에
프로그래머는 이런 부분들에 대해서 인지할 필요도 없고요)

이와같이 WinRT를 지원하기 위해선...
네이티브 컴파일러 자체가 확장되어 있어야 하는데, clang/LLVM 작업 마저도 아직 마무리 짓고있지 못한 상황에서
과연 엠바카데로 얘네들이 WinRT 지원 까지 감당할 여력이 있었겠냐는 겁니다. (델파이 컴파일러도 마찬가지 고요)



그리고 또 한가지...

어쩌면 엠바카데로에서 네이티브 WinRT를 지원하지 않을 수도 있을 것이란 생각인데..

C#, VB, 등의 닷넷 랭귀지를 이용해서도 Rapid Application 개발이 가능하지만... 생성되는 코드가 네이티브가 아닌 IL 이죠.
델파이/C++빌더는 네이티브 코드란 걸 강점으로 내세워서 엠바카데로 애들이 영업전략으로 삼고 있고요.

그런데...

WinRT는 윈도우 관련, 텍스트 박스, 콘트롤, 네트웍 기능, 등등 ... 모든 것들이 이미 네티이브 코드로 구현되어 있고,
.net 다루듯이 편하게 사용할 수 있어서... Win32 API 로 구현되어 있는 VCL 프레임웍이 무의미 해지게 됩니다.

이미 네이티브 코드로 구현되어 있는 WinRT를 이용해도 Rapid Application 개발이 되기 때문에, 엠바카데로가 내세우는 강점이
별 의미가 없게 되는 거죠.

WinRT를 이용해도 델파이/C++ 빌더처럼 쉽게 네이티브 프로그래밍이 되는데... 왜 굳이 엠바카데로 제품을 써야하지?

라고... 개발자들이 느끼기 시작할 테니까요.



...